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

[Lukasz Majewski <lukma@denx.de>]

[-- Attachment #1: Type: text/plain, Size: 2973 bytes --]

Hi Joseph,

Thanks for your input.

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

Yes. I can run Beagle Bone generated image on the HW (without the fix),
but it breaks down on QEMU.

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

Yes. OOPs are only present on the QEMU.

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

No, not yet. I try to debug working vs broken ld-linux.so on working
QEMU setup with LD_PRELOAD.

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




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]