From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.0 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.2 Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by inbox.vuxu.org (OpenSMTPD) with SMTP id a4ec7f5e for ; Wed, 29 Jan 2020 21:10:38 +0000 (UTC) Received: (qmail 9414 invoked by uid 550); 29 Jan 2020 21:10:37 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 9396 invoked from network); 29 Jan 2020 21:10:36 -0000 Date: Wed, 29 Jan 2020 22:10:24 +0100 From: Szabolcs Nagy To: musl@lists.openwall.com Message-ID: <20200129211024.GY23985@port70.net> Mail-Followup-To: musl@lists.openwall.com References: <20200129205330.GK30412@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <20200129205330.GK30412@brightrain.aerifal.cx> User-Agent: Mutt/1.10.1 (2018-07-13) Subject: Re: [musl] Static linking is broken after creation of DT_TEXTREL segment * Rich Felker [2020-01-29 15:53:30 -0500]: > On Wed, Jan 29, 2020 at 09:41:46PM +0300, =D0=90=D0=BD=D0=B4=D1=80=D0=B5= =D0=B9 =D0=90=D0=BB=D0=B0=D0=B4=D1=8C=D0=B5=D0=B2 wrote: > > So I think that bug is inside musl itself. Glibc container is the same > > situation works fine. I see no way to create a workaround for this issu= e. >=20 > musl only has limited support for TEXTRELs as a legacy feature, and > only on some archs. It does not support them in PIE executables or > other "new settings". i would like to see why this works on glibc. glibc can process some text relocs but even then the elf image will not be shared when multiple instances of the same binary are executed potentially wasting a lot of ram and icache. so i don't think the glibc behaviour is desirable. if the glibc binary does not have textrel (it can be checked using readelf -d binary) it would be nice to know why. i'm also surprised that it was only a warning, i think gcc default pie toolchain passes -z text nowadays exactly to make this a link time failure. this is probably a gentoo toolchain bug.