|
Message-ID: <20190530105206.GR16415@port70.net> Date: Thu, 30 May 2019 12:52:07 +0200 From: Szabolcs Nagy <nsz@...t70.net> To: musl@...ts.openwall.com Cc: Rich Felker <dalias@...c.org> Subject: Re: [PATCH] fix musl-gcc.specs.sh to correctly handle -static-pie * Fangrui Song <i@...kray.me> [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 <theferdi265@...il.com> > > > 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 <<EOF > > > 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
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.