dlopen() and placing exception body in .cpp file

[Dimitri Tcaciuc <dtcaciuc at gmail dot com>]

Hey everyone,

There are bits of information here and there, but I'm trying to get a
complete picture of how gcc output interacts with dlopen to produce
the results that I'm seeing in my test. I'm having a common exception
class `E` and two modules `foo` and `bar` which need to be dlopened
from one executable; functions from either module need to be able to
catch `E` (if you're wondering, this is for Python extension modules),
which for test's sake, they themselves can throw. E inherits from
`std::exception`.

 [main]

 dlopen(..) <--  foo.so <--------|
                                 [e.h]
 dlopen(..) <--  bar.so <--------|


For each module, [main] dlopens `catch_e` function that does a simple

   try { throw E(); } catch (const E & e) { printf("Caught e!\n" }


For base case,

  * exception is defined entirely in the header.
  * I use RTLD_LOCAL for dlopen arguments.

Now, according to `dlopen` manual, I have to load with RTLD_GLOBAL for
RTTI to function properly. But, here are some steps that I want to
understand how they work internally with RTLD_LOCAL enabled:

 * If I dlopen just one module (say foo), everything is dandy
 * If bar is loaded after that, bar::catch_e() catches general
`std::exception` instead of E.
 * If I have a single `const std::type_info & t_ = typeid(E);` in my
`main.cpp`, everything works fine.
 * Everything is solved if I implemented virtual destructor for my
exception in a separate `libe.so` and link foo and bar against it. I
think this is why modules catch std::exception instead of E;
std::exception is implemented in libstdc++.so

The last point seems to be the ultimate remedy, but I only found that
resolution searching through a number of blog posts where folks seem
to accidentally deduce that from trial and error. My best explanation
is that the `typeinfo` from the first binary or DSO that has it
becomes the main one; any subsequently loaded DSOs will get a mismatch
between the main typeinfo and their internal one. But then why does
implementing a virtual method of E in its own module solves the whole
thing altogether? What makes [main] properly resolve the typeinfo from
both loaded DSOs in that case?

It would be great if someone explained how this whole thing works or
pointed me to an official gcc/otherwise page that deals with this.

I've attached the test case files. Platform info: gcc (Gentoo 4.3.4
p1.0, pie-10.1.5) 4.3.4


Thanks,

Dimitri.

Attachment: ex_test_5.tar.gz
Description: GNU Zip compressed data