From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from phobos.denx.de (phobos.denx.de [IPv6:2a01:238:438b:c500:173d:9f52:ddab:ee01]) by sourceware.org (Postfix) with ESMTPS id 5A4EF385803F for ; Fri, 17 Sep 2021 08:29:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5A4EF385803F 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 C60FC8319C; Fri, 17 Sep 2021 10:29:24 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=denx.de; s=phobos-20191101; t=1631867365; bh=sTcb7e+H5y8/pVeXUvT2F1cMP3qjFYzVx0HAd9vmIOU=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=qs1j3Y0zBZj1TPOMMFeMKBbbR9SUmb/dPrA3nhqVECBoxmkI+jzGAYjGzNhaKMzTZ wnpk864/aqZJ7DzsRgwgTRk48QSfJUOUZe26q9z8vFaiUkfiFg5cl9GZZHiNsLzgb3 Mq5p9NuywwpgTHqwW9FhGx1zr4VxNaPhS7oa91SVLFv1ZUot/EhQ/0Y5jTl9fu711e LmZX/AfYaokj1Zikg8syQSDMFLRiTqlJfVqF8kK56s8SKe9t8BCFobTA0Ewa7bOOyk FWMBCRhpCe4ztUr1Np2K3BdABqlVggQ1lRVaWcBpdeILeQ/5Acuif/jjGoYdakAS7Z 1dFXXUOYzNtrw== Date: Fri, 17 Sep 2021 10:29:18 +0200 From: Lukasz Majewski To: Adhemerval Zanella Cc: Florian Weimer , libc-alpha , Joseph Myers Subject: Re: [PATCH] dl: Use "adr" assembler command to get proper load address Message-ID: <20210917102918.49b2d79a@ktm> In-Reply-To: <20210910121007.6b6bc81a@ktm> 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> 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_/1AHZvc=+AHaVzfJ02gdW8m/"; 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=-2.7 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: Fri, 17 Sep 2021 08:29:29 -0000 --Sig_/1AHZvc=+AHaVzfJ02gdW8m/ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Dear Community, > On Thu, 9 Sep 2021 11:49:36 +0200 > Lukasz Majewski wrote: >=20 > > On Thu, 9 Sep 2021 09:18:06 +0200 > > Lukasz Majewski wrote: > > =20 > > > On Wed, 8 Sep 2021 22:34:21 +0200 > > > Lukasz Majewski wrote: > > > =20 > > > > Hi Adhemerval, > > > > =20 > > > > > On 08/09/2021 12:05, Lukasz Majewski wrote: =20 > > > > > >=20 > > > > > > The r1 gets the 0xffffee80 (negative offset) value. It is > > > > > > then added to pc and used to calculate r2. > > > > > >=20 > > > > > > For working code (with this patch applied) - there are NO > > > > > > such large values (like aforementioned 0xffffee80). The > > > > > > arithmetic is done on=20 > > > > > >=20 > > > > > > 1690: 00000020 .word 0x00000020 > > > > > > 1694: 0002be7e .word 0x0002be7e > > > > > >=20 > > > > > > which seems to work. > > > > > >=20 > > > > > > This shouldn't be a problem as with U2 the arithmetic shall > > > > > > work. However, I've noticed (with passing LD_DEBUG=3Dall) that > > > > > > the ld-linux-armhf.so.3 (and init) are relocated twice > > > > > > before execution. > > > > > >=20 > > > > > > Why do we need to relocate it? > > > > > >=20 > > > > > > Another question is why on this particular case the large > > > > > > (i.e. negative) offset matters? =20 > > > > >=20 > > > > > I think it is highly unlikely the negative offset plays any > > > > > role here. Do you have a working example to trigger this > > > > > issue?=20 > > > >=20 > > > > I'm just using QEMU (runqemu -d y2038-image-devel nographic) > > > > from meta-y2038 build. > > > >=20 > > > > Recent versions:=20 > > > > poky: SHA1: 1e2e9a84d6dd81d7f6dd69c0d119d0149d10ade1 > > > > qemu_6.0.0 > > > > binutils_2.37 > > > > gcc_11.2 > > > >=20 > > > > The QEMU board uses Cortex-A9 core. =20 > > >=20 > > > I've updated the poky to be the newest -master: > > > master:50293eec9a7d0602b748220ab100b070b8d3432a > > >=20 > > > No change. > > >=20 > > > I will try the same setup with Cortex-A5 core - maybe there is > > > some kind of subtle handling of such emulation in qemu? =20 > >=20 > > No change. On the qemuarm yocto/OE MACHINE the same situation is > > observed. > > =20 >=20 > Do you have any more ideas where to look for solution of this problem? Can we make a decision regarding this fix? The only finding, which I get, is the large negative offset added to the pc in the glibc broken (current master) code, which causes QEMU system to fail.=20 I've shared this problem with the QEMU community [1], but no reply received till today. Shall we: 1. Apply this patch or 2. Revert the conversion (whole) patch [2] for ARM. 3. Wait till QEMU response for the problem? Links: [1] - https://lists.nongnu.org/archive/html/qemu-devel/2021-09/msg03332.html [2] - SHA1: bca0f5cbc9257c13322b99e55235c4f21ba0bd82 >=20 > > After applying this patch the board works without issues. > > =20 > > > =20 > > > > =20 > > > > > I am currently > > > > > testing arm for different compilers (gcc 6.2, gcc 10, gcc 11) > > > > > and with different configurations (armv5, armv6, armv7, with > > > > > and without thumb) and I haven't see any issue so far. > > > > >=20 > > > > > It might binutils related, which version are you using? > > > > > =20 > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > > Best regards, > > > >=20 > > > > Lukasz Majewski > > > >=20 > > > > -- > > > >=20 > > > > 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 =20 > > >=20 > > >=20 > > >=20 > > >=20 > > > Best regards, > > >=20 > > > Lukasz Majewski > > >=20 > > > -- > > >=20 > > > 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 =20 > >=20 > >=20 > >=20 > >=20 > > Best regards, > >=20 > > Lukasz Majewski > >=20 > > -- > >=20 > > 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 =20 >=20 >=20 >=20 >=20 > Best regards, >=20 > Lukasz Majewski >=20 > -- >=20 > 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 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_/1AHZvc=+AHaVzfJ02gdW8m/ Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEgAyFJ+N6uu6+XupJAR8vZIA0zr0FAmFEUd4ACgkQAR8vZIA0 zr0QsggAw87qc/enP2qLf0jBYeoqgaBfwuILiNcqFqxCGGBAMEnFgdSrex68M+wc vd7elRtpjIlrxqkLd+pO/jU8j+fW/cg5vGRY+xGMeJM/lfLAIS4HaeK8klHUWsDc ZveuWXTBaisCwkD44288GkSwW5z6gg+4K9NvdWeYgYcBfiBy3g/gpXaPpnPnrNbB QOaBdFpnsGfongHIzQPZtpwbs+dOC6giMJRRAY1PyF0sZSp8rubQoZ0ta6Cq5hTu FRq3AfA4VBKU/9Er/Llyzgbp+oIydgVJOWDQCY6g/cp9jFMFDXQtxBb50X/cp9eZ XetRwv5DMckVjdq520mAAvoXsUK++w== =6XMp -----END PGP SIGNATURE----- --Sig_/1AHZvc=+AHaVzfJ02gdW8m/--