-fsection-anchors broken on ARM

[Iain Buclaw]

On 24 April 2013 15:12, Iain Buclaw <ibuclaw at ubuntu.com> wrote:

> On 23 April 2013 18:25, Iain Buclaw <ibuclaw at ubuntu.com> wrote:
>
>> On 23 April 2013 17:28, Johannes Pfau <nospam at example.com> wrote:
>>
>>> Am Tue, 23 Apr 2013 17:10:43 +0200
>>> schrieb "Iain Buclaw" <ibuclaw at ubuntu.com>:
>>>
>>> > In reference to this link:
>>> > http://forum.dlang.org/post/50476C77.20608@googlemail.com
>>> >
>>> >
>>> > I'm currently working on dealing with each of these issues in the
>>> > following pull (with the intention to merge back upstream where
>>> > required).
>>> > https://github.com/D-Programming-GDC/GDC/pull/62
>>> >
>>> I'll make sure to have a look at this, but as always too little time...
>>>
>>> > In order:
>>> >
>>> > 1. ClassInfo
>>> >
>>> > The initialiser emitted will have two symbols, one public symbol
>>> > with the TypeInfo_Class members, and a second private generated
>>> > symbol for the interfaces array.  I can't forsee any way this
>>> > could break compatibility with any existing compilied gdc (or
>>> > perhaps even dmd/ldc) binaries out there.
>>>
>>> Sounds good. That should also be good for debug info.
>>>
>>>
>> Actually, found an interesting problem when confronting it.
>>
>> ---
>> struct Interface
>> {
>>     TypeInfo_Class   classinfo;
>>     void*[]     vtbl;
>>     ptrdiff_t   offset;     /// offset to Interface 'this' from Object
>> 'this'  <--
>> }
>> ---
>>
>> I'll have to have a think about what value should be put there, and how
>> best to put it in.
>>
>>
>
> Or alternatively we could generate the type (for debugging) on the flying
> in ::toSymbol
>
> 1.  Module::toSymbol.
>
> Type = Type::moduleinfo type.
>
>
> 2. ClassDeclaration::toSymbol
>
> Type = Type::typeinfoclass type.
>
> Then for each interface, add the fields for Type::interface onto the type.
>
>
> 3. InterfaceDeclaration::toSymbol
>
> Likewise to above.
>
>
For the time being in this pull:

https://github.com/D-Programming-GDC/GDC/pull/62

For ModuleInfo, TypeInfoClass and Interface classes, I have added a new
kind of type node into the glue layer.

- d_unknown_type_node: LANG_TYPE

This means that the backend won't touch, or do any sort of laying out of
the type.

If we find this type in d_finalize_symbol  (formerly called outdata), then
we give it the compiler generated type of the initialiser, and for debug
purposes give it an eponymous type name  (eg:  _Dobject_ModuleInfoZ symbol
has type name struct _Dobject_ModuleInfoZ).

This is fine for the workaround so far, but future improvements would be to
take the logic from toObjFile / genmoduleinfo and give the fields the
correct names when generating the symbol in toSymbol.

Alternatively we could store this information within Symbol itself during
the toObjFile / genmoduleinfo stage, and have d_finalize_symbol call a
routine that will generate the correct type layout to prevent code
duplication.


Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/d.gnu/attachments/20130508/afd99798/attachment.html>