uClibc linking against libgcc_eh.a, the right thing to do?

[Ralph Siemsen]

On Tue, Sep 30, 2014 at 09:57:07PM +0200, Bernhard Reutner-Fischer wrote:
> On 30 September 2014 16:17:35 CEST, Thomas Petazzoni <thomas.petazzoni at free-electrons.com> wrote:
> >Hello,
> >
> >In commit 8d31a6e50db423b89082b64a3250eec1b94a7456 ("buildsys: link
> >libgcc_eh if DODEBUG"), Bernhard modified the uClibc build system to
> >link uClibc against libgcc_eh.a if DODEBUG is enabled.
> 
> This was a workaround for a failure with lockf() IIRC. Linking libgcc_eh in is wrong, maybe async unwind tables or no-except would get around the lockf() linker error, maybe later GCC (> 4.8.1 or some such) with -O0 do not expose the error in the first place.

I'm a little puzzled: is 8d31a6e50db423b89082b64a3250eec1b94a7456 meant
to fix the gcc build issue when using DODEBUG, or the SIGABRT issue
reported here: https://bugs.busybox.net/show_bug.cgi?id=5174 ?

They seem to be related somehow, but I'm not really certain anymore.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51275 seems to imply
that the optimizer can remove the EH info, presumably needed for
the try/catch to function correctly. That bug remains open, but
related PR 51117 was marked fixed back in 2011.

This stuff is all a bit over my head, but if there is anything I can
do to help test or debug, please let me know. I've tried various gcc
and uClibc combinations, so far, they all exhibit the SIGABRT problem
when an exception is thrown. The only workaround seems to be to compile
with -O0 or to pass -fno-omit-frame-pointer.

I do gather that NTPL support in uClibc is still considered experimental,
though it does seem to be the default configuration for ARM. I'm a bit
surprised that this has not caused more problems in C++ applications.

Regards,
-Ralph