[xsd-users] gcc visibility, serializer-map and typeinfo

[Boris Kolpackov]

Hi Benjamin,

Benjamin Schindler <bschindler at inf.ethz.ch> writes:

> The problem is that the type_map of type_serializer_map stores pointers
> to type_id structs. These type_info structs seem to have different
> addresses when compiled with --visbility=hidden in different shared
> objects. Some light on this issue is shed on in this faq entry:
> http://gcc.gnu.org/faq.html#dso
> 
> The problem manifests this way: When my object to be serialized is
> created in the so's loaded at startup time, it works. The xsd is
> compiled into dataflow.so, and the object is created and serialized in
> server.so and it works fine.
> 
> However, it does not work, when I create the xsd object in a plugin
> (i.e. a dlopened library) and serialize it in server.so. I get the
> exception thrown on type-serializer-map.txx:344.
> I don't know whether it would work when I'd serialize it in the dlopened
> lib itself - might work, but I'm not too familiar with the xsd internals.

Let me summarize the situation as I see it. Please correct me if I
missed something.

1. The same type has different std::type_info objects in different
   DSOs.

2. GCC uses address comparison in its implementation of 
   type_info::before () which in turn is used in polymorphism maps
   in XSD.

3. The dynamic linker is supposed to "weed out" duplicate type_info
   objects so that the process only uses a single object.

4. Exactly the same schemas and DSOs work fine if you use the
   default visibility instead of hidden.

If the above assumptions are correct, I think the problem is that the
types that are placed into the plugin DSO have hidden visibility which
leads to their type_info objects also having the hidden visibility and
the dynamic linker not "seeing" this object when it resolve duplicates.

>From the previous emails describing the Windows-related problem you
have experienced, I remember that you compile plugin schemas without
the --export-symbol option. This would result in exactly the behavior
described above.

Boris