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 ? > >> 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?
They are complementary. Perhaps another option like linker's --dynamic-list=<> that can take a file specifying the list of symbols. > > Longer term it would be probably better to support it properly > in the linker. > Linker solution has its own downside -- it require reserving more space conservatively for many callsites which end up being direct calls. David > -Andi > > -- > a...@linux.intel.com -- Speaking for myself only
