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. Regards -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
