[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 15 Jun 2014 21:41:31 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: gcc'c crtstuff.c: a musl-related experience
On Sun, Jun 15, 2014 at 05:36:37PM -0400, writeonce@...ipix.org wrote:
> The two files at stake are gcc/linux.h, and libgcc/crtstuff.c. In
> the former, a built-in macro named __gnu_linux__ is defined when
> glibc is the toolchain's default libc (OPTION_GLIBC). In the
> latter, a macro named USE_PT_GNU_EH_FRAME is defined when
> __gnu_linux__ is defined, which accordingly prevents
> USE_EH_FRAME_REGISTRY from being defined shortly thereafter. The
> absence of this last macro results in a crtbegin.o that is
> incompatible with musl, at least in some cases (a simple c++
> application crashes after an exception has been thrown, which is how
> I came to notice it).
I'm not an expert on gcc internals, but I'm doubtful of your
explanation of the problem. From just the macro names,
USE_PT_GNU_EH_FRAME is the one you want, and USE_EH_FRAME_REGISTRY
sounds like the nasty old fallback that's incompatible with static
linking of libgcc_eh.a.
However I'm confused what this has to do with crtbegin.o/crtend.o.
Perhaps someone who's worked with toolchain stuff could comment.
The reason I'm bringing this up is that there might really be some bug
in musl or in your toolchain setup, where switching to the old code is
just covering up the bug.
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.
