www.digitalmars.com         C & C++   DMDScript  

D.gnu - Re: -fsection-anchors broken on ARM

reply "Iain Buclaw" <ibuclaw ubuntu.com> writes:
In reference to this link:
http://forum.dlang.org/post/50476C77.20608 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

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.


2. TypeInfoStruct

Likewise to the above.


3. ModuleInfo

We can get the correct type as is defined in object.di through 
Module::moduleinfo, this would mean that all generated moduleinfo 
symbols will be the same size (rather than be of a variable size) 
padded out with zeros at the end.  However, this requires a 
front-end patch to store it as there is an implementation 
conflict because of MODULEINFO_IS_STRUCT macro, the type is a 
StructDeclaration (Module::moduleinfo is a ClassDeclaration type).

Going one step further, the type itself could probably be put up 
for a clean up.  Removing the struct New/Old implementation 
(keeping the 'New' for getting data members) and perhaps replace 
it something like the following.

struct ModuleInfo
{
   uint flags;           // Module flags
   uint index;           // Index into moduleinfo array
   void*[14] reserved;   // Padding large enough to contain
                         // all optional data added depending on 
flags.
}

This however is not really required, but am just throughing it 
out there as a thought.


Any thoughts on this?  (Looking at you Johannes).

Regards
Iain
Apr 23 2013
next sibling parent Johannes Pfau <nospam example.com> writes:
Am Tue, 23 Apr 2013 17:10:43 +0200
schrieb "Iain Buclaw" <ibuclaw ubuntu.com>:

 In reference to this link:
 http://forum.dlang.org/post/50476C77.20608 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
 

 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.
 
 
 2. TypeInfoStruct
 
 Likewise to the above.

The situation here is a little different AFAIR. TypeInfoStruct has no interfaces array or something similar, it only had a variable size because the name data was part of the TypeInfoStruct type. Now name is just stored as a slice and the data is stored in a custom symbol. So the TypeInfoStruct size is fixed and there's no need to do anything special about it. https://github.com/D-Programming-Language/dmd/pull/1128/files
 
 
 3. ModuleInfo
 
 We can get the correct type as is defined in object.di through 
 Module::moduleinfo, this would mean that all generated moduleinfo 
 symbols will be the same size (rather than be of a variable size) 
 padded out with zeros at the end.  However, this requires a 
 front-end patch to store it as there is an implementation 
 conflict because of MODULEINFO_IS_STRUCT macro, the type is a 
 StructDeclaration (Module::moduleinfo is a ClassDeclaration type).
 
 Going one step further, the type itself could probably be put up 
 for a clean up.  Removing the struct New/Old implementation 
 (keeping the 'New' for getting data members) and perhaps replace 
 it something like the following.
 
 struct ModuleInfo
 {
    uint flags;           // Module flags
    uint index;           // Index into moduleinfo array
    void*[14] reserved;   // Padding large enough to contain
                          // all optional data added depending on 
 flags.
 }
 
 This however is not really required, but am just throughing it 
 out there as a thought.

ModuleInfo could really need a cleanup, sounds good.
 
 
 Any thoughts on this?  (Looking at you Johannes).
 
 Regards
 Iain

Everything sounds good so far. As far as I can tell the workarounds we implemented some time ago work fine, but it would certainly be good to implement the proper fixes. Maybe we can revert some of this code after this fix: git log --grep=fsection-anchors
Apr 23 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
--047d7b6d86c40ef51304db0a799a
Content-Type: text/plain; charset=ISO-8859-1

On 23 April 2013 17:28, Johannes Pfau <nospam example.com> wrote:

 Am Tue, 23 Apr 2013 17:10:43 +0200
 schrieb "Iain Buclaw" <ibuclaw ubuntu.com>:

 In reference to this link:
 http://forum.dlang.org/post/50476C77.20608 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

 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.

