Re: lld status with powerpc64

[Adhemerval Zanella <adhemerval.zanella@linaro.org>]

On 08/11/2021 10:59, Bill Schmidt wrote:
> On 11/8/21 7:54 AM, Adhemerval Zanella wrote:
>>
>> On 08/11/2021 10:26, Bill Schmidt wrote:
>>> On 11/8/21 5:37 AM, Adhemerval Zanella wrote:
>>>> On 07/11/2021 11:24, Bill Schmidt wrote:
>>>>> Please coordinate with Alan Modra and Nemanja Ivanovic on this topic.  There are ongoing discussions about bfd and lld linker support around @notoc that will be resolved soon, and Tulio is on vacation, so I don't want the community to make steps they'll have to undo later, or for people to engage in duplicate work.
>>>> For this specific issue I just sent a patch to fix it on glibc side [1].
>>>> However I think it would be good if lld also implements the ld.bfd
>>>> optimization to fallback to older stub generation if no pcrel relocation
>>>> is found (although it is debatable that @notoc should implicit generate
>>>> older ISA code depending of the resulting objects being linked against).
>>>>
>>>> [1] https://patchwork.sourceware.org/project/glibc/patch/20211108113316.8867-1-adhemerval.zanella@linaro.org/
>>> Hi Adhemerval,
>>>
>>> Current course and speed is that @notoc will imply pcrel stubs on P10 and later,
>>> but will not do so on P9 and earlier.  The relocation currently associated with
>>> @notoc actually came with ELFv2 on P8 and, although no compilers ever generated 
>>> @notoc, assembly routines using it prior to P10 are a valid case and should not be
>>> punished.  This can be handled by generating a different reloc for @notoc in the
>>> two cases.
>>>
>>> If this solution holds up, then changes to glibc should be unnecessary.
>> The main problem is this imposes an extra burden for the linker, where it 
>> need to implement the ld.bfd optimization to not generate the power10 stubs 
>> if no pcrel is found.  And it seems that lld does not yet support this
>> yes and I guess it has not been an issue because @notoc in assembly
>> routines should be rare. 
>>
>> It also means that stubs generation are subject to a combination of
>> relocation on different objects (@notoc on assembly does not necessary
>> generate power10 stub with default linker option).  I think it should
>> be ok, although I see this as really confusing since it took some time
>> to figure out what ld.lfd was doing.
> 
> My only point is that the linker teams from both groups have been huddling about
> this, so I wanted you to be aware the issue goes a little deeper than it appears
> on the surface.  How glibc deals with this is up to glibc, of course. :)
> 

Well, my patch had to disable notoc exactly because lld version does not support
such optimization (so default builds always use power10 instruction).  It means
that lld powerpc64le support is either incomplete or @notoc handling need to be
clarified.