[Bug c++/40068] New: GCC fails to apply dllexport attribute to typeinfo.

[Bug c++/40068] New: GCC fails to apply dllexport attribute to typeinfo.

[dave dot korn dot cygwin at gmail dot com]

Precisely as subject.  All other class members and related data (e.g. vtables,
synthetic ctors) will be tagged dllexport if the class itself is dllexport, and
-export comments will be added listing their symbols in the .drectve section. 
Typeinfo data alone will not receive the dllexport attribute, because it is not
a class member.  (Theoretically, I think it counts as a static class data
member of type std::type_info, but internally) It is generated as a synthetic
POD data type, and hence does not appear to the i386 backend as belonging to
the class it represents.

The description in bug 17300 suggests that there could be a problem further
down the line with dllimporting such typeinfos, but right now they simply can't
be referenced outside the enclosing DLL at all, i.e. clients of a DLL can't
dynamically cast class pointers to the classes it implements, only routines
within the DLL which have local linkage to the typeinfo.  This is a separate
problem, which I think can be resolved further down the toolchain using
pseudo-relocs; I don't think it's a reason not to make export work.


-- 
           Summary: GCC fails to apply dllexport attribute to typeinfo.
           Product: gcc
           Version: 4.5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: dave dot korn dot cygwin at gmail dot com
 GCC build triplet: i686-pc-cygwin
  GCC host triplet: i686-pc-cygwin
GCC target triplet: i686-pc-cygwin


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40068

[Bug c++/40068] GCC fails to apply dllexport attribute to typeinfo.

[dave dot korn dot cygwin at gmail dot com]

------- Comment #1 from dave dot korn dot cygwin at gmail dot com  2009-05-08 11:53 -------
Created an attachment (id=17826)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17826&action=view)
Simple testcase

It doesn't get much more trivial than this.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40068

[Bug c++/40068] GCC fails to apply dllexport attribute to typeinfo.

[dave dot korn dot cygwin at gmail dot com]

------- Comment #2 from dave dot korn dot cygwin at gmail dot com  2009-05-08 11:55 -------
To reproduce the bug, compile the attached testcase

g++-4 -fpreprocessed -S vti.ii

and view the very end of the .s file emitted:

        .section .drectve
        .ascii " -export:_ZTV12XMLException,data"
        .ascii " -export:_ZN12XMLExceptionD2Ev"
        .ascii " -export:_ZN12XMLExceptionD1Ev"
        .ascii " -export:_ZN12XMLExceptionD0Ev"
        .ascii " -export:_ZN12XMLExceptionC1Ev"
        .ascii " -export:_ZN12XMLExceptionC2Ev"

Everything gets exported except the typeinfo.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40068

[Bug target/40068] GCC fails to apply dllexport attribute to typeinfo.

[dave dot korn dot cygwin at gmail dot com]

------- Comment #3 from dave dot korn dot cygwin at gmail dot com  2009-05-10 01:11 -------
Created an attachment (id=17841)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17841&action=view)
inherit dllexport from class to typeinfo

Now testing a solution based on the approach of adding the dllexport attribute
to the class' typeinfo object when the class is passed to
i386_pe_adjust_class_at_definition.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40068

[Bug target/40068] GCC fails to apply dllexport attribute to typeinfo.

[dannysmith at users dot sourceforge dot net]

------- Comment #4 from dannysmith at users dot sourceforge dot net  2009-05-10 05:01 -------
(In reply to comment #3)
> Created an attachment (id=17841)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17841&action=view) [edit]
> inherit dllexport from class to typeinfo
> 
> Now testing a solution based on the approach of adding the dllexport attribute
> to the class' typeinfo object when the class is passed to
> i386_pe_adjust_class_at_definition.
> 
Hello Dave,
Rather than use DLL linkage (and so force client to resort to auto-import
magic)
why not just always emit the RTTI with one-only comdat linkage.

        * decl2.c (import_export_decl): Always emit RTTI with comdat linkage
        rather than import if MULTIPLE_SYMBOL_SPACES.

