https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100593
--- Comment #4 from Fangrui Song <i at maskray dot me> --- (In reply to Alexander Monakov from comment #3) > I understand what you're saying, but it seems we're talking past each other. > > I agree that if a library is linked with any -Bsymbolic* flag, the main > executable is at risk of broken address uniqueness unless it uses GOT > indirection. > > I am saying that if the library was linked with a more restrictive variant > of -Bsymbolic (that I called -Bsymbolic-plt), it would still get most the > benefit of -Bsymbolic, while remaining compatible with unmodified > executables. > > Would you agree? You misunderstand this. Emitting GOT-generating relocation in -fno-pic mode is the only way to avoid canonical PLT entry, if the function turns out to be defined in a shared object. No -Bsymbolic variant can make this compatible. Our goal is to eliminate symbol lookup for the function definition in the shared object. We must eliminate symbolic dynamic relocations, i.e. no JUMP_SLOT, no GLOB_DAT, no R_X86_64_64. The linker must set an address in the shared object and bind references to that address. In many programs (not long-running, not all code paths are exercised), the symbol lookup may cost more than the PLT indirection, given the sheer amount of symbol lookups. Now a -fno-pic program uses an absolute/PC-relative relocation => the linker must set an address in the executable's address space as well. The traditional ELF hack (st_value!=0, st_shndx=0) achieves this and let the shared object symbol reference bind to the executable definition. Note that we have explicitly eliminated symbol lookup for the defining shared object so the pointer equality cannot be satisfied at all.
