On Fri, May 1, 2015 at 8:01 AM, Andi Kleen <a...@firstfloor.org> wrote: > Sriraman Tallam <tmsri...@google.com> writes: >> >> This comes with caveats. This cannot be generally done for all >> functions marked extern as it is impossible for the compiler to say if >> a function is "truly extern" (defined in a shared library). If a >> function is not truly extern(ends up defined in the final executable), >> then calling it indirectly is a performance penalty as it could have >> been a direct call. Further, the newly created GOT entries are fixed >> up at start-up and do not get lazily bound. > > This means you need to make it depend on -fno-semantic-interposition ?
Please correct me if I am wrong but I do not see any dependency on semantic-interposition. The GOT entry created for the function pointer (whose PLT has been eliminated) has a dynamic relocation against it to fixup the address at run-time and the dynamic linker fills it with the right address. This is not a new mechanism. The same mechanism is used when we access function pointers with PIE for instance. Thanks Sri > >> Given this, I propose adding a new option called >> -fno-plt=<function-name> to the compiler. This tells the compiler >> that we know that the function is truly extern and we want the >> indirect call only for these call-sites. I have attached a patch that >> adds -fno-plt= to GCC. Any number of "-fno-plt=" can be specified and >> all call-sites corresponding to these named functions will be done >> indirectly using the mechanism described above without the use of a >> PLT stub. > > The argument seems awkward. The command line may get very long. > Better an attribute? > > Longer term it would be probably better to support it properly > in the linker. > > -Andi > > -- > a...@linux.intel.com -- Speaking for myself only