Re: [PATCH] dl: Use "adr" assembler command to get proper load address

[Joseph Myers <joseph@codesourcery.com>]

On Fri, 17 Sep 2021, Lukasz Majewski wrote:

> Can we make a decision regarding this fix?

I don't think we've yet seen a thorough analysis of the issue.

Involvement of QEMU is probably not relevant.  Either the dynamic linker 
binary generated is correct, according to the instruction semantics in the 
Arm ARM and the relocation semantics in AAELF, or it isn't.  If it's 
incorrect, either the (static) linker inputs are correct and there's a 
linker bug, or the linker inputs are incorrect ("correct" here might be a 
bit fuzzier, involving things that are not fully specified).

So start from working out whether the generated binary is correct or not, 
with an appropriate description of the relevant instruction sequences 
executed and why they do or do not work in each case.

QEMU only becomes relevant if you have a binary that works when executed 
on hardware but not on QEMU (or vice versa).

(a) Do you have such a binary working on hardware but not on QEMU?

(b) Have you tested using the same binaries with both QEMU and hardware?

(c) Have you tested with the glibc testsuite, using a prebuilt system 
image with known good glibc rather than building init with the new QEMU?  
That's a better starting point than building a whole system with the new 
glibc, though if the result is "all tests fail execution" you may not be 
much further forward (but at least you can run the dynamic linker, good 
and bad versions, under gdbserver, and step individual instructions to see 
exactly what happens when the problem code is executed).

(d) Likewise, but with --enable-hardcoded-path-in-tests?  The point of 
this question is that one thing that's different by default between a 
glibc testsuite run and running binaries outside the glibc testsuite is 
whether new binaries are run directly or via ld.so --library-path.  It's 
possible some dynamic linker bugs might show up in one configuration but 
not the other.  So if the glibc testsuite passes in a default 
configuration (which I assume it did, if the submitter of the original 
patch tested it properly), but init fails in a newly built system image, 
one possible explanation would be such a bug - and running the glibc 
testsuite with --enable-hardcoded-path-in-tests is one way of checking for 
that kind of issue.

-- 
Joseph S. Myers
joseph@codesourcery.com