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 526C93858D28 for ; Mon, 11 Oct 2021 13:10:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 526C93858D28 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 0BB378314C; Mon, 11 Oct 2021 15:10:14 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=denx.de; s=phobos-20191101; t=1633957814; bh=JfUmzb0XIwNXJJ/0hBNfeq1otiMSwLx+nQRX4zD4UMA=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=gdhyajVgMMGK1iE3ZzymOI634ej2ae9BKi1y38nFQ41nr8jNuvWyP2aIP7VW/V211 48vQ3W/Gyq7Zbrt/qYx2L1HsCcakbIMClNpk+KNw+kDZvrZqnrHgKdB4erPNRIcWmj J3tJb7MYFRBwLBtIwY9exC2MXAXY7ZQ2CCBxuShOssHsFmlgUNje9ORMNtD71GYnT/ TDWUDAvm1avLzMekw5l0UjxuhElwOJ7afVE6nWC7Yu8HKiIg8ygJHL7E0YyI8IoGf9 kO+rmIWlsOPwg74g5MP4NMjUvjou22Hn5I6BqyMLK9KnBiLNLib3Vw/m6SmLiUKJzF PbrktkqsUAl8w== Date: Mon, 11 Oct 2021 15:10:07 +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: <20211011151007.2903e38b@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> 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_/Xo7IDLKTMZ9xGOKrB6qoM/Z"; 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.3 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 13:10:20 -0000 --Sig_/Xo7IDLKTMZ9xGOKrB6qoM/Z Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Mon, 11 Oct 2021 05:01:23 -0700 "H.J. Lu" wrote: > On Mon, Oct 11, 2021 at 4:47 AM Lukasz Majewski wrote: > > > > 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 >=20 > Just don't run prelink on ld.so since the load address is controlled > by kernel. prelink is used also to speed things up. In some use cases - boot time optimization (like kiosk, or automotive) the bootup time is crucial. IMHO, the change with __ehdr_start introduced regression and hence shall be fixed so the previous behaviour is preserved. >=20 > > (moreover, IMHO running prelink on any binary and glibc is a valid > > use case) > > =20 > > > 2) partial revert =20 > > > > Ok. > > =20 > > > 3) new way to compute the load address. =20 > > > > This would require some input from developers deeply involved in ELF > > loader development. (Florian IIRC). > > > > 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 =20 >=20 >=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_/Xo7IDLKTMZ9xGOKrB6qoM/Z Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEgAyFJ+N6uu6+XupJAR8vZIA0zr0FAmFkN68ACgkQAR8vZIA0 zr3UCwf+LNYKZqdYFThQUBC5WHeOu/beC5b1MmoTwe22n7JItpu7KfOMXNdzDGOn JfiZ8QW/8hmO9oV+PNwVDMaQ3fPvRl7JAuT6F1Qqom74W/SArWYALNJ7c6mxK7zQ z8FAJiF2mSE3S5t79R4Huyz8nisyVq6f6sPAL5qpm62KU0yvztT/2YZcHI3UkDSr XFXVl7zLX2h3blxQCJStZvsQn8Sb1DaEseOWErt3mtkmFNOjhfiIOPveBoQoB82Z k2KbAIoNexXmuP+gKppXeANsSjVYMkEGsxIPfiI3eXc8+zsbMufNUSYqB2RzRy4w oYu5Hx1QSreU++ciX3DU0CQQTbPV3A== =ft9Q -----END PGP SIGNATURE----- --Sig_/Xo7IDLKTMZ9xGOKrB6qoM/Z--