Problem with c++ exception handling within shared objects

[Peer Georgi <peer at peer-ware dot de>]

Hi All,

I have a very subtly problem when linking a shared object that includes the 
gcc-runtime to support c++ exceptions, type info, ...

The problem is that the following crashes:

         try {
           throw cCoreException();
         }
//          catch(const cUnUsedObjectThatWillNeverBeThrown& e)
//            {
//              (*mcu.mpDebug) << "Caught! cMy\n";
//              (*mcu.mpDebug) << e.what() << "\n";
//            }
         catch(const cCoreException& a)
           {
             // so far so good //
             const char* p = a.what();   // <- results in a crash
           }

The crash does occur when using:
  gcc-4.1, binutils-2.16.1  (compiled for ARM, sjlj-exceptions)
  gcc-4.2.1, binutils-2.18  (compiled for ARM, sjlj-exceptions)

The crash not coccurs when using:
  gcc-3.4.1, binutils-2.15 (compiled for ARM, sjlj-exceptions)


If I uncommend the lines above the same code works as expected on all tested 
compilers.
When linking using the "-symbolic" switch the code also works.



When I catch a non-reference of cCoreException like:

         catch(cCoreException a)         // <- no const reference
           {
             // so far so good //
             const char* p = a.what();
           }

all works perfectly.


For two weeks I try to track down the problem and I have collected all 
information in a document:
  http://www.obico.de/problem/gcc-runtime.pdf
(It's too much stuff for the mailing list.)


Some background information - What I try to do

I'm working on an exokernel for ARM written c++ in form of a shared object.
I use the default linux linker scripts that produce ELF shared objects without 
any changes.

My bootloader loads and relocates the shared object, calls all global 
constructors and jumps into the kernel-init function
that executes the code above.

The c++ runtime support is compiled together with the kernel sources.
I'm not using the libgcc_eh.a and libsupc++.a provided by the toolchain 
because I think the code is not position independend. - Am I right ???
The libgcc.so and libsupc++.so are also not a solution because this would 
require to load and relocate these libraries by my bootloader.


My questions are:
Why does the "-symbolic" link switch enable the code to work ?

As far I understood the "-symbolic" switch prevents the ".plt" section in
the resulting ELF library. Does this influence the c++ exception handling ???

Is there another piece of code required to get the c++ runtime working ?
Please note that I use sjlj exceptions. As far as I know calling global 
constructors is enough. - A I right ???


I hope anyone can give me a hint...

Best Regards,
  Peer Georgi.