[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150429032725.GT17573@brightrain.aerifal.cx>
Date: Tue, 28 Apr 2015 23:27:25 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: building musl libc.so with gcc -flto
On Tue, Apr 28, 2015 at 06:42:13PM -0700, Andre McCurdy wrote:
> On Tue, Apr 28, 2015 at 6:44 AM, Rich Felker <dalias@...c.org> wrote:
> > On Mon, Apr 27, 2015 at 11:23:40PM -0700, Andre McCurdy wrote:
> >> On Mon, Apr 27, 2015 at 5:24 PM, Rich Felker <dalias@...c.org> wrote:
> >> > On Mon, Apr 27, 2015 at 05:16:12PM -0700, Andre McCurdy wrote:
> >> >> > OK, it looks like the _dlstart_c symbol got removed before linking the
> >> >> > asm. What about selectively compiling this file with -fno-lto via
> >> >> > something like this in config.mak:
> >> >> >
> >> >> > src/ldso/dlstart.lo: CFLAGS += -fno-lto
> >> >>
> >> >> That works. Should I send a patch?
> >> >
> >> > Yes, but configure would need to detect support for -fno-lto and add
> >> > it appropriately. See what's done for CFLAGS_NOSSP. I suspect the crt
> >> > files also need -fno-lto in principle even if they're not currently
> >> > breaking for lack of it.
> >>
> >> Patch sent.
> >>
> >> I think the crt files might be OK as they are, since the _start_c
> >> symbol isn't being hidden?
> >
> > I think you'll find the exact same thing happens if you use a crt1.o
> > produced from crt1.c for static linking with LTO. Note that on i386
> > (and x86_64) we still have a crt1.s which overrides crt1.c; I want to
> > remove it at some point. Temporarily removing/renaming it yourself
> > will allow you to test what happens with LTO on this file.
>
> Yes, you're right. The same workaround is needed for crt1.c, so my
> original patch is incomplete.
>
> The next issue, as Khem mentioned, is that AR and RANLIB need to be changed to:
>
> AR = $(CROSS_COMPILE)gcc-ar
> RANLIB = $(CROSS_COMPILE)gcc-ranlib
>
> Is it safe to use these gcc-xx wrappers in all cases (after having
> configure test that the toolchain provides them)? Or should they only
> be used with LTO?
I have no idea. But why can't a normal archive produced with ar be
used for LTO? Inability to use standard toolchain components/build
scripts sounds like a fairly big problem for LTO deployability.
> Beyond that I'm not able to statically link a hello.c test app using
> LTO yet, since LTO linking with .a archives requires the gold linker
> and I specifically have that disabled (to avoid issues I had seen
> previously with musl+gold+dynamic linking). It looks like I need to
> enable gold again before continuing. Are there any known issues, or
> known success stories, when using musl with gold?
I would actually love to see new reports on gold with musl dynamic
linking. The new dynamic linker bootstrap design should be a lot more
robust against poor choices by the linker, but there could be stupid
details that are breaking still which might call for fixes on musl's
side.
If you have citations for the problems that previously existed with
musl+gold, it would be nice to see those again too just to make sure
the issues were properly taken care of and not just swept under a rug.
Rich
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.
