<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 24 April 2013 15:12, Iain Buclaw <span dir="ltr"><<a href="mailto:ibuclaw@ubuntu.com" target="_blank">ibuclaw@ubuntu.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr"><div><div class="h5"><div class="gmail_extra"><div class="gmail_quote">On 23 April 2013 18:25, Iain Buclaw <span dir="ltr"><<a href="mailto:ibuclaw@ubuntu.com" target="_blank">ibuclaw@ubuntu.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr"><div><div class="gmail_extra"><div class="gmail_quote">On 23 April 2013 17:28, Johannes Pfau <span dir="ltr"><<a href="mailto:nospam@example.com" target="_blank">nospam@example.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Am Tue, 23 Apr 2013 17:10:43 +0200<br>
schrieb "Iain Buclaw" <<a href="mailto:ibuclaw@ubuntu.com" target="_blank">ibuclaw@ubuntu.com</a>>:<br>
<div><br>
> In reference to this link:<br>
> <a href="http://forum.dlang.org/post/50476C77.20608@googlemail.com" target="_blank">http://forum.dlang.org/post/50476C77.20608@googlemail.com</a><br>
><br>
><br>
> I'm currently working on dealing with each of these issues in the<br>
> following pull (with the intention to merge back upstream where<br>
> required).<br>
> <a href="https://github.com/D-Programming-GDC/GDC/pull/62" target="_blank">https://github.com/D-Programming-GDC/GDC/pull/62</a><br>
><br>
</div>I'll make sure to have a look at this, but as always too little time...<br>
<div><br>
> In order:<br>
><br>
> 1. ClassInfo<br>
><br>
> The initialiser emitted will have two symbols, one public symbol<br>
> with the TypeInfo_Class members, and a second private generated<br>
> symbol for the interfaces array. I can't forsee any way this<br>
> could break compatibility with any existing compilied gdc (or<br>
> perhaps even dmd/ldc) binaries out there.<br>
<br>
</div>Sounds good. That should also be good for debug info.<br><br>
</blockquote></div><br></div></div><div class="gmail_extra">Actually, found an interesting problem when confronting it.<br><br>---<br>struct Interface<br>{<br> TypeInfo_Class classinfo;<br> void*[] vtbl;<br> ptrdiff_t offset; /// offset to Interface 'this' from Object 'this' <--<br>
}<br>---<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">I'll have to have a think about what value should be put there, and how best to put it in.<span><font color="#888888"><br></font></span></div>
<span><font color="#888888"><div class="gmail_extra"><br></div></font></span></div></blockquote></div><br><br></div></div></div><div class="gmail_extra">Or alternatively we could generate the type (for debugging) on the flying in ::toSymbol<br>
<br></div><div class="gmail_extra">1. Module::toSymbol.<br><br></div><div class="gmail_extra">Type = Type::moduleinfo type.<br></div><div class="gmail_extra"><br><br></div><div class="gmail_extra">2. ClassDeclaration::toSymbol<br>
</div><div class="gmail_extra"><br></div><div class="gmail_extra">Type = Type::typeinfoclass type.<br><br></div><div class="gmail_extra">Then for each interface, add the fields for Type::interface onto the type.<br></div>
<br><br>3. InterfaceDeclaration::toSymbol<br><div class="gmail_extra"><br></div><div class="gmail_extra">Likewise to above.<br></div><div class="gmail_extra"></div><div class="gmail_extra"><br></div></div></blockquote></div>
<br></div><div class="gmail_extra">For the time being in this pull:<br><br><a href="https://github.com/D-Programming-GDC/GDC/pull/62">https://github.com/D-Programming-GDC/GDC/pull/62</a><br><br></div><div class="gmail_extra">
For ModuleInfo, TypeInfoClass and Interface classes, I have added a new kind of type node into the glue layer.<br><br></div><div class="gmail_extra">- d_unknown_type_node: LANG_TYPE<br><br></div><div class="gmail_extra">This means that the backend won't touch, or do any sort of laying out of the type.<br>
<br></div><div class="gmail_extra">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).<br>
<br></div><div class="gmail_extra">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.<br>
<br>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.<br>
</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Regards<br></div><div class="gmail_extra">-- <br>Iain Buclaw<br><br>*(p < e ? p++ : p) = (c & 0x0f) + '0';
</div></div>