[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120818194035.GY27715@brightrain.aerifal.cx>
Date: Sat, 18 Aug 2012 15:40:35 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: Building without -Wl,-Bsymbolic-functions
On Sat, Aug 18, 2012 at 12:07:34PM -0400, idunham@...abit.com wrote:
> > On Sat, Aug 18, 2012 at 01:38:23PM +0200, Jens wrote:
> >>
> >> Hi!
> >>
> >> Im building musl inside an oldish uclibc environment based on uclibc
> >> 0.9.30.1, gcc 4.1.2 and GNU ld version 2.17.
> >>
> >> The linker does not accept -Bsymbolic-functions.
> >>
> >> Im now building the shared library despite of this.
> >>
> >> How broken will the musl libc be without -Bsymbolic-functions ?
> >
> > If building without it entirely, the shared libc will just crash.
> >
> > If replacing it with -Bsymbolic, it will run, but global variables in
> > libc that are accessed by the application (e.g. environ, optind, ...)
> > will actually have separate copies in libc and the application, and
> > thus the app won't work as expected.
> Last I checked, ISTR it was "Illegal instruction" or segfault (even for
> hello world); I forget which was which, but both did not work at all.
The first function call in __dynlink will jump to an invalid address,
yielding SIGILL or bogus behavior if the address is valid and SIGSEGV
if it's not.
It might be possible to include a hack to avoid this problem by
putting __asm__ (".hidden funcname"); at file scope in dynlink.c for
each function that might be used by the dynamic linker, but if any of
those functions in turn depend on other functions, it won't be
sufficient. I see it as a fairly fragile hack, and I'd rather not go
there; requiring -Bsymbolic-functions ensures that everything will
work.
> > A patch to add -Bsymbolic-functions to old binutils would be very
> > welcome... In the mean time, you could compile a new ld and pass the
> > -B option to gcc to give it the path for the new ld.
> The patch isn't trivial to get right, but 2.17.50 (20070703) is a
> significant improvement in many other ways (a few code generation fixes
> among them)...
> I've built a tarball, but not really posted it publicly (tarballs in git
> is really nasty 8-)* ).
>
> Interestingly, -B is not needed if you just put the desired version first
> in your path. (I found that out trying 2.17/2.17.50 on an Ubuntu host
> Isaac Dunham
Whether this works probably depends on how gcc is configured. For
example cross compilers will never get ld, etc. from the path; they'll
always use their configured directories.
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.
