[prev in list] [next in list] [prev in thread] [next in thread] 

List:       binutils
Subject:    Re: [PATCH v2] elf: Support DT_RELR relative relocation format [BZ #27924]
From:       Adhemerval Zanella via Binutils <binutils () sourceware ! org>
Date:       2021-10-29 19:53:14
Message-ID: b6d5e23f-063a-1057-28c7-3dfd43525238 () linaro ! org
[Download RAW message or body]



On 29/10/2021 16:35, Carlos O'Donell via Binutils wrote:
> On 10/29/21 14:38, Fāng-ruì Sòng wrote:
>> On Fri, Oct 29, 2021 at 11:21 AM Carlos O'Donell <carlos@redhat.com> wrote:
>>>
>>> On 10/16/21 20:50, Fangrui Song via Binutils wrote:
>>>> PIE and shared objects usually have many relative relocations. In
>>>> 2017/2018, SHT_RELR/DT_RELR was proposed on
>>>> https://groups.google.com/g/generic-abi/c/bX460iggiKg/m/GxjM0L-PBAAJ
>>>> ("Proposal for a new section type SHT_RELR") and is a pre-standard. RELR
>>>> usually takes 3% or smaller space than R_*_RELATIVE relocations. The
>>>> virtual memory size of a mostly statically linked PIE is typically 5~10%
>>>> smaller.
>>>
>>> We've been going over this patch on the weekly Monday patch queue review.
>>>
>>> I took a note to point out that one of the blockers here is that it is difficult
>>> to immediately test this work because it requires a working glibc build using
>>> ldd (which has support for DT_RELR).
>>
>> No:) There may be a misunderstanding.
>>
>> To test the feature: a DT_RELR executable is needed.
>> Currently only ld.lld --pack-dyn-relocs=relr supports generating
>> DT_RELR binaries,
>> but glibc itself does not need to be linked with ld.lld.
> 
> This is true.
> 
> However, running the entire testsuite with ld.lld and DT_RELR gives wider coverage
> and improves confidence in the feature.
> 
>> If the patch is accepted, GNU ld built glibc will support DT_RELR
>> programs linked by ld.lld.
> 
> I agree, but in that scenario, lacking the ability to link the entire testsuite
> with ld.lld reduces testing coverage for the feature.
> 
>>> What is the status of the lld support patches for glibc?
>>
>> aarch64 and x86-64 work well for me.
> 
> ... but they aren't yet committed?
> 
> Do we have a patchwork series for them?
> 
> https://patchwork.sourceware.org/project/glibc/list/?series=4199
> 
>> Seems that Adhemerval may be interested in adding a lld configuration
>> to scripts/build-many-glibcs.py
> 
> checking version of ld... 12.0.1, bad
> ...
> configure: error: 
> *** These critical programs are missing or too old: LLD
> *** Check the INSTALL file for required versions.
> 
> What's the fix for this?


I summarized the previous status of glibc plus lld on [1].  In a short,
only x86_64, i686, and aarch64 works without testcase regressions (i686
does show one regression, elf/ifuncmain6pie).  I am working on arm,
I could get it build and having the testcase without only 11 regression
(all of them related to ifunc). I plan to send the patches soon.

The powerpc builds but either loader or libc fails to run.  The riscv
also builds with an extra patch to set -mno-relax (to avoid R_RISCV_ALIGN
generation since lld does not support it), but I didn't not actually
test if works as expected.

The other supported architectures, sparc64 and mips, seems to be broken
and it would require much more work.

[1] https://sourceware.org/pipermail/libc-alpha/2021-October/132315.html
[prev in list] [next in list] [prev in thread] [next in thread]