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

[Benjamin Schindler]

Hi Boris

Okay, I have located the bug. One never stops learning...The problem is
the following: If I have a template class like this:

template<typename T>
class Bla {
// some code
};

and I instantiate this template in different dso's, the template will be
instantiated in each dso with visibility=hidden and they therefore get
their own type_info object. This problem does not occur with the stl as
they declare their namespaces like this:

_GLIBCXX_BEGIN_NESTED_NAMESPACE(std, _GLIBCXX_STD_D) which expands to

namespace std __attribute__ ((__visibility__ ("default"))) {

This means, that the template type gets exported and the type_info
object get correctly merged. I don't know whether you need to export the
entire namespace or just all template classes. Anyway - I tested this.
The serialization happened on a element declared like this in the xsd:

<xs:element name="errorReport" type="xs:string" minOccurs="0" />

I looked up the internal type and indeed, you have your own string
class. So in types.hxx, line 58, I tested did this:

template <typename C, typename B>
class __attribute__((visibility("default"))) string: public B, public
std::basic_string<C>

with this change, serialization of this type worked. I'll let it up to
you to decide what and how you would like to export your stuff. as
little as possible is always a good thing, but since libxsd is template
only, it might make sense to export the entire namespace may be

Cheers
Benjamin

The problem is, that template types need to be exported using
On 06/24/2010 09:29 PM, Boris Kolpackov wrote:
> 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