-
Notifications
You must be signed in to change notification settings - Fork 191
Expose ELF visibility and more relocation types #835
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
base: master
Are you sure you want to change the base?
Expose ELF visibility and more relocation types #835
Conversation
| /// Returns the symbol visibility. | ||
| /// | ||
| /// For ELF, this corresponds to the lower 2 bits of the `st_other` field. | ||
| /// For other formats, this returns [`SymbolVisibility::Default`]. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is misleading. At least mach-o has an equivalent of hidden visibility too. If you only care about default vs hidden visibility, then symbol.scope() will already give you that info. If you also care about protected visibility, then symbol.flags() will give you the visibility in the st_other field of the SymbolFlags::Elf variant.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I found the scope not sufficient for what I needed; True st_other exposes it but the other aspects of it already have friendlier methods;
if the issue is with MachO we can add it there as well or raise not implemented in default?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I found the scope not sufficient for what I needed
What do you need this for? Knowing the use might help guide the design.
It was a deliberate choice to not direct expose ELF's visibility in the unified API, because other formats don't have all of its intricacies; instead SymbolScope was chosen to expose the part that is common between formats. If there's another aspect of ELF's visibility that is orthogonal to SymbolScope, and you want to handle this in format agnostic code, then we could add a method for that. If all you need is ELF specific handling of visibility values, then the intent is to use SymbolFlags::Elf instead, even if it isn't as friendly.
| elf::R_X86_64_PLT32 => (K::PltRelative, g, 32), | ||
| elf::R_X86_64_GOTPCREL => (K::GotRelative, g, 32), | ||
| elf::R_X86_64_GOTPCRELX => (K::GotRelative, E::X86Gotpcrelx, 32), | ||
| elf::R_X86_64_REX_GOTPCRELX => (K::GotRelative, E::X86RexGotpcrelx, 32), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you specifically need the encoding values, or is knowing that they are GotRelative sufficient for your needs?
No description provided.