Re: [PATCH v2] elf: Support DT_RELR relative relocation format [BZ #27924]

["Fāng-ruì Sòng" <maskray@google.com>]

On 2021-10-29, Adhemerval Zanella wrote:
>
>
>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.

I use a hacked /usr/local/bin/ld to link tst- test- objects with --pack-dyn-relocs=relr:

% cat /usr/local/bin/ld
#!/bin/zsh
output=
prev_arg=
for arg in "$@"; do
   [[ $prev_arg == -o ]] && output=$arg
   prev_arg=$arg
done

if [[ $output =~ 'tst-|test-' ]]; then
   exec ~/Stable/bin/ld.lld --pack-dyn-relocs=relr "$@"
else
   exec ~/Stable/bin/ld.lld "$@"
fi
% ~/Stable/bin/ld.lld --version
LLD 14.0.0 (compatible with GNU linkers)
% readelf -WS elf/tst-absolute-sym | grep relr.dyn
   [11] .relr.dyn         00000013: <unknown> 0000000000000f90 000f90 000020 08   A  0   0  8


Most tests pass, except the 7 nptl tests which spawn a gdb process and do some complex stuff with it:

% comm -3 <(grep '^FAIL' tests.sum | sort) <(grep '^FAIL' ../lld0/tests.sum | sort)
FAIL: nptl/test-condattr-printers
FAIL: nptl/test-cond-printers
FAIL: nptl/test-mutexattr-printers
FAIL: nptl/test-mutex-printers
FAIL: nptl/test-rwlockattr-printers
FAIL: nptl/test-rwlock-printers
FAIL: nptl/tst-pthread-gdb-attach-static

% cat nptl/test-condattr-printers.out
Error: Response does not match the expected pattern.
Command: print *condvar
Expected pattern: pthread_cond_t
Response:  Cannot access memory at address 0xffffd788
(gdb)



The 4000+ PASSes give me confidence that the DT_RELR does the right thing.



I read the generic-abi thread in 2019 but just noted that a comment from Ali Bahrami deserved my re-read
https://groups.google.com/g/generic-abi/c/bX460iggiKg/m/0PMCJ0hjBAAJ

"My free advice (worth what you paid for it) is to roll out the support, and
  then wait a bit before turning on the use widely, so that the support is in
  place before it is needed, and to not complicate things with a way to
  catch time travelers. The window of time where this can be a problem
  is finite, and once you're past it, you'll be glad to have a simpler system."

I hope that I have captured the status well enough in https://maskray.me/blog/2021-10-31-relative-relocations-and-relr#glibc :)

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

13.0.0 is needed :)

>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