--- 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. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0'; --047d7b6d86c40ef51304db0a799a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 2= 3 April 2013 17:28, Johannes Pfau <span dir=3D"ltr">&lt;<a href=3D"mailto:n= ospam example.com" target=3D"_blank">nospam example.com</a>&gt;</span> wrot= e:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b= order-left:1px solid rgb(204,204,204);padding-left:1ex"> Am Tue, 23 Apr 2013 17:10:43 +0200<br> schrieb &quot;Iain Buclaw&quot; &lt;<a href=3D"mailto:ibuclaw ubuntu.com">i= buclaw ubuntu.com</a>&gt;:<br> <div class=3D"im"><br> &gt; In reference to this link:<br> &gt; <a href=3D"http://forum.dlang.org/post/50476C77.20608 googlemail.com" = target=3D"_blank">http://forum.dlang.org/post/50476C77.20608 googlemail.com= </a><br> &gt;<br> &gt;<br> &gt; I&#39;m currently working on dealing with each of these issues in the<= br> &gt; following pull (with the intention to merge back upstream where<br> &gt; required).<br> &gt; <a href=3D"https://github.com/D-Programming-GDC/GDC/pull/62" target=3D= "_blank">https://github.com/D-Programming-GDC/GDC/pull/62</a><br> &gt;<br> </div>I&#39;ll make sure to have a look at this, but as always too little t= ime...<br> <div class=3D"im"><br> &gt; In order:<br> &gt;<br> &gt; 1. ClassInfo<br> &gt;<br> &gt; The initialiser emitted will have two symbols, one public symbol<br> &gt; with the TypeInfo_Class members, and a second private generated<br> &gt; symbol for the interfaces array. =A0I can&#39;t forsee any way this<br=

