Am Thu, 09 May 2013 19:40:04 +0200 schrieb "Iain Buclaw" <ibuc...@ubuntu.com>:
> On Wednesday, 8 May 2013 at 11:34:19 UTC, Iain Buclaw wrote: > > On 24 April 2013 15:12, Iain Buclaw <ibuc...@ubuntu.com> wrote: > > > >> On 23 April 2013 18:25, Iain Buclaw <ibuc...@ubuntu.com> wrote: > >> > >>> On 23 April 2013 17:28, Johannes Pfau <nos...@example.com> > >>> wrote: > >>> > >>>> Am Tue, 23 Apr 2013 17:10:43 +0200 > >>>> schrieb "Iain Buclaw" <ibuc...@ubuntu.com>: > >>>> > >>>> > In reference to this link: > >>>> > http://forum.dlang.org/post/50476c77.20...@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.
