Re: How to link funcrtion definitions, optimized for certain arch at link time ?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 20. 03. 19 09:28, Florian Weimer wrote:
* Branko:

On 20. 03. 19 08:11, Florian Weimer wrote:
* Branko:

If one yould check that condition during dynamic linking or customized
dl-opening of a needed DSO, one could simply do all the needed job there
- ie

check the condition and relocate all the calls to foo to land on foo_A,
or foo_B etc.

That way, there would be no runtime speed penalties...
The GNU toolchain supports IFUNCs, which allow precisely this.  Due to
the way ELF dynamic linking works, you still have the indirect
function call overhead, but this is present with or without IFUNCs
once cross shared object boundary.

Great. But it looks as it if needs to use PLT _always_, even for
local names as resolving function has to be initially accessed there
and then it decides which version of real function should appear in
that PLT slot.
This really depends on the architecture.  On some targets and with
certain memory models, if GCC knows a function has hidden visibility,
it emits a direct call.  Then IFUNCs will not work.  On these targets,
it is usually possible to keep these functions at default visibility,
annotate them with the noplt attribute at the source level, and mark
them as hidden in the linker.  Then GCC will emit an indirect call,
and the linker will generate an IRELATIVE relocation.

Part of the challenge is that on GNU, the compiler does not have clear
import/export information, unlike some other targets such as PE/COFF,
where this information is readily available (and somewhat cumbersome
to maintain.


Hmm. How do I mark selected functions as hidden "in the linker" ?








[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux