kris wrote:
> Walter Bright wrote:
>> kris wrote:
>>
>>> _D12TypeInfo_AAa6__initZ    COMDAT flags=x0 attr=x10 align=x0
>>
>>
>> TypeInfo's don't get the module prefix because it would cause duplication of code (i.e. bloat) to have it that way. There is no difference between the TypeInfo for char[][] in one module, and the TypeInfo for char[][] in another, so the TypeInfo names should match exactly.
> 
> well, ok ... but it is responsible for what happened here? If not, what is?

From your description, the linker is looking to resolve a reference to the TypeInfo for char[][], and found that module first.

kris wrote:
> Perhaps a question is this: why the heck is that symbol exposed from Core, when it should instead be exposed via the TypeInfo class for char[][] instead ... linked via the TypeInfo classes in Object.d? A large number of those are present in every D executable.

The standard TypeInfo's in Phobos cover only basic types and arrays of basic types. The rest are generated by the compiler.

Sean Kelly wrote:
> For some reason I thought an optimizing linker worked at a segment level, but I suppose that is not true for data in a library?  In other words, since libraries are indexed by module name, I suppose this means they are necessarily dealt with at module granularity instead?

The linker works at the .obj file level.

Walter Bright wrote:
> kris wrote:
> 
>> Walter Bright wrote:
>>
>>> kris wrote:
>>>
>>>> _D12TypeInfo_AAa6__initZ    COMDAT flags=x0 attr=x10 align=x0
>>>
>>>
>>>
>>> TypeInfo's don't get the module prefix because it would cause duplication of code (i.e. bloat) to have it that way. There is no difference between the TypeInfo for char[][] in one module, and the TypeInfo for char[][] in another, so the TypeInfo names should match exactly.
>>
>>
>> well, ok ... but it is responsible for what happened here? If not, what is?
> 
> 
>  From your description, the linker is looking to resolve a reference to the TypeInfo for char[][], and found that module first.


That's exactly what it looks like. Would you agree the results could be described as haphazard? The outcome here certainly has that feeling to it :)

It also finds that particular one whether the module is listed first or last in the lib response-file.

What is one supposed to do for production-quality libraries?

Walter Bright wrote:
> kris wrote:
> 
>> Perhaps a question is this: why the heck is that symbol exposed from Core, when it should instead be exposed via the TypeInfo class for char[][] instead ... linked via the TypeInfo classes in Object.d? A large number of those are present in every D executable.
> 
> 
> The standard TypeInfo's in Phobos cover only basic types and arrays of basic types. The rest are generated by the compiler.

Yep, I've seen that to be the case. However, the current strategy clearly leads to a somewhat haphazard mechanism for resolving such symbols: in this case, the exe is dogged by a suite of code that it doesn't want or need ... all for the sake of a typedef init?

Sure, we don't want such things being replicated all over the place, but I think it has been shown that the current approach is unrealistic in practice.

Isn't there some way to isolate the typeinfo such that only a segment is linked, rather than the entire "hosting" module (the one that just happened to be found first in the lib) ?

kris wrote:
> Isn't there some way to isolate the typeinfo such that only a segment is linked, rather than the entire "hosting" module (the one that just happened to be found first in the lib) ?

The obvious solution would be to always generate typeinfo even if it can be determined imported modules will already supply it. The current approach seems to confuse the linker, causing it to link in unrelated objects that happen to supply the symbol even though the compiler "meant" for another object file to supply it.

Yes, that will "bloat" object files, but the current approach apparently bloats applications. Care to guess which are distributed most often? ;)

Walter Bright wrote:
> Sean Kelly wrote:
>> For some reason I thought an optimizing linker worked at a segment level, but I suppose that is not true for data in a library?  In other words, since libraries are indexed by module name, I suppose this means they are necessarily dealt with at module granularity instead?
> 
> The linker works at the .obj file level.

GNU ld seems to be perfectly happy working at the section level (with --gc-sections).

Frits van Bommel wrote:
> kris wrote:
>> Isn't there some way to isolate the typeinfo such that only a segment is linked, rather than the entire "hosting" module (the one that just happened to be found first in the lib) ?

No, the linker deals with .obj files as a unit.

> The obvious solution would be to always generate typeinfo even if it can be determined imported modules will already supply it. The current approach seems to confuse the linker, causing it to link in unrelated objects that happen to supply the symbol even though the compiler "meant" for another object file to supply it.

I wish to be precise - there is no "seems" or "confuse" with linking. It simply follows the algorithm I outlined previously - have an unresolved symbol, find the first .obj module in the library which resolves it. It does this in a loop until there are no further unreferenced symbols.

Most of the complexity in a linker stems from:

1) trying to make it fast
2) the over-complicated .obj file format

Conceptually, it is a very simple program.

> Yes, that will "bloat" object files, but the current approach apparently bloats applications. Care to guess which are distributed most often? ;)

TypeInfo's are only going to grow, and this could create gigantic obj files.

kris wrote:
> It also finds that particular one whether the module is listed first or last in the lib response-file.

I bet that's because that module was imported (directly or indirectly) by every other module that used char[][], and so it was the only module that defines it.

> What is one supposed to do for production-quality libraries?

Some strategies:

1) minimize importing of modules that are never used

2) for modules with a lot of code in them, import them as a .di file rather than a .d

3) create a separate module that defines the relevant typeinfo's, and put that first in the library

Frits van Bommel wrote:
> GNU ld seems to be perfectly happy working at the section level (with --gc-sections).

Yeah, well, try linking D programs with --gc-sections, and you'll get a crashing executable.