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