-static-libgcc, static libstdc++.a, dynamically loaded so files and exception handling.

[Ian Lance Taylor]

Bob Rossi <bob@brasko.net> writes:

> On Sat, Jan 15, 2011 at 08:09:16PM -0800, Ian Lance Taylor wrote:
>
>> What you describe is not safe in all known configurations.  There are
>> configurations where the unwind library invoked to throw the exception
>> will not be able to find the unwind information defined by the shared
>> library, which means that it will not be able to reliably unwind through
>> the functions in the shared library, and, in particular, will not be
>> able to run destructors for local variables defined in functions in the
>> shared library.
>
> I'm assumming that you understood that the shared libraries are pure C,
> with no C++ in them at all. (There won't be any destructors for local
> variables defined in the shared library since it's pure C.) Only the
> main executable with throw and catch exceptions.

There is a gcc extension that permits destructors for local variables in
C code, and the GNU/Linux pthread library uses it when available.  Look
at pthread_cleanup_push in <pthread.h>.

Anyhow, whether you rely on that or not, the unwind library still needs
to find the unwind info just to unwind the stack reliably on x86_64.


>> However, what you describe is safe on current versions of GNU/Linux.  It
>> is safe if 1) your linker supports the --eh-frame-hdr option (binutils
>> 2.12 ; 2) your glibc provides the dl_iterate_phdr option; 3) your gcc
>> was configured to be aware of both these facts.  These facts have been
>> true for at least five years on GNU/Linux systems.
>> 
>> What is the range of configurations you have to consider?
>
> Well, essentially any configuration that someone asks to run the
> software on.
>
> Regarding points 1, 2, and 3. Do those have to be true at link time
> (when i'm building the executable on the machines I control)
> or at load time (when the user goes to run the executable on the
> machines they control)?

Unless you are linking statically, the dl_iterate_phdr function has to
be available at runtime, in libc.so.6.  Every other aspect is only
required at link time, on a machine you control.  You are probably safe
enough on GNU/Linux in practice, the question you'll have to consider is
whether you have to run on non-GNU/Linux systems.

Ian