www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 6461] New: multiple definitions with typeid and multiobj

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6461

           Summary: multiple definitions with typeid and multiobj
           Product: D
           Version: D2
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: dawg dawgfoto.de



--- tmpl.d:
module tmpl;
struct Tmpl(T) {
  T a;
}

---- a.d:
module a;
import tmpl;
TypeInfo fun() { return typeid(Tmpl!int()); }

--- b.d:
module b;
import tmpl;
TypeInfo fun() { return typeid(Tmpl!long()); }

--- main.d:
import a, b;
void main() {
  auto t1 = a.fun();
  auto t2 = b.fun();
  assert(t1 != t2);
}

reproduce:
dmd -lib -ofliba.a a
dmd -lib -oflibb.a b
dmd main -L-L. -L-la -L-lb

This bug is caused by Type::getTypeInfo causing a call to obj_append while
already being in a deferred genobjfile. The appended symbol is not marked as
doppelganger module thus writes out ModuleAssert, ModuleArray et al. Now two
different libraries can end up with colliding definitions if count in
obj_write_deferred is accidentally the same.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 09 2011
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6461




This bug is not caused by the late obj_append but is a direct consequence of
the special handling for Dsymbols that don't have a module in
obj_write_deferred.
It seems for the D case that TypeInfos are the only DSymbols that don't have a
module.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 09 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6461


Martin Nowak <code dawg.eu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |verylonglogin.reg gmail.com



*** Issue 9044 has been marked as a duplicate of this issue. ***

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 30 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6461


Martin Nowak <code dawg.eu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |major


-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 30 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6461




22:13:21 MSD ---
Change the title please as if Issue 9044 is dup of this, there is no need to
generate multiple object files and the issue can be triggered in dmd itself,
not in the linker. Also there is no need for `typeid` (at least in user code)
as shown in Rainer's example.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 30 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6461


Rainer Schuetze <r.sagitario gmx.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |r.sagitario gmx.de



PDT ---

 Also there is no need for `typeid` (at least in user code)


as shown in Rainer's example.

The "new" implicitely accesses typeid, so I think Martin is correct in marking
the issues as duplicates.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 30 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6461






 Change the title please as if Issue 9044 is dup of this, there is no need to
 generate multiple object files


It's multiobj not multiple objects and in fact you need at least two archives.


 and the issue can be triggered in dmd itself, not in the linker.


True


 Also there is no need for `typeid` (at least in user code)
 as shown in Rainer's example.


It happens when TypeInfo instances are emitted, because they are not put into a
doppelgänger module, i.e. the object contains definitions for assert,
unittest_fail, ModuleInfo.

For these TypeInfo instances s->getModule() returns NULL.
https://github.com/D-Programming-Language/dmd/blob/20655f957f3729298b79e6c695b9d7840ac5ef0f/src/glue.c#L116

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 30 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6461




PDT ---
Generating a UUID instead of the simple static counter in obj_write_deferred
seems to fix the problem.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 30 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6461




10:28:04 MSD ---




 Change the title please as if Issue 9044 is dup of this, there is no need to
 generate multiple object files


 
 It's multiobj not multiple objects and in fact you need at least two archives.


Sorry my ignorance, but I sill not sure I understand the terminology. The
library produced by `dmd -lib a.b b.d` is multiobj and contains two archives? I
thought the library is an archive...

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 30 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6461




PDT ---
"multiobj" is a term used in the compiler source when a module is split into
multiple object files (one for each function) to allow linking only referenced
functions. It is enabled when you bulid with "-lib". 

So "dmd -lib a.d" produces a library with 4 objects. If you then run "dmd -lib
b.d a.lib", dmd does the same for b.d and then merges the other lib a.lib into
b.lib. Doing so it detects the multiple definitions.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 30 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6461




PDT ---


 Generating a UUID instead of the simple static counter in obj_write_deferred
 seems to fix the problem.


Probably the better fix might be to not generate pseudo-ModuleInfo at all. In
addition, without a module the TypeInfo symbol is merged into the previous
(possibly unrelated) object file.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 31 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6461








 Generating a UUID instead of the simple static counter in obj_write_deferred
 seems to fix the problem.


 
 Probably the better fix might be to not generate pseudo-ModuleInfo at all. In
 addition, without a module the TypeInfo symbol is merged into the previous
 (possibly unrelated) object file.


Yeah UUIDs might work but we should instead remove the ugly hack that causes
the multiple definitions, i.e. "mname = lastmname;".

IIRC TypeInfo instances were the only symbols where s->getModule() returns
NULL.
But a TypeInfo instance should belong to the module of the described Type.
I hope that we can remove the hack if we fix that behavior and assert
s->getModule.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 31 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6461




PDT ---


 IIRC TypeInfo instances were the only symbols where s->getModule() returns
 NULL.


I had the impression that the init-data has the same problem, but I could also
have been confused by other issues (the multiobj library creation doesn't work
at all for omf atm).


 But a TypeInfo instance should belong to the module of the described Type.
 I hope that we can remove the hack if we fix that behavior and assert
 s->getModule.


The problem also exists for derived types like const(Struct) or Struct* (maybe
also for basic types?). You cannot generate all possible types into the module
itself (and you might not have it compiled anyway if the declaration is only in
a di file). E.g. for const(Struct) you'll have to at least generate the
TypeInfo_Const that refers to TypeInfo_Struct somewhere into the current
compiler output.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 31 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6461








 IIRC TypeInfo instances were the only symbols where s->getModule() returns
 NULL.


 
 I had the impression that the init-data has the same problem, but I could also
 have been confused by other issues (the multiobj library creation doesn't work
 at all for omf atm).
 

 But a TypeInfo instance should belong to the module of the described Type.
 I hope that we can remove the hack if we fix that behavior and assert
 s->getModule.


 
 The problem also exists for derived types like const(Struct) or Struct* (maybe
 also for basic types?). You cannot generate all possible types into the module
 itself (and you might not have it compiled anyway if the declaration is only in
 a di file). E.g. for const(Struct) you'll have to at least generate the
 TypeInfo_Const that refers to TypeInfo_Struct somewhere into the current
 compiler output.


True, but wouldn't it still make sense to emit these into a doppelgänger module
of the original module? One problem is, that this required linking against the
original module, because it references assert etc.

As this only seems to happen with data we don't actually need the module
functions, so we could omit them.
Also emitting them to a doppelgänger of a special anonymous module would make
more sense than to reuse the last filename.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 31 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6461


Denis Shelomovskij <verylonglogin.reg gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P2                          |P1
           Severity|major                       |critical



2013-06-04 22:15:14 MSD ---
Partial workaround:
One can try to detrigger the issue by minimizing module count i.e. for
`mylib.*` library which forces you projects to fail building create `mylib_all`
module with copied contents of all library files and replace `import mylib.`
with `import mylib_all; //mylib.` for easy replacing back once the issue is
fixed.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 04 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6461


Walter Bright <bugzilla digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla digitalmars.com
           Platform|Other                       |All
            Version|D2                          |D1 & D2



02:41:42 PDT ---
https://github.com/D-Programming-Language/dmd/pull/2151

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 09 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6461




2013-06-10 10:23:08 MSD ---
Created an attachment (id=1221)
Testcase

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 09 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6461




22:48:22 PDT ---
https://github.com/D-Programming-Language/dmd/pull/2201

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 26 2013
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6461


Denis Shelomovskij <verylonglogin.reg gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED



2013-06-27 11:10:37 MSD ---


-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 27 2013