-fsection-anchors broken on ARM

[Iain Buclaw]

On Wednesday, 8 May 2013 at 11:34:19 UTC, Iain Buclaw wrote:
> 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.
>
>


Also, I have altered the mismatch check in d_finalize_symbol 
(outdata) that you put in initially for this fix.  Now it asserts 
that type_size == initialiser_type_size.

This passes through the testsuite 100%, so I'll keep it.  There 
should be no reason whatsoever why the initialiser would be less 
than the type size.

Regards
Iain