From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) by sourceware.org (Postfix) with ESMTPS id 3FB573858C60 for ; Sun, 26 Sep 2021 19:58:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3FB573858C60 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=denx.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=denx.de Received: from ktm (85-222-111-42.dynamic.chello.pl [85.222.111.42]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: lukma@denx.de) by phobos.denx.de (Postfix) with ESMTPSA id E6DE68357A; Sun, 26 Sep 2021 21:58:37 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=denx.de; s=phobos-20191101; t=1632686318; bh=RBIdr2eRBmLSf0z561/d8Kr9XbPhWbvIFaNIefPQ+so=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=TIyiFMVnreQHy0kZuPlicUAQi2aN5xIKdE2AQZoPD9FXk0qztIpYrHSJfPmeTBTES C6rYUDFQg6qR8fkqtQHVVUJGthaDQnsS4CkWVrwWRAegIPGuc0LEX46iO4/RszV6yr 1mA6zDL8kLsMdTzbp5Hsi20GuxlRKiMxWJnptsGsykqriLCT9YQQXoreUPxfwXUc03 ENVG1qacZvmw/xPqIFiMk65HtPiXo+QPecphSchM8NOSFhOtm+adR6UbpKBdhGsEzb /wxabpqVbPl2ISgrqvc4YqpCVrt1aRV6calAdhgQ7qtIeKrUssfr5EvROLLyeH8bsn SzMDrS4VY08rg== Date: Sun, 26 Sep 2021 21:58:30 +0200 From: Lukasz Majewski To: Joseph Myers Cc: Adhemerval Zanella , Florian Weimer , libc-alpha Subject: Re: [PATCH] dl: Use "adr" assembler command to get proper load address Message-ID: <20210926215830.2d7d2ea6@ktm> In-Reply-To: References: <20210907131616.23472-1-lukma@denx.de> <20210907164906.yt6nonvfyhvbrx6p@google.com> <20210907193227.6047f9cc@ktm> <20210907174417.sctsswphsyae4mpc@google.com> <20210908170524.4be44bf0@ktm> <16812ef5-e21b-ba69-7ee7-a0c5a094ad01@linaro.org> <20210908223421.3befe316@ktm> <20210909091806.25d6ac87@ktm> <20210909114936.318c22c8@ktm> <20210910121007.6b6bc81a@ktm> <20210917102918.49b2d79a@ktm> Organization: denx.de X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/FnBohokShrROq4MLmi55hBA"; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.103.2 at phobos.denx.de X-Virus-Status: Clean X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_BARRACUDACENTRAL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Sep 2021 19:58:42 -0000 --Sig_/FnBohokShrROq4MLmi55hBA Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi Joseph, Thanks for your input. > On Fri, 17 Sep 2021, Lukasz Majewski wrote: >=20 > > Can we make a decision regarding this fix? =20 >=20 > I don't think we've yet seen a thorough analysis of the issue. >=20 > 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). >=20 > 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. >=20 > QEMU only becomes relevant if you have a binary that works when > executed on hardware but not on QEMU (or vice versa). >=20 > (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. >=20 > (b) Have you tested using the same binaries with both QEMU and > hardware? Yes. OOPs are only present on the QEMU. >=20 > (c) Have you tested with the glibc testsuite, using a prebuilt system=20 > 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). >=20 > (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. >=20 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 --Sig_/FnBohokShrROq4MLmi55hBA Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEgAyFJ+N6uu6+XupJAR8vZIA0zr0FAmFQ0OYACgkQAR8vZIA0 zr2Sdgf+L5Sfje5qk9Ne/VzNC5ghaxCpB0cUZ771d8ZMZvejiUdS4qJlyK7oMMsQ QnI6NK6FA4SyQZqiP16fiaxbprp5jl5g1l9ykX+nXKgZMq3Kl8VE8s8AlYwtmDxD d80ToegdBJu9A2+PR47Wf/AJ2hK8XgjLHc8nFZaT5/NWWY4OhQn0hI84UrTtDusk HQ8ljVK1ZxXyCOLjwXG9MTifpSA8sryhOvAxFaRazK1AJWIKs/Kxs21cd8Zb7FU6 0aahKBqjiC/2G1eDWDJmmKg6ACE/xRJVLHwXRXtbp5ZalpqJBSkcnsIl8nqui+CQ tm5pnqs91UqkcvhxX0gCaUmRZT6KrQ== =xvE2 -----END PGP SIGNATURE----- --Sig_/FnBohokShrROq4MLmi55hBA--