typeid expression causes typeInfo to be duplicated

[dlangBugzillaToGithub]

Benjamin Thaut (@bethau) reported this on 2018-01-30T19:55:53Z

Transferred from https://issues.dlang.org/show_bug.cgi?id=18338

CC List

• kinke

Description

Created attachment 1678
Repro case

In the attached repro case, when compiling test.d via:
dmd -m64 test.d -c

The TypeInfo for file.DirEntry ( _D24TypeInfo_S4file8DirEntry6__initZ) will be emitted into the object file even though its never used in test.d

This is a problem when file.d is build into a dll. Because this results in a duplication of the type info. As a result cross dll casts and throws and all other type info related operations may fail.

The cause is the typeid expression in file.d. As soon as the compiler encounters a typeid expression it will instanciate the typeinfo for this type even if the typeid expression is in a non root module. Typeid expressions should only instanciate the type info if the typeid expression is part of a root module.

!!!There are attachements in the bugzilla issue that have not been copied over!!!

[dlangBugzillaToGithub]

kinke commented on 2018-01-30T21:26:24Z

(In reply to Benjamin Thaut from comment #0)
> Typeid expressions should only instanciate the type info
> if the typeid expression is part of a root module.

I guess that's not enough for a shared `typeid(SomeSharedType)` expression in both a root module of the DLL and in a root module of the other lib/executable. There probably has to be a clear ownership by emitting the TypeInfo and its helper functions once in the declaring/template-instantiating module/object.

How are colliding TypeInfo symbols across shared objects handled on Linux?

[dlangBugzillaToGithub]

code (@MartinNowak) commented on 2018-02-01T20:17:33Z

(In reply to kinke from comment #1)
> 
> I guess that's not enough for a shared `typeid(SomeSharedType)` expression
> in both a root module of the DLL and in a root module of the other
> lib/executable. There probably has to be a clear ownership by emitting the
> TypeInfo and its helper functions once in the
> declaring/template-instantiating module/object.
> 
> How are colliding TypeInfo symbols across shared objects handled on Linux?

The linux shared library mechanism automatically deduplicates duplicated symbols. For linux both the symbol name binding and the address resolving happens at binary load time. For linux the symbol name binding happens at link time and only the address resloving happens at load time. As a result the windows shared library mechanism doesn't deduplicate symbols.

The critical part is that the type infos for all user defined types (structs / classes / enums etc) have a clear ownership. E.g. are always emitted alongside the definition of the user defined type. Because these are what is used for casts and other type info critical operations. Other type info such as const array etc can be duplicated without impact.

The bug here really is though that the typeinfo will be emitted twice due to the typeid statement. Once when compiling file.d and once when compiling test.d. Emitting it while compiling test.d is a bug in my opinion.