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

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

[ktietz at gcc dot gnu.org]

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

Kai Tietz <ktietz at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ml@convergent-it.at

--- Comment #8 from Kai Tietz <ktietz at gcc dot gnu.org> 2012-02-02 21:00:41 UTC ---
*** Bug 50044 has been marked as a duplicate of this bug. ***

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

[ktietz at gcc dot gnu.org]

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

--- Comment #9 from Kai Tietz <ktietz at gcc dot gnu.org> 2012-02-07 10:46:06 UTC ---
Author: ktietz
Date: Tue Feb  7 10:45:59 2012
New Revision: 183962

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183962
Log:
2012-02-07  Kai Tietz  <ktietz@redhat.com>
            Dave Korn  <dave.korn.cygwin@gmail.com>

        PR target/40068
        * config/i386/winnt-cxx.c (i386_pe_adjust_class_at_definition):
        Take care that typinfo gets dllexport-attribute.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/i386/winnt-cxx.c

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

[ktietz at gcc dot gnu.org]

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

--- Comment #10 from Kai Tietz <ktietz at gcc dot gnu.org> 2012-02-07 10:49:20 UTC ---
Author: ktietz
Date: Tue Feb  7 10:49:14 2012
New Revision: 183963

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183963
Log:
2012-02-07  Kai Tietz  <ktietz@redhat.com>
            Dave Korn  <dave.korn.cygwin@gmail.com>

        PR target/40068
        * config/i386/winnt-cxx.c (i386_pe_adjust_class_at_definition):
        Take care that typinfo gets dllexport-attribute.


Modified:
    branches/gcc-4_6-branch/gcc/ChangeLog
    branches/gcc-4_6-branch/gcc/config/i386/winnt-cxx.c

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

[ktietz at gcc dot gnu.org]

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

--- Comment #11 from Kai Tietz <ktietz at gcc dot gnu.org> 2012-02-07 11:48:41 UTC ---
Author: ktietz
Date: Tue Feb  7 11:48:34 2012
New Revision: 183965

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183965
Log:
2012-02-07  Kai Tietz  <ktietz@redhat.com>
            Dave Korn  <dave.korn.cygwin@gmail.com>

        PR target/40068
        * config/i386/winnt-cxx.c (i386_pe_adjust_class_at_definition):
        Take care that typinfo gets dllexport-attribute.


Modified:
    branches/gcc-4_5-branch/gcc/ChangeLog
    branches/gcc-4_5-branch/gcc/config/i386/winnt-cxx.c

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

[mattyclarkson at gmail dot com]

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

Matt Clarkson <mattyclarkson at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mattyclarkson at gmail dot com

--- Comment #12 from Matt Clarkson <mattyclarkson at gmail dot com> ---
Did that patch resolve this bug?  I'm using MinGW-builds-4.8.1-x64-posix-seh
and building a project and ended up with the following error:

value.hpp:33:31: error: external linkage required for symbol
'_ZTIN3udp8keystone6binary9arguments5ValueIZNS1_4Main17GetParsedArgumentERKSsE5DummyEE'
because of 'dllexport' attribute class UDP_KEYSTONE_DLL_PUBLIC Value final :
public ValueBase {

Which translates to missing 'dllexport' attribute on 'typeinfo for
udp::keystone::binary::arguments::Value'

But both my Value class and ValueBase classes are marked with
'UDP_KEYSTONE_DLL_PUBLIC' that expands to '__attribute__((dllexport))'

If this is a similar bug and not my error (which I presume it is) I will
resolve a test delta.

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

[mattyclarkson at gmail dot com]

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

--- Comment #13 from Matt Clarkson <mattyclarkson at gmail dot com> ---
Created attachment 30814
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30814&action=edit
missing dllexport on typeinfo output

Added an attachment for the full compiler output.

[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 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