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

Reply via email to