You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I believe this is correct; the idea is that it returns whether the symbol is something a dynamic linker could import; relying on section header information, while nice, is not actually required by a dynamic linker (since section headers can be stripped)
I don't have an opinion on the correct fix, but here's some things to think about.
I'm not sure how much sense it makes to try to classify symbols as an import based on what the dynamic linker does:
I don't think the dynamic linker ever needs to classify symbols as imports. It can't iterate through the symbols because there is no dynamic entry for the symbol table size. Instead, the dynamic linker only tries to import symbols that are referenced by relocations.
Even if the symbol referenced by the relocation is defined, every symbol with default visibility can ultimately be imported from another library instead.
I tried looking in glibc. It has a condition for determining an export which has portions that check both SHN_UNDEF and st_value == 0, among other things. Note that the st_value == 0 check is combined with SHN_ABS and STT_TLS checks.
You want to be checking whether it's global/weak and has a shndx of 0 (SHN_UNDEF)
The text was updated successfully, but these errors were encountered: