Re: lld status with powerpc64

[Bill Schmidt <wschmidt@linux.ibm.com>]

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. :)