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=-2.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,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 46c5a2cc for ; Wed, 29 Jan 2020 21:36:16 +0000 (UTC) Received: (qmail 22295 invoked by uid 550); 29 Jan 2020 21:36:15 -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 22277 invoked from network); 29 Jan 2020 21:36:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=ct5eecWVlXkN+Q2FYmOfrKItUFqf1U8Vu8dkZEwt72s=; b=jKLLlMPgnd4eNt3fRFr3Z7r7kkdUV8EsJxKpCfNMbwrzgM1xWRrBrZREU1DivJGPJh P7VZqS/DAvmH3OJ74DG/xNVZJpp8tIX17msIaTIYXWdhA1Mx0VZ/zAsNWI+xfvavJHn7 0kLQ1t95ZyKaydGyAz0HR5xanoKIyj++iaQ/W/7RFsBASSQ8kD6ziGNodcfljt88vW1Q QGLQoc2E9GtT6eL6Azv547kjLUZijYQ0V63UR/Zi+067YZeg1B+0YfkEoDSiQBVDQk1j MrXudRrisGdgaFLuz2ai6vCtgFiJmkT88d0RiSLCh7gRpbZKXGfb2nGJU+ZGFsqeoWFj f6Sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=ct5eecWVlXkN+Q2FYmOfrKItUFqf1U8Vu8dkZEwt72s=; b=BOQFPL2MEduEsUEOvRDf0akLlPemGkPnuH+ehlPOxwfKQoCKQMKW1xLQl+eRCYxW9Y 2jSFDUPiUMOk1qXs3tRtC48WIYeRX+l8jHVMTYwj1FYbOVzrCx5DSoeqm7P66hTutfxo ePQir6nmKJO1lquZLnhTsZVfliPUh2+lKZaMz+bkpDNjhRyQIVsuAS3kiLvphYaVjDFz aMsohdeyTA3co53nV0NveDey8wYeAQ6a/No2BL6R1l281Kb4UYKBFhoyHvrEnfSTTTKe ypr8vZ3NlHWkeGgh8WauXc0p30aqZxQZG64siZDeP0CC704WYYrvF2nE4zq7LX9UjlY8 dHNw== X-Gm-Message-State: APjAAAXTLje5wVFGlAjEo0eNe/4/OOc6VsfbGznX64bbQwz8F+LprwMl u8J41oL4ZERj6e8DStmiKnWN7sZt1ISNQGhh+4Q628fDKHg= X-Google-Smtp-Source: APXvYqypLf+0ghNdqQu8KuPg6gBRi0h7J6Tl4Ldw1OyDmTs68I74SUU0KSqL0fTCJqz/u/qJZ6wF1IuD37Kuu5lwbnU= X-Received: by 2002:a2e:89d4:: with SMTP id c20mr713461ljk.228.1580333763179; Wed, 29 Jan 2020 13:36:03 -0800 (PST) MIME-Version: 1.0 References: <20200129205330.GK30412@brightrain.aerifal.cx> <20200129211024.GY23985@port70.net> In-Reply-To: <20200129211024.GY23985@port70.net> From: =?UTF-8?B?0JDQvdC00YDQtdC5INCQ0LvQsNC00YzQtdCy?= Date: Thu, 30 Jan 2020 00:35:52 +0300 Message-ID: To: musl@lists.openwall.com Content-Type: multipart/alternative; boundary="00000000000094b848059d4e2041" Subject: Re: [musl] Static linking is broken after creation of DT_TEXTREL segment --00000000000094b848059d4e2041 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable "readelf -d main | grep TEXTREL" returns the same text on both musl and glibc containers: 0x0000000000000016 (TEXTREL) 0x0 0x000000000000001e (FLAGS) TEXTREL "gcc -no-pie" is another workaround for musl container like Rich said. But I think that 'set(CMAKE_EXE_LINKER_FLAGS "-static")' will be best cross platform solution. As I know "-static" implies "no-pie". > 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. What do you mean "-z text"? We can report improvement for gentoo. =D1=87=D1=82, 30 =D1=8F=D0=BD=D0=B2. 2020 =D0=B3. =D0=B2 00:10, Szabolcs Na= gy : > * 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 sam= e > > > situation works fine. I see no way to create a workaround for this > issue. > > > > 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. > --00000000000094b848059d4e2041 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
"readelf -d main | grep TEXTREL" returns the sam= e text on both musl and glibc containers:

0x00000000= 00000016 (TEXTREL) 0x0
0x000000000000001e (FLAGS)=C2=A0 =C2=A0 =C2=A0TEX= TREL

"gcc -no-pie" is another workar= ound for musl container like Rich said. But I think that 'set(CMAKE_EXE= _LINKER_FLAGS "-static")' will be best cross platform solutio= n. As I know "-static" implies "no-pie".

=
> 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 li= nk time failure. this is probably a gentoo toolchain bug.

What do you mean "-z text"? We can report improvement for= gentoo.

=D1=87=D1=82, 30 =D1=8F=D0=BD=D0=B2. 2020 =D0=B3. =D0=B2 00= :10, Szabolcs Nagy <nsz@port70.net= >:
* Rich Fel= ker <dalias@libc.or= g> [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 thi= s issue.
>
> 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.
--00000000000094b848059d4e2041--