Function Addresses

[Ofek Shilon]

The current spec says (under "Dynamic Linking/Function Addresses"):

"To allow comparisons of function addresses to work as expected, if an executable file references a function defined in a shared object, the link editor will place the address of the procedure linkage table entry for that function in its associated symbol table entry. This will result in symbol table entries with section index of SHN_UNDEF but a type of STT_FUNC and a non-zero st_value. A reference to the address of a function from within a shared library will be satisfied by such a definition in the executable."

It appears from brief testing (just gcc/x64) that this is not the mechanism in use today: 

Taking the address of a function makes the compiler mark its reloc as R_X86_64_GLOB_DAT instead of R_X86_64_JUMP_SLOT, making it bind at load time. Taking the function address then appears to deref its GOT entry - and not take the address of its PLT entry.

Is this indeed the state of things across platforms and architectures? If so - would you consider a patch that rectifies this spec paragraph? 

[Fangrui Song]

This paragraph does need some clarification.

You don't see a st_shndx=0, st_value!=0 symbol likely because you are compiling with -fpie, and GCC -fpie doesn't use a direct access relocation.

https://maskray.me/blog/2021-01-09-copy-relocations-canonical-plt-entries-and-protected

--
You received this message because you are subscribed to the Google Groups "X86-64 System V Application Binary Interface" group.
To unsubscribe from this group and stop receiving emails from it, send an email to x86-64-abi+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/x86-64-abi/336ef3da-e286-45ba-a965-abc3d3e1a25dn%40googlegroups.com.

--

宋方睿

[Florian Weimer]

* Ofek Shilon:

> It appears from brief testing (just gcc/x64) that this is not the
> mechanism in use today: Taking the address of a function makes the
> compiler mark its reloc as R_X86_64_GLOB_DAT instead of
> R_X86_64_JUMP_SLOT, making it bind at load time. Taking the function
> address then appears to deref its GOT entry - and not take the address
> of its PLT entry.

This behavior you observe is specific to position-independent
executables. Your toolchain appears to create them by default.

When the ABI speaks of “executable”, nowdays you need to read that as
“position-dependent executable” (an ET_EXEC object).

If I understand things correctly, the ET_EXEC behavior breaks the
implementation of protected symbols, which is probably why it wasn't
retained for ET_DYN executables. I think the glibc dynamic linker would
show the expected behavior for non-zero st_value in SHN_UNDEF symbols.

Thanks,
Florian