On Thu, Nov 20, 2014 at 5:42 AM, Michael Matz <m...@suse.de> wrote: > Exactly. As a symbol lookup needs to be done anyway for the GLOB_DAT > reloc going through the dynamic linker for the lazy lookup later when a > call occurs doesn't make sense. > >> jmp *name@GOTPCREL(%rip) >> 8 byte nop > > You mean replacing the PLT slot with the above? Yep, something like that. > Even better of course would be to not use the PLT slot at all, it's just a > useless indirection. It would be even cooler to rewrite the call insn > from > call foo@PLT > into > call *foo@GOTPCREL(%rip) > > (in the small model here) Unfortunately the latter is one byte larger > than the former. But perhaps GCC could already emit the latter form > when it knows a certain function symbol has its address taken (or more > precisely if a GLOB_DAT reloc is going to be emitted for it). > >> where name@GOTPCREL points to the normal GOT slot >> updated by R_X86_64_GLOB_DAT relocation at run-time. >> Should I give it a try? > > Frankly, I have no idea if it's worth it. Address takings of function > symbols doesn't occur very often, except in vtables, and that's not using > GOT slots. Vtables should be handled in a completely different way > anyway: as the entries aren't usually used for address comparisons they > should point to the PLT slots, so that it's only RELATIVE relocs, not > symbol based ones, so that also virtual calls can be resolved lazily. > > > Ciao, > Michael.
I fixed a bug on hjl/plt.got branch: https://sourceware.org/git/?p=binutils-gdb.git;a=shortlog;h=refs/heads/hjl/plt.got It passed glibc tests and bootstrapped GCC. It optimized functions like std::bad_exception::~bad_exception() __cxa_finalize std::range_error::~range_error() std::bad_array_length::~bad_array_length() -- H.J.