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

[Branko]

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" ?