On 11 May 2013 12:50, Johannes Pfau <nos...@example.com> wrote: > 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. >
If decl_initial size < type size. Then the backend will always automatically pad out the end with zeroes. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
