libphobos on ARM

[Iain Buclaw]

On 13 June 2012 15:44, Johannes Pfau <nospam at example.com> wrote:
> Am Mon, 11 Jun 2012 18:30:37 +0100
> schrieb Iain Buclaw <ibuclaw at ubuntu.com>:
>>
>> There are two things under my general consensus for this:
>>
>> 1. would be to re-implement dfrontend/todt.c entirely, so that we
>> produce GCC trees directly from the toDt routines, rather than the
>> dmd's intermediate backend representation and later blindly converting
>> to GCC after all information about the type size is finalised.
>>
>> 2. would be to review the current implementation of how we record
>> inheritance in classes and fix it up where possible to utilise the
>> already existing macros in place to hold information about type
>> inheritance and basetypes for the backend to better understand what
>> information we are sending it.
>
> I'm not very familiar with the GDC glue code yet, but I'm not sure if 1
> would help in this case.
>
> The problem is that ClassDeclaration::toSymbol() in d-decls.cc uses
> ClassDeclaration::classinfo->type->toCtype() to generate it's Stree
> field and therefore uses size = 76.
> Then outdata (in d-objfile.cc) calls check_static_sym which returns
> this Stree(size = 76). outdata the sets DECL_INITIAL(t) =
> dt2tree(sym->Sdt), and this dt2tree result produces data with size =
> 108.
>
> Now if we kept the initializer sym->Sdt as a tree instead of the dt*
> list stuff, we could still have size mismatches. So while getting rid
> of the intermediary dt_t representation sure has lots of other
> benefits, I don't see how it could be useful in this case. We'd have to
> somehow combine the dt_t creation (in this case it's actually not toDt,
> it's ClassDeclaration::toObjFile which creates the dt_t list) and
> ClassDeclaration::toSymbol() to really avoid this problem, but that's
> probably a lot of work.
>
>

I can check this, but the side of the issue when I checked some time
ago I saw was that the initialiser is a typeless constructor that is
raw casted into the type we are assigning it to, so one bad factor of
that is we are relying on the member layout to match what was created
by toDt.



> 2 seems like it probably wouldn't be ABI compatible to dmd. I don't
> care if we break ABI compatibility, just wanted to mention that.
>
>

2 is more for better debug information for a class and interface
declaration's inheritance tree.  Ever notice that you can't access
methods through the debugger, lest you want to ICE gdb? :-)

There's a little bit of cludge and cleanup needed around that code
area anyway, so it's on my TODO.


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';