On 13 June 2012 15:44, Johannes Pfau <nospam@example.com> wrote:
> Am Mon, 11 Jun 2012 18:30:37 +0100
> schrieb Iain Buclaw <ibuclaw@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';

Am Wed, 13 Jun 2012 17:24:18 +0100
schrieb Iain Buclaw <ibuclaw@ubuntu.com>:


> 
> 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.

So DECL_INITIAL would do a type check? That would detect size mismatches of course and is probably a good idea.

> 
> > 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.

I haven't looked at GCCs inheritance implementation for C++ yet, maybe it's even possible to stay ABI compatible to dmd? Would be good to keep at least ClassInfo (as declared in druntime) consistent.