&gt; 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 class=3D"gmail_extra">Actually, found an = interesting problem when confronting it.<br><br>---<br>struct Interface<br>= {<br>=A0=A0=A0 TypeInfo_Class=A0=A0 classinfo;<br>=A0=A0=A0 void*[]=A0=A0= =A0=A0 vtbl;<br>=A0=A0=A0 ptrdiff_t=A0=A0 offset;=A0=A0=A0=A0 /// offset to= Interface &#39;this&#39; from Object &#39;this&#39;=A0 &lt;--<br> }<br>---<br></div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_= extra">I&#39;ll have to have a think about what value should be put there, = and how best to put it in.<br></div><div class=3D"gmail_extra"><br>-- <br>I= ain Buclaw<br> <br>*(p &lt; e ? p++ : p) =3D (c &amp; 0x0f) + &#39;0&#39;; </div></div> --047d7b6d86c40ef51304db0a799a--
Apr 23 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
--047d7bdca7c21c084204db1be37d
Content-Type: text/plain; charset=ISO-8859-1

On 23 April 2013 18:25, Iain Buclaw <ibuclaw ubuntu.com> wrote:

 On 23 April 2013 17:28, Johannes Pfau <nospam example.com> wrote:

 Am Tue, 23 Apr 2013 17:10:43 +0200
 schrieb "Iain Buclaw" <ibuclaw ubuntu.com>:

 In reference to this link:
 http://forum.dlang.org/post/50476C77.20608 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

 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.

--- 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. Regards -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0'; --047d7bdca7c21c084204db1be37d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 2= 3 April 2013 18:25, Iain Buclaw <span dir=3D"ltr">&lt;<a href=3D"mailto:ibu= claw ubuntu.com" target=3D"_blank">ibuclaw ubuntu.com</a>&gt;</span> wrote:= <br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor= der-left:1px solid rgb(204,204,204);padding-left:1ex"> <div dir=3D"ltr"><div class=3D"im"><div class=3D"gmail_extra"><div class=3D= "gmail_quote">On 23 April 2013 17:28, Johannes Pfau <span dir=3D"ltr">&lt;<= a href=3D"mailto:nospam example.com" target=3D"_blank">nospam example.com</= a>&gt;</span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"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 &quot;Iain Buclaw&quot; &lt;<a href=3D"mailto:ibuclaw ubuntu.com" t= arget=3D"_blank">ibuclaw ubuntu.com</a>&gt;:<br> <div><br> &gt; In reference to this link:<br> &gt; <a href=3D"http://forum.dlang.org/post/50476C77.20608 googlemail.com" = target=3D"_blank">http://forum.dlang.org/post/50476C77.20608 googlemail.com= </a><br> &gt;<br> &gt;<br> &gt; I&#39;m currently working on dealing with each of these issues in the<= br> &gt; following pull (with the intention to merge back upstream where<br> &gt; required).<br> &gt; <a href=3D"https://github.com/D-Programming-GDC/GDC/pull/62" target=3D= "_blank">https://github.com/D-Programming-GDC/GDC/pull/62</a><br> &gt;<br> </div>I&#39;ll make sure to have a look at this, but as always too little t= ime...<br> <div><br> &gt; In order:<br> &gt;<br> &gt; 1. ClassInfo<br> &gt;<br> &gt; The initialiser emitted will have two symbols, one public symbol<br> &gt; with the TypeInfo_Class members, and a second private generated<br> &gt; symbol for the interfaces array. =A0I can&#39;t forsee any way this<br=

&gt; 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=3D"gmail_extra">Actually, fou= nd an interesting problem when confronting it.<br><br>---<br>struct Interfa= ce<br>{<br>=A0=A0=A0 TypeInfo_Class=A0=A0 classinfo;<br>=A0=A0=A0 void*[]= =A0=A0=A0=A0 vtbl;<br>=A0=A0=A0 ptrdiff_t=A0=A0 offset;=A0=A0=A0=A0 /// off= set to Interface &#39;this&#39; from Object &#39;this&#39;=A0 &lt;--<br> }<br>---<br></div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_= extra">I&#39;ll have to have a think about what value should be put there, = and how best to put it in.<span class=3D""><font color=3D"#888888"><br></fo= nt></span></div> <span class=3D""><font color=3D"#888888"><div class=3D"gmail_extra"><br></d= iv></font></span></div></blockquote></div><br><br></div><div class=3D"gmail= _extra">Or alternatively we could generate the type (for debugging) on the = flying in ::toSymbol<br> <br></div><div class=3D"gmail_extra">1.=A0 Module::toSymbol.<br><br></div><= div class=3D"gmail_extra">Type =3D Type::moduleinfo type.<br></div><div cla= ss=3D"gmail_extra"><br><br></div><div class=3D"gmail_extra">2. ClassDeclara= tion::toSymbol<br> </div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Type = =3D Type::typeinfoclass type.<br><br></div><div class=3D"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=3D"gmail_extra"><br=
</div><div class=3D"gmail_extra">Likewise to above.<br></div><div class=3D=

gmail_extra"> Regards<br></div><div class=3D"gmail_extra">-- <br>Iain Buclaw<br><br>*(p &= lt; e ? p++ : p) =3D (c &amp; 0x0f) + &#39;0&#39;; </div></div> --047d7bdca7c21c084204db1be37d--
Apr 24 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
--047d7b6da4c8b626f604dc334f28
Content-Type: text/plain; charset=ISO-8859-1

On 24 April 2013 15:12, Iain Buclaw <ibuclaw ubuntu.com> wrote:

 On 23 April 2013 18:25, Iain Buclaw <ibuclaw ubuntu.com> wrote:

 On 23 April 2013 17:28, Johannes Pfau <nospam example.com> wrote:

 Am Tue, 23 Apr 2013 17:10:43 +0200
 schrieb "Iain Buclaw" <ibuclaw ubuntu.com>:

 In reference to this link:
 http://forum.dlang.org/post/50476C77.20608 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

 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.

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

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'; --047d7b6da4c8b626f604dc334f28 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 2= 4 April 2013 15:12, Iain Buclaw <span dir=3D"ltr">&lt;<a href=3D"mailto:ibu= claw ubuntu.com" target=3D"_blank">ibuclaw ubuntu.com</a>&gt;</span> wrote:= <br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor= der-left:1px solid rgb(204,204,204);padding-left:1ex"> <div dir=3D"ltr"><div><div class=3D"h5"><div class=3D"gmail_extra"><div cla= ss=3D"gmail_quote">On 23 April 2013 18:25, Iain Buclaw <span dir=3D"ltr">&l= t;<a href=3D"mailto:ibuclaw ubuntu.com" target=3D"_blank">ibuclaw ubuntu.co= m</a>&gt;</span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left:1px solid rgb(204,204,204);padding-left:1ex"> <div dir=3D"ltr"><div><div class=3D"gmail_extra"><div class=3D"gmail_quote"=
On 23 April 2013 17:28, Johannes Pfau <span dir=3D"ltr">&lt;<a href=3D"mai=

wrote:<br> <blockquote class=3D"gmail_quote" style=3D"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 &quot;Iain Buclaw&quot; &lt;<a href=3D"mailto:ibuclaw ubuntu.com" t= arget=3D"_blank">ibuclaw ubuntu.com</a>&gt;:<br> <div><br> &gt; In reference to this link:<br> &gt; <a href=3D"http://forum.dlang.org/post/50476C77.20608 googlemail.com" = target=3D"_blank">http://forum.dlang.org/post/50476C77.20608 googlemail.com= </a><br> &gt;<br> &gt;<br> &gt; I&#39;m currently working on dealing with each of these issues in the<= br> &gt; following pull (with the intention to merge back upstream where<br> &gt; required).<br> &gt; <a href=3D"https://github.com/D-Programming-GDC/GDC/pull/62" target=3D= "_blank">https://github.com/D-Programming-GDC/GDC/pull/62</a><br> &gt;<br> </div>I&#39;ll make sure to have a look at this, but as always too little t= ime...<br> <div><br> &gt; In order:<br> &gt;<br> &gt; 1. ClassInfo<br> &gt;<br> &gt; The initialiser emitted will have two symbols, one public symbol<br> &gt; with the TypeInfo_Class members, and a second private generated<br> &gt; symbol for the interfaces array. =A0I can&#39;t forsee any way this<br=

&gt; 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=3D"gmail_extra">Actually, fou= nd an interesting problem when confronting it.<br><br>---<br>struct Interfa= ce<br>{<br>=A0=A0=A0 TypeInfo_Class=A0=A0 classinfo;<br>=A0=A0=A0 void*[]= =A0=A0=A0=A0 vtbl;<br>=A0=A0=A0 ptrdiff_t=A0=A0 offset;=A0=A0=A0=A0 /// off= set to Interface &#39;this&#39; from Object &#39;this&#39;=A0 &lt;--<br> }<br>---<br></div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_= extra">I&#39;ll have to have a think about what value should be put there, = and how best to put it in.<span><font color=3D"#888888"><br></font></span><= /div> <span><font color=3D"#888888"><div class=3D"gmail_extra"><br></div></font><= /span></div></blockquote></div><br><br></div></div></div><div class=3D"gmai= l_extra">Or alternatively we could generate the type (for debugging) on the= flying in ::toSymbol<br> <br></div><div class=3D"gmail_extra">1.=A0 Module::toSymbol.<br><br></div><= div class=3D"gmail_extra">Type =3D Type::moduleinfo type.<br></div><div cla= ss=3D"gmail_extra"><br><br></div><div class=3D"gmail_extra">2. ClassDeclara= tion::toSymbol<br> </div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Type = =3D Type::typeinfoclass type.<br><br></div><div class=3D"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=3D"gmail_extra"><br=
</div><div class=3D"gmail_extra">Likewise to above.<br></div><div class=3D=

</div>

r><a href=3D"https://github.com/D-Programming-GDC/GDC/pull/62">https://gith= ub.com/D-Programming-GDC/GDC/pull/62</a><br><br></div><div class=3D"gmail_e= xtra"> For ModuleInfo, TypeInfoClass and Interface classes, I have added a new kin= d of type node into the glue layer.<br><br></div><div class=3D"gmail_extra"=
- d_unknown_type_node: LANG_TYPE<br><br></div><div class=3D"gmail_extra">T=

the type.<br> <br></div><div class=3D"gmail_extra">If we find this type in d_finalize_sym= bol=A0 (formerly called outdata), then we give it the compiler generated ty= pe of the initialiser, and for debug purposes give it an eponymous type nam= e=A0 (eg:=A0 _Dobject_ModuleInfoZ symbol has type name struct _Dobject_Modu= leInfoZ).<br> <br></div><div class=3D"gmail_extra">This is fine for the workaround so far= , but future improvements would be to take the logic from toObjFile / genmo= duleinfo and give the fields the correct names when generating the symbol i= n toSymbol.<br> <br>Alternatively we could store this information within Symbol itself duri= ng the toObjFile / genmoduleinfo stage, and have d_finalize_symbol call a r= outine that will generate the correct type layout to prevent code duplicati= on.<br> </div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><br><= /div><div class=3D"gmail_extra">Regards<br></div><div class=3D"gmail_extra"=
-- <br>Iain Buclaw<br><br>*(p &lt; e ? p++ : p) =3D (c &amp; 0x0f) + &#39;=

</div></div> --047d7b6da4c8b626f604dc334f28--
May 08 2013
prev sibling next sibling parent "Iain Buclaw" <ibuclaw ubuntu.com> writes:
On Wednesday, 8 May 2013 at 11:34:19 UTC, Iain Buclaw wrote:
 On 24 April 2013 15:12, Iain Buclaw <ibuclaw ubuntu.com> wrote:

 On 23 April 2013 18:25, Iain Buclaw <ibuclaw ubuntu.com> wrote:

 On 23 April 2013 17:28, Johannes Pfau <nospam example.com> 
 wrote:

 Am Tue, 23 Apr 2013 17:10:43 +0200
 schrieb "Iain Buclaw" <ibuclaw ubuntu.com>:

 In reference to this link:
 http://forum.dlang.org/post/50476C77.20608 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

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.

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

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
May 09 2013
prev sibling next sibling parent Johannes Pfau <nospam example.com> writes:
Am Thu, 09 May 2013 19:40:04 +0200
schrieb "Iain Buclaw" <ibuclaw ubuntu.com>:

 On Wednesday, 8 May 2013 at 11:34:19 UTC, Iain Buclaw wrote:
 On 24 April 2013 15:12, Iain Buclaw <ibuclaw ubuntu.com> wrote:

 On 23 April 2013 18:25, Iain Buclaw <ibuclaw ubuntu.com> wrote:

 On 23 April 2013 17:28, Johannes Pfau <nospam example.com> 
 wrote:

 Am Tue, 23 Apr 2013 17:10:43 +0200
 schrieb "Iain Buclaw" <ibuclaw ubuntu.com>:

 In reference to this link:
 http://forum.dlang.org/post/50476C77.20608 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

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.

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

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.
May 11 2013
prev sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
--047d7bf0de88c4af6604dc710e2f
Content-Type: text/plain; charset=ISO-8859-1

On 11 May 2013 12:50, Johannes Pfau <nospam example.com> wrote:

 Am Thu, 09 May 2013 19:40:04 +0200
 schrieb "Iain Buclaw" <ibuclaw ubuntu.com>:

 On Wednesday, 8 May 2013 at 11:34:19 UTC, Iain Buclaw wrote:
 On 24 April 2013 15:12, Iain Buclaw <ibuclaw ubuntu.com> wrote:

 On 23 April 2013 18:25, Iain Buclaw <ibuclaw ubuntu.com> wrote:

 On 23 April 2013 17:28, Johannes Pfau <nospam example.com>
 wrote:

 Am Tue, 23 Apr 2013 17:10:43 +0200
 schrieb "Iain Buclaw" <ibuclaw ubuntu.com>:

 In reference to this link:
 http://forum.dlang.org/post/50476C77.20608 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

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.

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

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'; --047d7bf0de88c4af6604dc710e2f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 1= 1 May 2013 12:50, Johannes Pfau <span dir=3D"ltr">&lt;<a href=3D"mailto:nos= pam example.com" target=3D"_blank">nospam example.com</a>&gt;</span> wrote:= <br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef= t:1px #ccc solid;padding-left:1ex"> Am Thu, 09 May 2013 19:40:04 +0200<br> <div><div class=3D"h5">schrieb &quot;Iain Buclaw&quot; &lt;<a href=3D"mailt= o:ibuclaw ubuntu.com">ibuclaw ubuntu.com</a>&gt;:<br> <br> &gt; On Wednesday, 8 May 2013 at 11:34:19 UTC, Iain Buclaw wrote:<br> &gt; &gt; On 24 April 2013 15:12, Iain Buclaw &lt;<a href=3D"mailto:ibuclaw= ubuntu.com">ibuclaw ubuntu.com</a>&gt; wrote:<br> &gt; &gt;<br> &gt; &gt;&gt; On 23 April 2013 18:25, Iain Buclaw &lt;<a href=3D"mailto:ibu= claw ubuntu.com">ibuclaw ubuntu.com</a>&gt; wrote:<br> &gt; &gt;&gt;<br> &gt; &gt;&gt;&gt; On 23 April 2013 17:28, Johannes Pfau &lt;<a href=3D"mail= to:nospam example.com">nospam example.com</a>&gt;<br> &gt; &gt;&gt;&gt; wrote:<br> &gt; &gt;&gt;&gt;<br> &gt; &gt;&gt;&gt;&gt; Am Tue, 23 Apr 2013 17:10:43 +0200<br> &gt; &gt;&gt;&gt;&gt; schrieb &quot;Iain Buclaw&quot; &lt;<a href=3D"mailto= :ibuclaw ubuntu.com">ibuclaw ubuntu.com</a>&gt;:<br> &gt; &gt;&gt;&gt;&gt;<br> &gt; &gt;&gt;&gt;&gt; &gt; In reference to this link:<br> &gt; &gt;&gt;&gt;&gt; &gt; <a href=3D"http://forum.dlang.org/post/50476C77.= 20608 googlemail.com" target=3D"_blank">http://forum.dlang.org/post/50476C7= 7.20608 googlemail.com</a><br> &gt; &gt;&gt;&gt;&gt; &gt;<br> &gt; &gt;&gt;&gt;&gt; &gt;<br> &gt; &gt;&gt;&gt;&gt; &gt; I&#39;m currently working on dealing with each o= f these issues<br> &gt; &gt;&gt;&gt;&gt; &gt; in the<br> &gt; &gt;&gt;&gt;&gt; &gt; following pull (with the intention to merge back= upstream<br> &gt; &gt;&gt;&gt;&gt; &gt; where<br> &gt; &gt;&gt;&gt;&gt; &gt; required).<br> &gt; &gt;&gt;&gt;&gt; &gt; <a href=3D"https://github.com/D-Programming-GDC/= GDC/pull/62" target=3D"_blank">https://github.com/D-Programming-GDC/GDC/pul= l/62</a><br> &gt; &gt;&gt;&gt;&gt; &gt;<br> &gt; &gt;&gt;&gt;&gt; I&#39;ll make sure to have a look at this, but as alw= ays too<br> &gt; &gt;&gt;&gt;&gt; little time...<br> &gt; &gt;&gt;&gt;&gt;<br> &gt; &gt;&gt;&gt;&gt; &gt; In order:<br> &gt; &gt;&gt;&gt;&gt; &gt;<br> &gt; &gt;&gt;&gt;&gt; &gt; 1. ClassInfo<br> &gt; &gt;&gt;&gt;&gt; &gt;<br> &gt; &gt;&gt;&gt;&gt; &gt; The initialiser emitted will have two symbols, o= ne public<br> &gt; &gt;&gt;&gt;&gt; &gt; symbol<br> &gt; &gt;&gt;&gt;&gt; &gt; with the TypeInfo_Class members, and a second pr= ivate<br> &gt; &gt;&gt;&gt;&gt; &gt; generated<br> &gt; &gt;&gt;&gt;&gt; &gt; symbol for the interfaces array. =A0I can&#39;t = forsee any way<br> &gt; &gt;&gt;&gt;&gt; &gt; this<br> &gt; &gt;&gt;&gt;&gt; &gt; could break compatibility with any existing comp= ilied gdc<br> &gt; &gt;&gt;&gt;&gt; &gt; (or<br> &gt; &gt;&gt;&gt;&gt; &gt; perhaps even dmd/ldc) binaries out there.<br> &gt; &gt;&gt;&gt;&gt;<br> &gt; &gt;&gt;&gt;&gt; Sounds good. That should also be good for debug info.= <br> &gt; &gt;&gt;&gt;&gt;<br> &gt; &gt;&gt;&gt;&gt;<br> &gt; &gt;&gt;&gt; Actually, found an interesting problem when confronting i= t.<br> &gt; &gt;&gt;&gt;<br> &gt; &gt;&gt;&gt; ---<br> &gt; &gt;&gt;&gt; struct Interface<br> &gt; &gt;&gt;&gt; {<br> &gt; &gt;&gt;&gt; =A0 =A0 TypeInfo_Class =A0 classinfo;<br> &gt; &gt;&gt;&gt; =A0 =A0 void*[] =A0 =A0 vtbl;<br> &gt; &gt;&gt;&gt; =A0 =A0 ptrdiff_t =A0 offset; =A0 =A0 /// offset to Inter= face &#39;this&#39;<br> &gt; &gt;&gt;&gt; from Object<br> &gt; &gt;&gt;&gt; &#39;this&#39; =A0&lt;--<br> &gt; &gt;&gt;&gt; }<br> &gt; &gt;&gt;&gt; ---<br> &gt; &gt;&gt;&gt;<br> &gt; &gt;&gt;&gt; I&#39;ll have to have a think about what value should be = put<br> &gt; &gt;&gt;&gt; there, and how<br> &gt; &gt;&gt;&gt; best to put it in.<br> &gt; &gt;&gt;&gt;<br> &gt; &gt;&gt;&gt;<br> &gt; &gt;&gt;<br> &gt; &gt;&gt; Or alternatively we could generate the type (for debugging) o= n<br> &gt; &gt;&gt; the flying<br> &gt; &gt;&gt; in ::toSymbol<br> &gt; &gt;&gt;<br> &gt; &gt;&gt; 1. =A0Module::toSymbol.<br> &gt; &gt;&gt;<br> &gt; &gt;&gt; Type =3D Type::moduleinfo type.<br> &gt; &gt;&gt;<br> &gt; &gt;&gt;<br> &gt; &gt;&gt; 2. ClassDeclaration::toSymbol<br> &gt; &gt;&gt;<br> &gt; &gt;&gt; Type =3D Type::typeinfoclass type.<br> &gt; &gt;&gt;<br> &gt; &gt;&gt; Then for each interface, add the fields for Type::interface<b= r> &gt; &gt;&gt; onto the type.<br> &gt; &gt;&gt;<br> &gt; &gt;&gt;<br> &gt; &gt;&gt; 3. InterfaceDeclaration::toSymbol<br> &gt; &gt;&gt;<br> &gt; &gt;&gt; Likewise to above.<br> &gt; &gt;&gt;<br> &gt; &gt;&gt;<br> &gt; &gt; For the time being in this pull:<br> &gt; &gt;<br> &gt; &gt; <a href=3D"https://github.com/D-Programming-GDC/GDC/pull/62" targ= et=3D"_blank">https://github.com/D-Programming-GDC/GDC/pull/62</a><br> &gt; &gt;<br> &gt; &gt; For ModuleInfo, TypeInfoClass and Interface classes, I have<br> &gt; &gt; added a new<br> &gt; &gt; kind of type node into the glue layer.<br> &gt; &gt;<br> &gt; &gt; - d_unknown_type_node: LANG_TYPE<br> &gt; &gt;<br> &gt; &gt; This means that the backend won&#39;t touch, or do any sort of<br=

&gt; &gt; the type.<br> &gt; &gt;<br> &gt; &gt; If we find this type in d_finalize_symbol =A0(formerly called<br> &gt; &gt; outdata), then<br> &gt; &gt; we give it the compiler generated type of the initialiser, and<br=

&gt; &gt; purposes give it an eponymous type name =A0(eg:<br> &gt; &gt; _Dobject_ModuleInfoZ symbol<br> &gt; &gt; has type name struct _Dobject_ModuleInfoZ).<br> &gt; &gt;<br> &gt; &gt; This is fine for the workaround so far, but future improvements<b= r> &gt; &gt; would be to<br> &gt; &gt; take the logic from toObjFile / genmoduleinfo and give the<br> &gt; &gt; fields the<br> &gt; &gt; correct names when generating the symbol in toSymbol.<br> &gt; &gt;<br> &gt; &gt; Alternatively we could store this information within Symbol<br> &gt; &gt; itself during<br> &gt; &gt; the toObjFile / genmoduleinfo stage, and have d_finalize_symbol<b= r> &gt; &gt; call a<br> &gt; &gt; routine that will generate the correct type layout to prevent<br> &gt; &gt; code<br> &gt; &gt; duplication.<br> &gt; &gt;<br> &gt; &gt;<br> &gt;<br> &gt;<br> &gt; Also, I have altered the mismatch check in d_finalize_symbol<br> &gt; (outdata) that you put in initially for this fix. =A0Now it asserts<br=

&gt;<br> &gt; This passes through the testsuite 100%, so I&#39;ll keep it. =A0There<= br> &gt; should be no reason whatsoever why the initialiser would be less<br> &gt; than the type size.<br> &gt;<br> <br> </div></div>If it passes the testsuite then there is indeed no reason not t= o change<br> it. Not sure why I made it check for &gt;=3D in the first place.<br> </blockquote></div><br></div><div class=3D"gmail_extra">If decl_initial siz= e=A0 &lt; type size. Then the backend will always automatically pad out the= end with zeroes.<br></div><div class=3D"gmail_extra"><br clear=3D"all"><br=
-- <br>

</div></div> --047d7bf0de88c4af6604dc710e2f--
May 11 2013