Re: [RFC] C++ vs forced unwinding

[Jan Vroonhof <jan dot vroonhof at insignia dot com>]

Richard Henderson <rth at twiddle dot net> writes:

> Really, I think it's about time to revisit re-enabling unwind
> tables by default in C.  The overhead when using current 
> binutils and glibc has dropped to just about zero.

It probably be useful to give a detailed description of what works
when. Currently the situation is a bit murky IMO and you have to glean
the info from various mailing list archives. [Unless of course I
completely missed the obvious site/doc that explains all this].

For simplicity lets concentrate on x86-linux:

As far as I know the situation depends on or can depend on

1. Whether main app is C++ or C
2. Which gcc/as main app is compiled with (and what flags)
3. Which binutils where used to link the main app
4. Whether main app is C++ or C
5. Which gcc/as main app is compiled with (and what flags)
6. Which binutils where used to link the main app
7. The libc version involved (implies run-time linker version)
8. No threads, linux-threads, or NPTL

And the symptoms can be

1. Works
2. Fails at link time
3. Fails at run-time link time
4. Runs but pthread_cancel silently does not work
5. Runs but pthread_cancel silently does not execute C++ destructors
5b Runs but pthread_cancel silently executes only some C++ destructors
6. Runs but longjmp() silently does not execute C++ destructors
6. Runs but longjmp() silently executes only some C++ destructors
7. other

But exactly what happens for each of the combinations is unclear to me.
Could someone enlighten me?

e.g., I presume C app, C library and no threads works always (apart
from debugging stripped binaries with -fomit-frame-pointer).  At which
point do things start going wrong?

Jan