From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa2.mentor.iphmx.com (esa2.mentor.iphmx.com [68.232.141.98]) by sourceware.org (Postfix) with ESMTPS id B8E603858D29 for ; Fri, 17 Sep 2021 13:27:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B8E603858D29 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com IronPort-SDR: FJVxqKA/CaKQodc29vo83MIe1IgQ11pQKC0ni/wXgnkj6v6CLH/Kuq9b4pVSCaALawLhietoPZ WaJpnVkwA84cBYXX4jXKtmjmkQRpDmmK6J91srwU2IcOTMvPQSNtI3ba3LW5HMwrZWWg0raoxE yPIOtPrFwiPlikUMKO007AWl12GfPDy/bXnB7GA4+ZF/FHSbkkBt7Fg94rZbLYwAQYMPAX0XV1 +V9J/YybuDA0daw/6FRQtZ+mLMDuynXsdRmT8mXO2LO1F91TkuDf8je4ZiaUmpz9rKa26eWyd3 mUc= X-IronPort-AV: E=Sophos;i="5.85,301,1624348800"; d="scan'208";a="65985560" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa2.mentor.iphmx.com with ESMTP; 17 Sep 2021 05:27:55 -0800 IronPort-SDR: MtKn4JuFWusrF3AzUsrFxq4W1FOi1d+NMjXQAHcxjxVYJ+wwe9R2YzpvF0tkK28p81NkE0uPc3 XNo+zMJg3QTdsCPxle5x9Mrhp1lrkgY5GvGXLwWr48w6HJHbAp6+WspAvFl51lkXHT5K4Yer21 E4uD60epzE8uE5pOFCY6qw9nmnj8KxoegpnzXdKwja4c49ciRepbyXTgacCw9Mpo17q5XZ6SdO qwFjG4C2XG3drJCkw15MX6a0UEyvuGcwQ+jKmdIFXhNR5zw6b0zkAENvCdDYcATXkGcbwDi2MF wYs= Date: Fri, 17 Sep 2021 13:27:49 +0000 From: Joseph Myers X-X-Sender: jsm28@digraph.polyomino.org.uk To: Lukasz Majewski CC: Adhemerval Zanella , Florian Weimer , libc-alpha Subject: Re: [PATCH] dl: Use "adr" assembler command to get proper load address In-Reply-To: <20210917102918.49b2d79a@ktm> Message-ID: 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> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-Spam-Status: No, score=-3118.4 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, SPF_HELO_PASS, 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: Fri, 17 Sep 2021 13:28:00 -0000 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