Hitchikers Guide to Porting Phobos / D Runtime to other architectures

[Iain Buclaw]

On 8 January 2014 12:14, Iain Buclaw <ibuclaw at gdcproject.org> wrote:
> 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.

s/struct/structure/