Exceptions in shared libraries on HP/UX fail

[Frank Pilhofer]

  Hi,

 I'm using egcs 1.0.2.

 Exceptions that are thrown from inside a shared library and are
supposed to be caught from outside the library cause a segmentation
fault on HP/UX.
 It seems to be the problem that the function __sjthrow from libgcc.a
may not reside in a shared library.

 Here's an example:

--8<---8<-- testlib.cc
class Ex {};
void Blubb (void) {
  throw Ex();
}

--8<---8<-- testapp.cc
void main()
{
  try {
    Blubb();
  } catch (...) {
  };
}
--8<---8<--

 I now compile testlib into a shared library using

  g++ -c -fPIC -c testlib.cc 
  g++ -shared -o libtestlib.sl -fPIC testlib.o  

 The linking command implicitely passes -lgcc to the linker, causing
__sjthrow and friends to be "statically" included in the shared lib.
Now I compile the application:

  g++ -o testapp testapp.cc -L. -ltestlib

 Since __sjthrow is part of libtestlib.sl, it is not linked in again
from libgcc.a, but will be resolved from the shared library. Now, if
I invoke the app:

jade:~ > ./testapp 
Segmentation fault (core dumped)

 A stack trace with gdb is short and to the point:

(gdb) bt
#0  0x29d4 in main ()
#1  0x0 in ?? ()

 However, if I force __sjthrow to be resolved from libgcc.a by force-
linking it in:

  ar x libgcc.a _eh.o
  g++ -o testapp testapp.cc _eh.o -L. -ltestlib

 Then the program runs successfully.

 We believe this may be a problem with setjmp/longjmp in relation with
shared libraries.

 The problem does not exist on SunOS or Linux (because of the different
exception handling mechanism?).

	Frank

-- 
 + Frank Pilhofer                        fp@informatik.uni-frankfurt.de  +
 |                                      http://www.uni-frankfurt.de/~fp/ |
 +---- Life would be a very great deal less weird without you.  - DA ----+