Index: decl2.c
===================================================================
--- decl2.c     (revision 147015)
+++ decl2.c     (working copy)
@@ -2351,15 +2351,21 @@
        {
          class_type = type;
          import_export_class (type);
-         if (CLASSTYPE_INTERFACE_KNOWN (type)
-             && TYPE_POLYMORPHIC_P (type)
-             && CLASSTYPE_INTERFACE_ONLY (type)
-             /* If -fno-rtti was specified, then we cannot be sure
-                that RTTI information will be emitted with the
-                virtual table of the class, so we must emit it
-                wherever it is used.  */
-             && flag_rtti)
-           import_p = true;
+          /* Do not import typeinfo if the class might be in a DLL.
+            Dllimports do not have a constant address at compile time,
+            causing problems for static initialization of tables with RTTI
+            fields.  Set to comdat instead.   */
+         if (MULTIPLE_SYMBOL_SPACES)
+           comdat_p = true;
+         else if (CLASSTYPE_INTERFACE_KNOWN (type)
+                  && TYPE_POLYMORPHIC_P (type)
+                  && CLASSTYPE_INTERFACE_ONLY (type)
+                  /* If -fno-rtti was specified, then we cannot be sure
+                     that RTTI information will be emitted with the
+                     virtual table of the class, so we must emit it
+                     wherever it is used.  */
+                  && flag_rtti)
+            import_p = true;
          else
            {
              if (CLASSTYPE_INTERFACE_KNOWN (type)


-- 

dannysmith at users dot sourceforge dot net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |dannysmith at users dot
                   |dot org                     |sourceforge dot net
             Status|UNCONFIRMED                 |ASSIGNED
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2009-05-10 05:01:24
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40068

[Bug target/40068] GCC fails to apply dllexport attribute to typeinfo.

[dave dot korn dot cygwin at gmail dot com]

------- Comment #5 from dave dot korn dot cygwin at gmail dot com  2009-05-10 11:17 -------
(In reply to comment #4)
> Hello Dave,

  Hi Danny!

> Rather than use DLL linkage (and so force client to resort to auto-import
> magic)
> why not just always emit the RTTI with one-only comdat linkage.

  I have your patch in the cygwin distro compiler where it works fine, but I am
concerned about what unforeseeable problems could arise by violating ODR in
this way.  I don't have any concrete evidence of any problem yet, it is just a
worry.

  Also, I don't think this is necessarily an either-or situation; we could add
my patch and have the typeinfo exported from the DLL, and also add yours so
that clients could link a comdat copy (which would override the import stub)
until we have a better solution for importing from the DLL.  Or I could follow
up with another patch that propagates dllimport attributes from class to
typeinfo.

There is of course this:

/* We leave typeinfo tables alone.  We can't mark TI objects as
     dllimport, since the address of a secondary VTT may be needed
     for static initialization of a primary VTT.  VTT's  of
     dllimport'd classes should always be link-once COMDAT.  */ 

          /* Do not import tinfo nodes if the class has dllimport attribute.
             Dllimports do not have a constant address at compile time, so
             static initialization of tables with RTTI fields is a problem.
             Set to comdat instead.   */

... but I do not see why this should be a problem in these days of auto-import
and pseudo-relocs; do you know more about what the actual problem is (or was)
here?  Is this not basically the same situation as something like 

----dll_A.c----

int foo;
int __attribute__ ((dllexport)) * bar = &foo;

----dll_B.c----

extern int __attribute__ ((dllexport)) * bar;
int __attribute__ ((dllexport)) * baz = &bar;

---------------

the example above?

  If it's possible to solve either in the compiler or further down the
toolchain, I would very much like to do so.

  Also, how come emitting the typeinfo .linkonce as we currently do isn't the
same as COMDAT for these purposes?

    cheers,
      DaveK


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40068

[Bug target/40068] GCC fails to apply dllexport attribute to typeinfo.

[dannysmith at users dot sourceforge dot net]

------- Comment #6 from dannysmith at users dot sourceforge dot net  2009-05-13 08:12 -------
(In reply to comment #5)

>   Also, I don't think this is necessarily an either-or situation; we could add
> my patch and have the typeinfo exported from the DLL, and also add yours so
> that clients could link a comdat copy (which would override the import stub)
> until we have a better solution for importing from the DLL.

Yes.  I was just thinking out loud.  I have no objection to your patch. 
Perhaps MULTIPLE_SYMBOL_SPACES should be defined in terms of an
-mmultiple-symbol-spaces target option , since if we depend on auto-import than
we should treat dll imports thae same as static lib imports.

> Also, how come emitting the typeinfo .linkonce as we currently do isn't the
> same as COMDAT for these purposes?
> 
I'm not sure I understand your question.  In earlier versions of G++,  both
vtables and typeinfo were  always emitted with linkonce semantics, because of
the MULTIPLE_SYMBOL_SPACES define.  

Regards
Danny


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40068

[Bug target/40068] GCC fails to apply dllexport attribute to typeinfo.

[dave dot korn dot cygwin at gmail dot com]

------- Comment #7 from dave dot korn dot cygwin at gmail dot com  2009-06-25 15:37 -------
  Hmm, I'm getting somewhere with this.

  By compiling the g++ testsuite "ptrflags.C" case with --save-temps, manually
hacking all the superfluous typeinfo stuff out, and re-assembling and linking
it, I can turn a FAIL into a PASS, with all the typeinfo and related stuff
being imported from the DLL.

  So I think typeinfo can be made to work, and work with both
__GXX_MERGED_TYPEINFO_NAMES and __GXX_TYPEINFO_EQUALITY_INLINE.

  All I need to do is stop the compiler from emitting comdat definitions of
items with vague linkage when they are dllimported, or perhaps make the linker
prefer an import over a comdat section when the same symbol could be resolved
by either.  Or perhaps both.  I think the linker fix is what you were
suggesting when you said

> since if we depend on auto-import than
> we should treat dll imports thae same as static lib imports

  More later.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40068