<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 11 May 2013 12:50, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Am Thu, 09 May 2013 19:40:04 +0200<br>
<div><div class="h5">schrieb "Iain Buclaw" <<a href="mailto:ibuclaw@ubuntu.com">ibuclaw@ubuntu.com</a>>:<br>
<br>
> On Wednesday, 8 May 2013 at 11:34:19 UTC, Iain Buclaw wrote:<br>
> > On 24 April 2013 15:12, Iain Buclaw <<a href="mailto:ibuclaw@ubuntu.com">ibuclaw@ubuntu.com</a>> wrote:<br>
> ><br>
> >> On 23 April 2013 18:25, Iain Buclaw <<a href="mailto:ibuclaw@ubuntu.com">ibuclaw@ubuntu.com</a>> wrote:<br>
> >><br>
> >>> On 23 April 2013 17:28, Johannes Pfau <<a href="mailto:nospam@example.com">nospam@example.com</a>><br>
> >>> wrote:<br>
> >>><br>
> >>>> Am Tue, 23 Apr 2013 17:10:43 +0200<br>
> >>>> schrieb "Iain Buclaw" <<a href="mailto:ibuclaw@ubuntu.com">ibuclaw@ubuntu.com</a>>:<br>
> >>>><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<br>
> >>>> > in the<br>
> >>>> > following pull (with the intention to merge back upstream<br>
> >>>> > 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>
> >>>> I'll make sure to have a look at this, but as always too<br>
> >>>> little time...<br>
> >>>><br>
> >>>> > In order:<br>
> >>>> ><br>
> >>>> > 1. ClassInfo<br>
> >>>> ><br>
> >>>> > The initialiser emitted will have two symbols, one public<br>
> >>>> > symbol<br>
> >>>> > with the TypeInfo_Class members, and a second private<br>
> >>>> > generated<br>
> >>>> > symbol for the interfaces array.  I can't forsee any way<br>
> >>>> > this<br>
> >>>> > could break compatibility with any existing compilied gdc<br>
> >>>> > (or<br>
> >>>> > perhaps even dmd/ldc) binaries out there.<br>
> >>>><br>
> >>>> Sounds good. That should also be good for debug info.<br>
> >>>><br>
> >>>><br>
> >>> 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'<br>
> >>> from Object<br>
> >>> 'this'  <--<br>
> >>> }<br>
> >>> ---<br>
> >>><br>
> >>> I'll have to have a think about what value should be put<br>
> >>> there, and how<br>
> >>> best to put it in.<br>
> >>><br>
> >>><br>
> >><br>
> >> Or alternatively we could generate the type (for debugging) on<br>
> >> the flying<br>
> >> in ::toSymbol<br>
> >><br>
> >> 1.  Module::toSymbol.<br>
> >><br>
> >> Type = Type::moduleinfo type.<br>
> >><br>
> >><br>
> >> 2. ClassDeclaration::toSymbol<br>
> >><br>
> >> Type = Type::typeinfoclass type.<br>
> >><br>
> >> Then for each interface, add the fields for Type::interface<br>
> >> onto the type.<br>
> >><br>
> >><br>
> >> 3. InterfaceDeclaration::toSymbol<br>
> >><br>
> >> Likewise to above.<br>
> >><br>
> >><br>
> > For the time being in this pull:<br>
> ><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>
> > For ModuleInfo, TypeInfoClass and Interface classes, I have<br>
> > added a new<br>
> > kind of type node into the glue layer.<br>
> ><br>
> > - d_unknown_type_node: LANG_TYPE<br>
> ><br>
> > This means that the backend won't touch, or do any sort of<br>
> > laying out of<br>
> > the type.<br>
> ><br>
> > If we find this type in d_finalize_symbol  (formerly called<br>
> > outdata), then<br>
> > we give it the compiler generated type of the initialiser, and<br>
> > for debug<br>
> > purposes give it an eponymous type name  (eg:<br>
> > _Dobject_ModuleInfoZ symbol<br>
> > has type name struct _Dobject_ModuleInfoZ).<br>
> ><br>
> > This is fine for the workaround so far, but future improvements<br>
> > would be to<br>
> > take the logic from toObjFile / genmoduleinfo and give the<br>
> > fields the<br>
> > correct names when generating the symbol in toSymbol.<br>
> ><br>
> > Alternatively we could store this information within Symbol<br>
> > itself during<br>
> > the toObjFile / genmoduleinfo stage, and have d_finalize_symbol<br>
> > call a<br>
> > routine that will generate the correct type layout to prevent<br>
> > code<br>
> > duplication.<br>
> ><br>
> ><br>
><br>
><br>
> Also, I have altered the mismatch check in d_finalize_symbol<br>
> (outdata) that you put in initially for this fix.  Now it asserts<br>
> that type_size == initialiser_type_size.<br>
><br>
> This passes through the testsuite 100%, so I'll keep it.  There<br>
> should be no reason whatsoever why the initialiser would be less<br>
> than the type size.<br>
><br>
<br>
</div></div>If it passes the testsuite then there is indeed no reason not to change<br>
it. Not sure why I made it check for >= in the first place.<br>
</blockquote></div><br></div><div class="gmail_extra">If decl_initial size  < type size. Then the backend will always automatically pad out the end with zeroes.<br></div><div class="gmail_extra"><br clear="all"><br>-- <br>
Iain Buclaw<br><br>*(p < e ? p++ : p) = (c & 0x0f) + '0';
</div></div>