From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14159 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH] fix musl-gcc.specs.sh to correctly handle -static-pie Date: Thu, 30 May 2019 12:52:07 +0200 Message-ID: <20190530105206.GR16415@port70.net> References: <9ea47b05-2298-dc48-d938-f1593c1d0d3c@gmail.com> <20190530031727.GL23599@brightrain.aerifal.cx> <20190530062044.i7lkjrwfvcdyvfm6@gmail.com> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="153738"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.10.1 (2018-07-13) Cc: Rich Felker To: musl@lists.openwall.com Original-X-From: musl-return-14175-gllmg-musl=m.gmane.org@lists.openwall.com Thu May 30 12:52:23 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1hWIfW-000dkG-F2 for gllmg-musl@m.gmane.org; Thu, 30 May 2019 12:52:22 +0200 Original-Received: (qmail 5853 invoked by uid 550); 30 May 2019 10:52:19 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 5830 invoked from network); 30 May 2019 10:52:18 -0000 Mail-Followup-To: musl@lists.openwall.com, Rich Felker Content-Disposition: inline In-Reply-To: <20190530062044.i7lkjrwfvcdyvfm6@gmail.com> Xref: news.gmane.org gmane.linux.lib.musl.general:14159 Archived-At: * Fangrui Song [2019-05-30 14:20:44 +0800]: > On 2019-05-29, Rich Felker wrote: > > On Tue, May 28, 2019 at 10:19:18PM +0200, Ferdi265 wrote: > > > Hello, > > > > > > Today I wanted to use musl-gcc to build -static-pie binaries. I noticed > > > that this does not work (musl-libc is still linked as a shared library > > > and is also still requested as an interpreter). > > > > > > Looking into the musl-gcc.specs file the bug was obvious: rcrt1.o was > > > not used as a startfile, and neither -no-dynamic-linker nor -static were > > > passed to the linker. > > > > > > This patch fixes this by actually using rcrt1.o and passing the linker > > > options when -static-pie is given. > > > > > > I don't have much experience with the specifics of gcc .spec files and > > > which options need to be passed, but this seems to work with all > > > variations of -shared, -static, and -static-pie that I've tried. > > > > > > Here (https://github.com/Ferdi265/musl) is the repository with the patch > > > on GitHub, and I've also attached the patch below. > > > > > > Greetings, > > > Ferdinand "Ferdi265" Bachmann > > > > > > --- PATCH BELOW --- > > > > > > From 070bce8f7e508a951d3b65da227b2fca3a65f37b Mon Sep 17 00:00:00 2001 > > > From: Ferdinand Bachmann > > > Date: Tue, 28 May 2019 21:53:25 +0200 > > > Subject: [PATCH] fix musl-gcc.specs.sh to correctly handle -static-pie > > > > > > --- > > > tools/musl-gcc.specs.sh | 4 ++-- > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > diff --git a/tools/musl-gcc.specs.sh b/tools/musl-gcc.specs.sh > > > index 30492574..7206cb25 100644 > > > --- a/tools/musl-gcc.specs.sh > > > +++ b/tools/musl-gcc.specs.sh > > > @@ -17,13 +17,13 @@ cat < > > libgcc.a%s %:if-exists(libgcc_eh.a%s) > > > > > > *startfile: > > > -%{!shared: $libdir/Scrt1.o} $libdir/crti.o crtbeginS.o%s > > > +%{static-pie: $libdir/rcrt1.o} %{!static-pie: %{!shared: > > > $libdir/Scrt1.o}} $libdir/crti.o crtbeginS.o%s > > > > > > *endfile: > > > crtendS.o%s $libdir/crtn.o > > > > > > *link: > > > --dynamic-linker $ldso -nostdlib %{shared:-shared} %{static:-static} > > > %{rdynamic:-export-dynamic} > > > +%{static-pie:-no-dynamic-linker -static} %{!static-pie:-dynamic-linker > > > $ldso} -nostdlib %{shared:-shared} %{static:-static} > > > %{rdynamic:-export-dynamic} > > > > > > *esp_link: > > > > > > > This looks okay-ish, but could be improved. GCC spec syntax doesn't > > require separate static-pie and !static-pie conditions; it supports > > "else" with notation: > > > > %{static-pie:-no-dynamic-linker -static;-dynamic-linker $ldso} > > > > There's also the question of whether we should make -static -pie work > > like it's intended to by us, or like gcc does it upstream (ignoring > > -pie). I think it's hard to duplicate the behavior we want since it > > depends on knowing if the compiler was built as default-pie, so the > > way you've done it is probably the best we can easily do, and at least > > non-broken. > > > > Anyone else have comments on this? > > gcc -dumpspecs says: > > %{static-pie:-static -pie --no-dynamic-linker -z text} > > Do we want to specify -z text? musl does not really support text rels so arguably -z text should be always passed. but since it's just a diagnostic option it is not strictly necessary, just userfriendly. > > In ld.bfd and gold, -z notext is the default. If text relocations are needed: > > -z notext: allow and emit DF_TEXTREL. DF_TEXTREL is not emitted if there is no text relocation. > -z text: error > In lld, -z text is the default (this change is a no-op). > > -z text: error on text relocations > -z notext: allow text relocations, and emit DF_TEXTREL no matter whether text relocations exist. > > > While comparing the differences, I also came across this rule: > > %{!static|static-pie:--eh-frame-hdr} > > > It means "pass --eh-frame-hdr to ld if -static isn't used or -static-pie > > is used since -static-pie needs PT_GNU_EH_FRAME segment. > > This is related to PT_GNU_EH_FRAME (it is produced if .eh_frame_hdr exists) and various unwinders. > I'm not particularly clear about the internals. Some related links: allows unwinding across or within an elf module without load-time registration of the module with the unwinder (registration implies single unwinder instance with global data). (with eh-frame-hdr an unwinder can find the data using dl_iterate_phdr, no registration is needed) i think the difference between static and static-pie exists because different compiler startup code (crtbeginT.o vs crtbeginS.o) gets linked in, the first uses the registry (__register_frame_info) the second assumes eh-frame-hdr. > > https://reviews.llvm.org/D19029 FreeBSD folk said LLVM's libunwind needed this on ARM > I think this piece of code is relevant > https://github.com/llvm-mirror/libunwind/blob/master/src/AddressSpace.hpp#L532 > https://reviews.llvm.org/D43203 clang -static adds --eh-frame-hdr unconditionally > https://www.openwall.com/lists/musl/2014/06/16/2 Re: gcc'c crtstuff.c: a musl-related experience