Hitchikers Guide to Porting Phobos / D Runtime to other architectures

[Iain Buclaw]

On 8 January 2014 12:13, Iain Buclaw <ibuclaw at gdcproject.org> wrote:
> On 8 January 2014 11:13, Mike <none at none.com> wrote:
>> On Wednesday, 8 January 2014 at 01:15:45 UTC, Iain Buclaw wrote:
>>>>
>>>> Anyway, once you add the word "class" or "struct" you release an
>>>> avalanche
>>>> of snowballing required runtime stuff that you are likely not even using,
>>>> directly or indirectly, in your program. And if using --gc-sections in
>>>> your
>>>> linker, it all just gets stripped out in the end. I was trying to
>>>> articulate
>>>> that here
>>>> (http://forum.dlang.org/post/zewevdmburppufkjxdje@forum.dlang.org)
>>>>
>>>
>>> If you use a struct, it generates typeinfo and initialiser symbols
>>> that go on the comdat on the basis that you *may* access the typeinfo
>>> at runtime.
>>>
>>> These are weak decls so the linker merges/removes duplicates.  There's
>>> currently no solution in which the compiler decides whether to omit
>>> sending the symbols to object file, but this can be worked upon.
>>>
>>
>> Thanks Iain, things are starting to make sense.
>>
>> Can't the compiler just emit whatever the runtime provides for the TypeInfo
>> stuff, right or wrong?  So, if the runtime does not provide a TypeInfo_x
>> implementation, it doesn't emit one.  If the runtime does provide a
>> TypeInfo_x, it emits exactly what the runtime provided, right or wrong.
>>
>> If the program provides a faulty TypeInfo_x implementation, the program
>> behaves in a faulty manner, just as the programmer specified.
>>
>> If the program references a missing TypeInfo_x (or one of it's properties)
>> implicitly/indirectly, the linker will emit and undefined reference error,
>> won't it?
>>
>> Is this implementation possible?
>>
>>
>
> Half and half. The TypeInfo support code is a separation layer between
> runtime and compiler and the compiler is not fully aware of what is
> implemented by runtime.
>
> On the one hand, there's the internal TypeInfo you see in object.d,
> these are required to be known at compile time for certain operations.
>  If those aren't present then you'll get mismatch errors from the
> compiler, and in the case of GDC, a handy little ICE to end the
> compilation immediately.
>
> On the other hand there's the TypeInfo support under rt.typeinfo (eg:
> TypeInfo_AC).  For these, only the symbol is generated by the compiler
> on the fly and referenced as 'extern'. So you get linker errors if
> they aren't implemented.
>
> This is why I suggested the 'all or nothing' approach.

Note, the struct of the internal TypeInfo symbols are known at compile
time because object.d is implicitly imported.