Re: [PATCH] csu: Skip ARCH_SETUP_IREL if _dl_relocate_static_pie applied IRELATIVE relocations [BZ #27164]

[Fangrui Song via Libc-alpha <libc-alpha@sourceware.org>]

On 2021-07-12, Carlos O'Donell wrote:
>On 7/8/21 6:10 PM, Fangrui Song wrote:
>> From: Siva Chandra Reddy <sivachandra@google.com>
>>
>> For a static pie, _dl_relocate_static_pie applies IRELATIVE relocations
>> so ARCH_SETUP_IREL should not apply relocations again. The code
>> currently relies on ld -pie not defining
>> __rela_iplt_start/__rela_iplt_end (they end up as 0 as unresolved
>> undefined weak symbols).
>
>Correct, this is how PIE and static PIE were designed by HJ.
>
>> However, LLD defines __rela_iplt_start/__rela_iplt_end regardless of
>> -no-pie or -pie, so in an LLD linked static pie, ARCH_SETUP_IREL would
>> re-apply the relocations in the range of [__rela_iplt_start,
>> __rela_iplt_end), causing a segfault.
>
>The reason this issue has been raised is that our joint downstream
>users are unable to use lld on existing systems to compile and test
>static PIE binaries.
>
>Ryan Houdek raised it on IRC, and I asked them to file a bug:
>https://sourceware.org/bugzilla/show_bug.cgi?id=28066
>
>The average downstream users may take anywhere from 12-18 months to
>get a new glibc in their systems.
>
>If lld were to make the change today that would enable all downstream
>users to be able to use lld to compile static PIE without needing to
>get an updated glibc.
>
>From such a perspective the lld change to match binutils enables the
>feature for the most number of users the fastest.
>
>> Change _dl_relocate_static_pie to return an int, indicating whether the
>> relocations have been applied. This makes the intention clearer and
>> makes glibc buildable with LLD>=9.0 if we allow LLD at configure time.
>>
>> In addition, this enables a future simplification to GNU ld: we can drop
>> a linker script difference between -no-pie and -pie.
>>
>> Co-authored-by: Fangrui Song <maskray@google.com>
>
>I'm not inclined to accept this path. Not because I think the patch is
>technically wrong, but because fixing lld enables it immediately for the
>most number of users (making the patch moot).

True, changing lld is the fastest.
(I am not sure the word "fix" is appropriate because it isn't clear lld
is doing wrong here. HJ's argument "he designed __rela_iplt_start that
way" wasn't convincing.  Static pie is new. I don't see why the old
mechanism doesn't deserve a refresh.  (It is not my own opinion that
-static-pie/--no-dynamic-linker/-z dynamic-undefined-weak were not as
elegant as they could be.))

A toolchain project can do some workaround for a libc if this choice
makes a large community happy. However, I think it is important not to
take it granted. It is inadequate to just dismiss toolchain developers'
reasonable complaints. The libc should actively fix the issues so that
the toolchain will not need to bear unneeded code in the future.

I actually have contributed quite a few lld/ELF patches to work around
glibc. For this one I just feel it is not right to just patch lld/ELF
without fixing glibc.