-
Notifications
You must be signed in to change notification settings - Fork 155
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fail to parse specific section for relocations #728
Comments
See if #729 meets your need. Note that even without that PR, I think you could still call |
Thank you for your advice. #729 does solve my problem:) |
Sorry for reopening this issue. I found that the solution could not solve my problem after some investigation. The GOT entries in .got section are relocated by relocation records in several sections, such as |
You're doing something that is very specific to ELF, so use the lower level ELF API to read the relocations in |
I guess another option would be to check the relocation type (such as |
Looking some more, I don't think that's true. |
OK, so I think this is a very specific question that isn't related to |
For anyone interested in this question, the following is my implementation of retrieving PLT stub symbols (do not rely on it for robustness).
|
For ELF binaries, we can use
Object::dynamic_relocations
orObjectSection::relocations
to getRelocation
type. However, asObject::dynamic_relocations
are meant to collect all relocations that appeared in this binary,Object::Section::relocations
does not designed to treat specific section's data as relocations entries. Instead, it usesRelocationSections::Get
in this line to find a corresponding relocation section for given section, and parse such section for relocation entries.However, in some binaries, the
RelocationSections
is empty, while we can still get relocation entries throughObject::dynamic_relocations
. In such binaries, there is no way to get relocation entries of specific sections.Why I want this feature
I want to get name of plt entries in an ELF binary, and following discussions in gimli-rs/object#227, I found that the ddbug uses disassembly to get the corresponding got entry of one PLT stub. However, as stated in this SO,
objdump
assumes that PLT stubs and GOT entries are increasing coordinately. As a result, we can only parse the got relocation entries and then use the offset to locate corresponding PLT stubs, which is much light-weight than the disassemble-approach.The text was updated successfully, but these errors were encountered: