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 B7CAF3858421 for ; Mon, 11 Oct 2021 14:31:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B7CAF3858421 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 A8C3B82DA1; Mon, 11 Oct 2021 16:31:25 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=denx.de; s=phobos-20191101; t=1633962686; bh=j18xPC/H8lUyYyyH0LZTg7fT6wwXfaANI45ssW5ZTc0=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=ggzrVHBEcl/Acubd/eFlfprj123hI3dWpAGcB0iIY0a37vNX84IzPB70afdyhO/+T g+PueH+oQXQ1SIu+5QqASsvQLwCq10G/2mAyb6/3vhWjSSKRp9QjJhXUQVaHzRB0E5 ey0/ZDAqpOMoSjs26/FhcdFYJYTvWm7/S1bzUe3IXFm/3T8vFPw88a3yKKUPiZ2zxe nDLROF2BoTN1ry98jUzsd4URNbtoZraxnASQ0wGZUI+banV0hUsWjn75fYYN3mgDWa 0tHYlWogIaIbyhH2JGZZTro0ut+MZKKOM1U0EiPGh8m7WGe3tzUVCSR+RjnkwrdRa5 jWvlNex2pq5+g== Date: Mon, 11 Oct 2021 16:31:19 +0200 From: Lukasz Majewski To: "H.J. Lu" Cc: Szabolcs Nagy , Adhemerval Zanella , Florian Weimer , libc-alpha , Andreas Schwab , Joseph Myers Subject: Re: [PATCH] dl: Use "adr" assembler command to get proper load address Message-ID: <20211011163119.395740ca@ktm> In-Reply-To: References: <20211005094554.2f28d6bd@ktm> <20211006075721.qnv6qabroytcsido@google.com> <20211006110321.5f1a9610@ktm> <20211006134344.63395242@ktm> <20211006125517.GE2700@arm.com> <20211007111926.30db4c4f@ktm> <20211007120038.1445bbd3@ktm> <44bac775-3127-7bc7-c4ea-fa282ed277d3@linaro.org> <20211011105617.5bcd493d@ktm> <20211011101839.GJ2700@arm.com> <20211011134736.57e763ba@ktm> <20211011151007.2903e38b@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_/cLhGg9pa=Nt2ZwSAkmPr0C0"; 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.2 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: Mon, 11 Oct 2021 14:31:29 -0000 --Sig_/cLhGg9pa=Nt2ZwSAkmPr0C0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Mon, 11 Oct 2021 06:22:53 -0700 "H.J. Lu" wrote: > On Mon, Oct 11, 2021 at 6:10 AM Lukasz Majewski wrote: > > > > On Mon, 11 Oct 2021 05:01:23 -0700 > > "H.J. Lu" wrote: > > =20 > > > On Mon, Oct 11, 2021 at 4:47 AM Lukasz Majewski > > > wrote: =20 > > > > > > > > Hi Szabolcs, > > > > > > > > Thank you very much for your input. > > > > =20 > > > > > The 10/11/2021 10:56, Lukasz Majewski wrote: =20 > > > > > > Do we have _any_ plan how to fix it? BSPs for many boards > > > > > > are built with Yocto/OE nowadays... > > > > > > > > > > > > The approach with using 'adr' (pseudo) assembler > > > > > > instruction to calculate the on-runtime addresses was > > > > > > working previously. > > > > > > > > > > > > Shall we revert changes which were introduced recently (to > > > > > > use __ehdr_start)? =20 > > > > > > > > > > the reason for the change was to avoid relying on GOT[0]. =20 > > > > > > > > And why it is requested to not relying on GOT[0]? > > > > =20 > > > > > > > > > > i guess we can revert elf_machine_load_address on arm, but > > > > > keep the new elf_machine_dynamic that does not rely on > > > > > GOT[0]. =20 > > > > > > > > This was the approach proposed by this patch. > > > > =20 > > > > > > > > > > it is also useful to have the same c code across targets > > > > > for the load address. if we want to do that and support > > > > > vaddr!=3D0 for ehdr then i think it can be (untested): > > > > > > > > > > __attribute__ ((const)) ElfW(Addr) > > > > > load_addr (void) > > > > > { > > > > > extern const ElfW(Ehdr) __ehdr_start __attribute__ > > > > > ((visibility ("hidden"))); ElfW(Addr) addr =3D (ElfW(Addr)) > > > > > &__ehdr_start; ElfW(Word) phnum =3D __ehdr_start.e_phnum; > > > > > const ElfW(Phdr) *phdr =3D (const void *) (addr + > > > > > __ehdr_start.e_phoff); const ElfW(Phdr) *ph; > > > > > assert (__ehdr_start.e_phentsize =3D=3D sizeof *phdr); > > > > > for (ph =3D phdr; ph < &phdr[phnum]; ++ph) > > > > > if (ph->p_type =3D=3D PT_LOAD && ph->p_offset =3D=3D 0) > > > > > { > > > > > addr -=3D ph->p_vaddr; =20 > > > > > > > > The above line is a bit strange for me. Isn't the p_offset set > > > > by prelink as well? > > > > > > > > And most of all - why do we need to perform relocation in such > > > > very early stage of the ld-linux-armhf.so.3 ? > > > > =20 > > > > > break; > > > > > } > > > > > return addr; > > > > > } > > > > > > > > > > i don't have a strong preference either way: > > > > > 1) fix yocto =20 > > > > > > > > Yocto by default uses prelinkg from the very long time. I think > > > > that it would be very difficult to change that. =20 > > > > > > Just don't run prelink on ld.so since the load address is > > > controlled by kernel. =20 > > > > prelink is used also to speed things up. In some use cases - boot > > time optimization (like kiosk, or automotive) the bootup time is > > crucial. =20 >=20 > I am NOT asking you to remove prelink. I am only asking not to run > prelink on ld.so. Do you have bootup time data on ld.so with and > without prelink? The prelink is run on /sbin/init binary, so the libc.so.6 and ld-linux-armhf.so.3 are automatically affected. To put it in other words - up till this issue everything was working (maybe it was just working by a pure coincidence). Now, because of change in glibc (__ehdr_start usage) you ask if Yocto/OE can stop using prelink on certain libraries to avoid this error. Have I understood your comment correctly? >=20 > > IMHO, the change with __ehdr_start introduced regression and hence > > shall be fixed so the previous behaviour is preserved. > > =20 >=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_/cLhGg9pa=Nt2ZwSAkmPr0C0 Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEgAyFJ+N6uu6+XupJAR8vZIA0zr0FAmFkSrcACgkQAR8vZIA0 zr0DVgf/T7bsICRYloiSOQ3fRHZaVexglUp5oCkAP3sDXWKeTD6/+Un+locJ7KlW /cWRBDxVFpx+XkP5+zlwHB+LsKycmVXA4xHpUxkZwzpQrM2q9qfr7XWeHqA8N27f dYpMx76peW+tbSJz8BAz1Hc+iDcL35iwOrWMC4/eFLo6zwR9kzzW8Hb7EXojv5ta EBoA9gapdJui8ekl2tQu2AJF+u60gD4uw5V9bE250hErbtDhrg4ey8vMPMAfmMEh 49okXCufpRDOWyXlSKESlN8mkLXmSWNqlF1MROo3twWDFi1jsIIT3wtWzTYceXLM N5Wn1S8+mkTgcyYcepCh8E7njJkpTQ== =Sznr -----END PGP SIGNATURE----- --Sig_/cLhGg9pa=Nt2ZwSAkmPr0C0--