Re: Problem with shared libraries, exceptions, and global constructors

[Geoff Keating <geoffk at geoffk dot org>]

Bernd Schmidt <bernds@redhat.com> writes:

> Consider this test:
> 
> bernds@tesuji:~/bug> cat bug1.cc
> void foo ()
> {
>         try {
>                 throw 1;
>         }
>         catch (...)
>         {
>         }
> }
> bernds@tesuji:~/bug> cat bug2.cc
> #include <cstdlib>
> extern int foo ();
> 
> 
> int z = foo ();
> bernds@tesuji:~/bug> cat main.cc
> int main ()
> {
>         return 0;
> }
> bernds@tesuji:~/bug> cat bug.sh
> g++ -fpic -shared bug1.cc  -o libbug1.so
> g++ -fpic -shared bug2.cc  -o libbug2.so
> g++ main.cc  -L. -lbug1 -lbug2 -Wl,-rpath -Wl,.
> 
> 
> Running the executable produces
>   terminate called after throwing an instance of 'i'
>   Aborted
> 
> This depends on the link order of the shared libraries; it runs without
> aborting if you reverse the order of libbug1.so and libbug2.so.
> 
> What seems to happen is that we call the initialization code of
> libbug2.so before that of libbug1.so; so we call the constructor for "z"
> (and, in turn, foo() in libbug1.so)  before the exception handling for
> libbug1.so has been set up with a call to register_frame_info.
> 
> I've been staring at this for a while, and I can't see a good way to fix
> this.  Suggestions?

Don't use constructors to register EH information?

Darwin parses the shared object to find the EH information.  In ELF, I
guess you'd put an address in the PHDR segment.

-- 
- Geoffrey Keating <geoffk@geoffk.org>