Am Thu, 09 May 2013 19:40:04 +0200

schrieb "Iain Buclaw" <ibuclaw@ubuntu.com>:

> On Wednesday, 8 May 2013 at 11:34:19 UTC, Iain Buclaw wrote:
> > On 24 April 2013 15:12, Iain Buclaw <ibuclaw@ubuntu.com> wrote:
> >
> >> On 23 April 2013 18:25, Iain Buclaw <ibuclaw@ubuntu.com> wrote:
> >>
> >>> On 23 April 2013 17:28, Johannes Pfau <nospam@example.com>
> >>> wrote:
> >>>
> >>>> Am Tue, 23 Apr 2013 17:10:43 +0200
> >>>> schrieb "Iain Buclaw" <ibuclaw@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.
>

If it passes the testsuite then there is indeed no reason not to change
it. Not sure why I made it check for >= in the first place.