www.digitalmars.com         C & C++   DMDScript  

D.gnu - libphobos on ARM

reply Matthew Caron <Matt.Caron redlion.net> writes:
Hey folks,

So, I've used the instructions and code here:

https://bitbucket.org/goshawk/gdc/wiki/crosstool-ng

to build a gdc for ARM.

I've written up a simple "Hello world" and I get an Illegal Instruction 
when executing on my ARM Linux EABI system.

GDB says (edited to remove standard stuff):

==
(gdb) run
Starting program: /hello

Program received signal SIGILL, Illegal instruction.
0x0002f5c4 in _D2gc3gcx2GC6mallocMFkkPkZPv (this= 0x96018, size=88, bits=1,
     alloc_size=0x0)
     at 
/home/mattc/workspace/d/buildder/.build/src/gcc-4.6.2/libphobos/gc/gcx.d:1224
1224 
/home/mattc/workspace/d/buildder/.build/src/gcc-4.6.2/libphobos/gc/gcx.d: No 
such file or directory.
         in 
/home/mattc/workspace/d/buildder/.build/src/gcc-4.6.2/libphobos/gc/gcx.d
Current language:  auto; currently minimal
(gdb) bt full
#0  0x0002f5c4 in _D2gc3gcx2GC6mallocMFkkPkZPv (this= 0x96018, size=88,
     bits=1, alloc_size=0x0)
     at 
/home/mattc/workspace/d/buildder/.build/src/gcc-4.6.2/libphobos/gc/gcx.d:1224
No locals.
#1  0x0002692c in gc.gc.gc_malloc (sz=<value optimized out>,
     ba=<value optimized out>)
     at 
/home/mattc/workspace/d/buildder/.build/src/gcc-4.6.2/libphobos/gc/gc.d:201
No locals.
#2  0x00019ad0 in _d_newclass (ci= 0x8e8bc)
     at 
/home/mattc/workspace/d/buildder/.build/src/gcc-4.6.2/libphobos/rt/lifetime.d:123
         p = Unhandled dwarf expression opcode 0x9f
==

So, the error is at line 1224 of gcx.d, which is:

==
     /**
      * add range to scan for roots
      */
     void addRange(void *p, size_t sz)
     {
         if (!p || !sz) // 1224
         {
             return;
         }
==

The full backtrace is less than useful here, because of optimizations in 
libphobos, so I've recompiled libphobos with -O0. Recompiling my program 
and re-running it gives me:

==
(gdb) run
Starting program: /hello
Hello gents

Program received signal SIGILL, Illegal instruction.
0x0004535c in _D2gc3gcx3Gcx16fullcollectshellMFZk (this=Cannot access 
memory at address 0x1
)
     at 
/home/mattc/workspace/d/buildder/.build/src/gcc-4.6.2/libphobos/gc/gcx.d:245
245 
/home/mattc/workspace/d/buildder/.build/src/gcc-4.6.2/libphobos/gc/gcx.d: No 
such file or directory.
         in 
/home/mattc/workspace/d/buildder/.build/src/gcc-4.6.2/libphobos/gc/gcx.d
Current language:  auto; currently minimal
(gdb) bt full
#0  0x0004535c in _D2gc3gcx3Gcx16fullcollectshellMFZk (this=Cannot 
access memory at address 0x1
)
     at 
/home/mattc/workspace/d/buildder/.build/src/gcc-4.6.2/libphobos/gc/gcx.d:245
No locals.
#1  0x000418ec in _D2gc3gcx2GC18fullCollectNoStackMFZv (this= 0xe4018)
     at 
/home/mattc/workspace/d/buildder/.build/src/gcc-4.6.2/libphobos/gc/gcx.d:245
         __sync33 = (struct TypeInfo_Class &)  0xdce4c: {init = {length 
= 8,
     ptr = 0xbc81c "4�v"}, name = {length = 13,
     ptr = 0xbc824 "gc.gcx.GCLock"}, vtbl = {length = 6, ptr = 0xbc834},
   interfaces = {length = 0, ptr = 0x0}, base =  0xda804, destructor = 0x0,
   classInvariant = 0, m_flags = 54, deallocator = 0x0, m_offTi = 
{length = 0,
     ptr = 0x0}, defaultConstructor = 0x0, xgetMembers = 0}
#2  0x0003ca34 in gc_term ()
     at 
/home/mattc/workspace/d/buildder/.build/src/gcc-4.6.2/libphobos/gc/gc.d:133
No locals.
#3  0x00022e2c in rt.dmain2.main.runAll (this=0xbe9e7cd8)
     at 
/home/mattc/workspace/d/buildder/.build/src/gcc-4.6.2/libphobos/rt/dmain2.d:67
No locals.
#4  0x000227c4 in rt.dmain2.main.tryExec (this=0xbe9e7cd8, dg=
       {object = 0xbe9e7cd8, func = 0x22d94 <rt.dmain2.main.runAll>})
---Type <return> to continue, or q <return> to quit---
     at 
/home/mattc/workspace/d/buildder/.build/src/gcc-4.6.2/libphobos/rt/dmain2.d:67
No locals.
#5  0x000225ac in main (argc=1, argv=0xbe9e7e64)
     at 
/home/mattc/workspace/d/buildder/.build/src/gcc-4.6.2/libphobos/rt/dmain2.d:67
         trapExceptions = true
         am = (struct char[] *) 0xe4008
         result = 0
         args = {length = 1, ptr = 0xe4008}
==

This actually does print the "Hello gents" that it is supposed to, but 
then dies after (likely when exiting and collecting all its memory).

The line referenced is in the following:
==
{{{
     void initialize() // 245
     {
         gcLock = GCLock.classinfo;
         gcx = cast(Gcx*)cstdlib.calloc(1, Gcx.sizeof);
         if (!gcx)
             onOutOfMemoryError();
         gcx.initialize();
         setStackBottom(rt_stackBottom());
     }
}}}

I should note that I tested the gcc which was built along with gdc and 
it does produce a "Hello world" application which appears to work correctly.

Does anyone have any ideas/pointers/hey there, do it this way, dummy/etc?
-- 
Matthew Caron, Build Engineer
Sixnet, a Red Lion business | www.sixnet.com
+1 (518) 877-5173 x138 office
Jun 01 2012
next sibling parent =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:
On 01-06-2012 23:05, Matthew Caron wrote:
 Hey folks,

 So, I've used the instructions and code here:

 https://bitbucket.org/goshawk/gdc/wiki/crosstool-ng

 to build a gdc for ARM.

 I've written up a simple "Hello world" and I get an Illegal Instruction
 when executing on my ARM Linux EABI system.

 GDB says (edited to remove standard stuff):

 ==
 (gdb) run
 Starting program: /hello

 Program received signal SIGILL, Illegal instruction.
 0x0002f5c4 in _D2gc3gcx2GC6mallocMFkkPkZPv (this= 0x96018, size=88, bits=1,
 alloc_size=0x0)
 at
 /home/mattc/workspace/d/buildder/.build/src/gcc-4.6.2/libphobos/gc/gcx.d:1224

 1224
 /home/mattc/workspace/d/buildder/.build/src/gcc-4.6.2/libphobos/gc/gcx.d: No
 such file or directory.
 in /home/mattc/workspace/d/buildder/.build/src/gcc-4.6.2/libphobos/gc/gcx.d
 Current language: auto; currently minimal
 (gdb) bt full
 #0 0x0002f5c4 in _D2gc3gcx2GC6mallocMFkkPkZPv (this= 0x96018, size=88,
 bits=1, alloc_size=0x0)
 at
 /home/mattc/workspace/d/buildder/.build/src/gcc-4.6.2/libphobos/gc/gcx.d:1224

 No locals.
 #1 0x0002692c in gc.gc.gc_malloc (sz=<value optimized out>,
 ba=<value optimized out>)
 at
 /home/mattc/workspace/d/buildder/.build/src/gcc-4.6.2/libphobos/gc/gc.d:201
 No locals.
 #2 0x00019ad0 in _d_newclass (ci= 0x8e8bc)
 at
 /home/mattc/workspace/d/buildder/.build/src/gcc-4.6.2/libphobos/rt/lifetime.d:123

 p = Unhandled dwarf expression opcode 0x9f
 ==

 So, the error is at line 1224 of gcx.d, which is:

 ==
 /**
 * add range to scan for roots
 */
 void addRange(void *p, size_t sz)
 {
 if (!p || !sz) // 1224
 {
 return;
 }
 ==

 The full backtrace is less than useful here, because of optimizations in
 libphobos, so I've recompiled libphobos with -O0. Recompiling my program
 and re-running it gives me:

 ==
 (gdb) run
 Starting program: /hello
 Hello gents

 Program received signal SIGILL, Illegal instruction.
 0x0004535c in _D2gc3gcx3Gcx16fullcollectshellMFZk (this=Cannot access
 memory at address 0x1
 )
 at
 /home/mattc/workspace/d/buildder/.build/src/gcc-4.6.2/libphobos/gc/gcx.d:245

 245
 /home/mattc/workspace/d/buildder/.build/src/gcc-4.6.2/libphobos/gc/gcx.d: No
 such file or directory.
 in /home/mattc/workspace/d/buildder/.build/src/gcc-4.6.2/libphobos/gc/gcx.d
 Current language: auto; currently minimal
 (gdb) bt full
 #0 0x0004535c in _D2gc3gcx3Gcx16fullcollectshellMFZk (this=Cannot access
 memory at address 0x1
 )
 at
 /home/mattc/workspace/d/buildder/.build/src/gcc-4.6.2/libphobos/gc/gcx.d:245

 No locals.
 #1 0x000418ec in _D2gc3gcx2GC18fullCollectNoStackMFZv (this= 0xe4018)
 at
 /home/mattc/workspace/d/buildder/.build/src/gcc-4.6.2/libphobos/gc/gcx.d:245

 __sync33 = (struct TypeInfo_Class &)  0xdce4c: {init = {length = 8,
 ptr = 0xbc81c "4�v"}, name = {length = 13,
 ptr = 0xbc824 "gc.gcx.GCLock"}, vtbl = {length = 6, ptr = 0xbc834},
 interfaces = {length = 0, ptr = 0x0}, base =  0xda804, destructor = 0x0,
 classInvariant = 0, m_flags = 54, deallocator = 0x0, m_offTi = {length = 0,
 ptr = 0x0}, defaultConstructor = 0x0, xgetMembers = 0}
 #2 0x0003ca34 in gc_term ()
 at
 /home/mattc/workspace/d/buildder/.build/src/gcc-4.6.2/libphobos/gc/gc.d:133
 No locals.
 #3 0x00022e2c in rt.dmain2.main.runAll (this=0xbe9e7cd8)
 at
 /home/mattc/workspace/d/buildder/.build/src/gcc-4.6.2/libphobos/rt/dmain2.d:67

 No locals.
 #4 0x000227c4 in rt.dmain2.main.tryExec (this=0xbe9e7cd8, dg=
 {object = 0xbe9e7cd8, func = 0x22d94 <rt.dmain2.main.runAll>})
 ---Type <return> to continue, or q <return> to quit---
 at
 /home/mattc/workspace/d/buildder/.build/src/gcc-4.6.2/libphobos/rt/dmain2.d:67

 No locals.
 #5 0x000225ac in main (argc=1, argv=0xbe9e7e64)
 at
 /home/mattc/workspace/d/buildder/.build/src/gcc-4.6.2/libphobos/rt/dmain2.d:67

 trapExceptions = true
 am = (struct char[] *) 0xe4008
 result = 0
 args = {length = 1, ptr = 0xe4008}
 ==

 This actually does print the "Hello gents" that it is supposed to, but
 then dies after (likely when exiting and collecting all its memory).

 The line referenced is in the following:
 ==
 {{{
 void initialize() // 245
 {
 gcLock = GCLock.classinfo;
 gcx = cast(Gcx*)cstdlib.calloc(1, Gcx.sizeof);
 if (!gcx)
 onOutOfMemoryError();
 gcx.initialize();
 setStackBottom(rt_stackBottom());
 }
 }}}

 I should note that I tested the gcc which was built along with gdc and
 it does produce a "Hello world" application which appears to work
 correctly.

 Does anyone have any ideas/pointers/hey there, do it this way, dummy/etc?

Please try building libphobos and libdruntime with -fno-section-anchors. -- Alex Rønne Petersen alex lycus.org http://lycus.org
Jun 01 2012
prev sibling next sibling parent Andrew Wiley <wiley.andrew.j gmail.com> writes:
--f46d0401fa33ad49d304c173d9a2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, Jun 1, 2012 at 3:24 PM, Alex R=C3=B8nne Petersen <alex lycus.org> w=
rote:

 On 01-06-2012 23:05, Matthew Caron wrote:

 Hey folks,

 So, I've used the instructions and code here:

 https://bitbucket.org/goshawk/**gdc/wiki/crosstool-ng<https://bitbucket.=


 to build a gdc for ARM.

 I've written up a simple "Hello world" and I get an Illegal Instruction
 when executing on my ARM Linux EABI system.

 GDB says (edited to remove standard stuff):

 =3D=3D
 (gdb) run
 Starting program: /hello

 Program received signal SIGILL, Illegal instruction.
 0x0002f5c4 in _D2gc3gcx2GC6mallocMFkkPkZPv (this=3D 0x96018, size=3D88,
 bits=3D1,
 alloc_size=3D0x0)
 at
 /home/mattc/workspace/d/**buildder/.build/src/gcc-4.6.2/**
 libphobos/gc/gcx.d:1224

 1224
 /home/mattc/workspace/d/**buildder/.build/src/gcc-4.6.2/**libphobos/gc/g=


 No
 such file or directory.
 in /home/mattc/workspace/d/**buildder/.build/src/gcc-4.6.2/**
 libphobos/gc/gcx.d
 Current language: auto; currently minimal
 (gdb) bt full
 #0 0x0002f5c4 in _D2gc3gcx2GC6mallocMFkkPkZPv (this=3D 0x96018, size=3D8=


 bits=3D1, alloc_size=3D0x0)
 at
 /home/mattc/workspace/d/**buildder/.build/src/gcc-4.6.2/**
 libphobos/gc/gcx.d:1224

 No locals.
 #1 0x0002692c in gc.gc.gc_malloc (sz=3D<value optimized out>,
 ba=3D<value optimized out>)
 at
 /home/mattc/workspace/d/**buildder/.build/src/gcc-4.6.2/**
 libphobos/gc/gc.d:201
 No locals.
 #2 0x00019ad0 in _d_newclass (ci=3D 0x8e8bc)
 at
 /home/mattc/workspace/d/**buildder/.build/src/gcc-4.6.2/**
 libphobos/rt/lifetime.d:123

 p =3D Unhandled dwarf expression opcode 0x9f
 =3D=3D

 So, the error is at line 1224 of gcx.d, which is:

 =3D=3D
 /**
 * add range to scan for roots
 */
 void addRange(void *p, size_t sz)
 {
 if (!p || !sz) // 1224
 {
 return;
 }
 =3D=3D

 The full backtrace is less than useful here, because of optimizations in
 libphobos, so I've recompiled libphobos with -O0. Recompiling my program
 and re-running it gives me:

 =3D=3D
 (gdb) run
 Starting program: /hello
 Hello gents

 Program received signal SIGILL, Illegal instruction.
 0x0004535c in _**D2gc3gcx3Gcx16fullcollectshell**MFZk (this=3DCannot acc=


 memory at address 0x1
 )
 at
 /home/mattc/workspace/d/**buildder/.build/src/gcc-4.6.2/**
 libphobos/gc/gcx.d:245

 245
 /home/mattc/workspace/d/**buildder/.build/src/gcc-4.6.2/**libphobos/gc/g=


 No
 such file or directory.
 in /home/mattc/workspace/d/**buildder/.build/src/gcc-4.6.2/**
 libphobos/gc/gcx.d
 Current language: auto; currently minimal
 (gdb) bt full
 #0 0x0004535c in _**D2gc3gcx3Gcx16fullcollectshell**MFZk (this=3DCannot
 access
 memory at address 0x1
 )
 at
 /home/mattc/workspace/d/**buildder/.build/src/gcc-4.6.2/**
 libphobos/gc/gcx.d:245

 No locals.
 #1 0x000418ec in _**D2gc3gcx2GC18fullCollectNoStac**kMFZv (this=3D 0xe40=


 at
 /home/mattc/workspace/d/**buildder/.build/src/gcc-4.6.2/**
 libphobos/gc/gcx.d:245

 __sync33 =3D (struct TypeInfo_Class &)  0xdce4c: {init =3D {length =3D 8=


 ptr =3D 0xbc81c "4=EF=BF=BDv"}, name =3D {length =3D 13,
 ptr =3D 0xbc824 "gc.gcx.GCLock"}, vtbl =3D {length =3D 6, ptr =3D 0xbc83=


 interfaces =3D {length =3D 0, ptr =3D 0x0}, base =3D  0xda804, destructo=


 classInvariant =3D 0, m_flags =3D 54, deallocator =3D 0x0, m_offTi =3D {=


 0,
 ptr =3D 0x0}, defaultConstructor =3D 0x0, xgetMembers =3D 0}
 #2 0x0003ca34 in gc_term ()
 at
 /home/mattc/workspace/d/**buildder/.build/src/gcc-4.6.2/**
 libphobos/gc/gc.d:133
 No locals.
 #3 0x00022e2c in rt.dmain2.main.runAll (this=3D0xbe9e7cd8)
 at
 /home/mattc/workspace/d/**buildder/.build/src/gcc-4.6.2/**
 libphobos/rt/dmain2.d:67

 No locals.
 #4 0x000227c4 in rt.dmain2.main.tryExec (this=3D0xbe9e7cd8, dg=3D
 {object =3D 0xbe9e7cd8, func =3D 0x22d94 <rt.dmain2.main.runAll>})
 ---Type <return> to continue, or q <return> to quit---
 at
 /home/mattc/workspace/d/**buildder/.build/src/gcc-4.6.2/**
 libphobos/rt/dmain2.d:67

 No locals.
 #5 0x000225ac in main (argc=3D1, argv=3D0xbe9e7e64)
 at
 /home/mattc/workspace/d/**buildder/.build/src/gcc-4.6.2/**
 libphobos/rt/dmain2.d:67

 trapExceptions =3D true
 am =3D (struct char[] *) 0xe4008
 result =3D 0
 args =3D {length =3D 1, ptr =3D 0xe4008}
 =3D=3D

 This actually does print the "Hello gents" that it is supposed to, but
 then dies after (likely when exiting and collecting all its memory).

 The line referenced is in the following:
 =3D=3D
 {{{
 void initialize() // 245
 {
 gcLock =3D GCLock.classinfo;
 gcx =3D cast(Gcx*)cstdlib.calloc(1, Gcx.sizeof);
 if (!gcx)
 onOutOfMemoryError();
 gcx.initialize();
 setStackBottom(rt_stackBottom(**));
 }
 }}}

 I should note that I tested the gcc which was built along with gdc and
 it does produce a "Hello world" application which appears to work
 correctly.

 Does anyone have any ideas/pointers/hey there, do it this way, dummy/etc=



Please try building libphobos and libdruntime with -fno-section-anchors.

optimization is turned off anyway, so that isn't actually your problem. Can you run `disassemble` in gdb to see what the faulting instruction is? --f46d0401fa33ad49d304c173d9a2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On Fri, Jun 1, 2012 at 3:24 PM, Alex R=C3=B8nne = Petersen <span dir=3D"ltr">&lt;<a href=3D"mailto:alex lycus.org" target=3D"= _blank">alex lycus.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_= quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1= ex"> <div class=3D"HOEnZb"><div class=3D"h5">On 01-06-2012 23:05, Matthew Caron = wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Hey folks,<br> <br> So, I&#39;ve used the instructions and code here:<br> <br> <a href=3D"https://bitbucket.org/goshawk/gdc/wiki/crosstool-ng" target=3D"_= blank">https://bitbucket.org/goshawk/<u></u>gdc/wiki/crosstool-ng</a><br> <br> to build a gdc for ARM.<br> <br> I&#39;ve written up a simple &quot;Hello world&quot; and I get an Illegal I= nstruction<br> when executing on my ARM Linux EABI system.<br> <br> GDB says (edited to remove standard stuff):<br> <br> =3D=3D<br> (gdb) run<br> Starting program: /hello<br> <br> Program received signal SIGILL, Illegal instruction.<br> 0x0002f5c4 in _D2gc3gcx2GC6mallocMFkkPkZPv (this=3D 0x96018, size=3D88, bit= s=3D1,<br> alloc_size=3D0x0)<br> at<br> /home/mattc/workspace/d/<u></u>buildder/.build/src/gcc-4.6.2/<u></u>libphob= os/gc/gcx.d:1224<br> <br> 1224<br> /home/mattc/workspace/d/<u></u>buildder/.build/src/gcc-4.6.2/<u></u>libphob= os/gc/gcx.d: No<br> such file or directory.<br> in /home/mattc/workspace/d/<u></u>buildder/.build/src/gcc-4.6.2/<u></u>libp= hobos/gc/gcx.d<br> Current language: auto; currently minimal<br> (gdb) bt full<br> #0 0x0002f5c4 in _D2gc3gcx2GC6mallocMFkkPkZPv (this=3D 0x96018, size=3D88,<= br> bits=3D1, alloc_size=3D0x0)<br> at<br> /home/mattc/workspace/d/<u></u>buildder/.build/src/gcc-4.6.2/<u></u>libphob= os/gc/gcx.d:1224<br> <br> No locals.<br> #1 0x0002692c in gc.gc.gc_malloc (sz=3D&lt;value optimized out&gt;,<br> ba=3D&lt;value optimized out&gt;)<br> at<br> /home/mattc/workspace/d/<u></u>buildder/.build/src/gcc-4.6.2/<u></u>libphob= os/gc/gc.d:201<br> No locals.<br> #2 0x00019ad0 in _d_newclass (ci=3D 0x8e8bc)<br> at<br> /home/mattc/workspace/d/<u></u>buildder/.build/src/gcc-4.6.2/<u></u>libphob= os/rt/lifetime.d:123<br> <br> p =3D Unhandled dwarf expression opcode 0x9f<br> =3D=3D<br> <br> So, the error is at line 1224 of gcx.d, which is:<br> <br> =3D=3D<br> /**<br> * add range to scan for roots<br> */<br> void addRange(void *p, size_t sz)<br> {<br> if (!p || !sz) // 1224<br> {<br> return;<br> }<br> =3D=3D<br> <br> The full backtrace is less than useful here, because of optimizations in<br=

m<br> and re-running it gives me:<br> <br> =3D=3D<br> (gdb) run<br> Starting program: /hello<br> Hello gents<br> <br> Program received signal SIGILL, Illegal instruction.<br> 0x0004535c in _<u></u>D2gc3gcx3Gcx16fullcollectshell<u></u>MFZk (this=3DCan= not access<br> memory at address 0x1<br> )<br> at<br> /home/mattc/workspace/d/<u></u>buildder/.build/src/gcc-4.6.2/<u></u>libphob= os/gc/gcx.d:245<br> <br> 245<br> /home/mattc/workspace/d/<u></u>buildder/.build/src/gcc-4.6.2/<u></u>libphob= os/gc/gcx.d: No<br> such file or directory.<br> in /home/mattc/workspace/d/<u></u>buildder/.build/src/gcc-4.6.2/<u></u>libp= hobos/gc/gcx.d<br> Current language: auto; currently minimal<br> (gdb) bt full<br> #0 0x0004535c in _<u></u>D2gc3gcx3Gcx16fullcollectshell<u></u>MFZk (this=3D= Cannot access<br> memory at address 0x1<br> )<br> at<br> /home/mattc/workspace/d/<u></u>buildder/.build/src/gcc-4.6.2/<u></u>libphob= os/gc/gcx.d:245<br> <br> No locals.<br> #1 0x000418ec in _<u></u>D2gc3gcx2GC18fullCollectNoStac<u></u>kMFZv (this= =3D 0xe4018)<br> at<br> /home/mattc/workspace/d/<u></u>buildder/.build/src/gcc-4.6.2/<u></u>libphob= os/gc/gcx.d:245<br> <br> __sync33 =3D (struct TypeInfo_Class &amp;) 0xdce4c: {init =3D {length =3D = 8,<br> ptr =3D 0xbc81c &quot;4=EF=BF=BDv&quot;}, name =3D {length =3D 13,<br> ptr =3D 0xbc824 &quot;gc.gcx.GCLock&quot;}, vtbl =3D {length =3D 6, ptr =3D= 0xbc834},<br> interfaces =3D {length =3D 0, ptr =3D 0x0}, base =3D 0xda804, destructor = =3D 0x0,<br> classInvariant =3D 0, m_flags =3D 54, deallocator =3D 0x0, m_offTi =3D {len= gth =3D 0,<br> ptr =3D 0x0}, defaultConstructor =3D 0x0, xgetMembers =3D 0}<br> #2 0x0003ca34 in gc_term ()<br> at<br> /home/mattc/workspace/d/<u></u>buildder/.build/src/gcc-4.6.2/<u></u>libphob= os/gc/gc.d:133<br> No locals.<br> #3 0x00022e2c in rt.dmain2.main.runAll (this=3D0xbe9e7cd8)<br> at<br> /home/mattc/workspace/d/<u></u>buildder/.build/src/gcc-4.6.2/<u></u>libphob= os/rt/dmain2.d:67<br> <br> No locals.<br> #4 0x000227c4 in rt.dmain2.main.tryExec (this=3D0xbe9e7cd8, dg=3D<br> {object =3D 0xbe9e7cd8, func =3D 0x22d94 &lt;rt.dmain2.main.runAll&gt;})<br=

at<br> /home/mattc/workspace/d/<u></u>buildder/.build/src/gcc-4.6.2/<u></u>libphob= os/rt/dmain2.d:67<br> <br> No locals.<br> #5 0x000225ac in main (argc=3D1, argv=3D0xbe9e7e64)<br> at<br> /home/mattc/workspace/d/<u></u>buildder/.build/src/gcc-4.6.2/<u></u>libphob= os/rt/dmain2.d:67<br> <br> trapExceptions =3D true<br> am =3D (struct char[] *) 0xe4008<br> result =3D 0<br> args =3D {length =3D 1, ptr =3D 0xe4008}<br> =3D=3D<br> <br> This actually does print the &quot;Hello gents&quot; that it is supposed to= , but<br> then dies after (likely when exiting and collecting all its memory).<br> <br> The line referenced is in the following:<br> =3D=3D<br> {{{<br> void initialize() // 245<br> {<br> gcLock =3D GCLock.classinfo;<br> gcx =3D cast(Gcx*)cstdlib.calloc(1, Gcx.sizeof);<br> if (!gcx)<br> onOutOfMemoryError();<br> gcx.initialize();<br> setStackBottom(rt_stackBottom(<u></u>));<br> }<br> }}}<br> <br> I should note that I tested the gcc which was built along with gdc and<br> it does produce a &quot;Hello world&quot; application which appears to work= <br> correctly.<br> <br> Does anyone have any ideas/pointers/hey there, do it this way, dummy/etc?<b= r> </blockquote> <br></div></div> Please try building libphobos and libdruntime with -fno-section-anchors.<sp= an class=3D"HOEnZb"><font color=3D"#888888"><br><br></font></span></blockqu= ote><div><br></div><div>You certainly need to do this, but -O0 means that s= ection-anchors optimization is turned off anyway, so that isn&#39;t actuall= y your problem. Can you run `disassemble` in gdb to see what the faulting i= nstruction is?=C2=A0</div> </div> --f46d0401fa33ad49d304c173d9a2--
Jun 01 2012
prev sibling next sibling parent Matthew Caron <Matt.Caron redlion.net> writes:
On 06/01/2012 10:13 PM, Andrew Wiley wrote:
 On Fri, Jun 1, 2012 at 3:24 PM, Alex Rønne Petersen <alex lycus.org
 <mailto:alex lycus.org>> wrote:
     Please try building libphobos and libdruntime with -fno-section-anchors.


 You certainly need to do this, but -O0 means that section-anchors
 optimization is turned off anyway, so that isn't actually your problem.

Judging by: https://bitbucket.org/goshawk/gdc/issue/120/fsection-anchors-broken-on-arm (specifically https://bitbucket.org/goshawk/gdc/issue/120/fsection-anchors-broken-on- rm#comment-686378), I thought that was fixed. I guess not. I'll build it with no-section-anchors from now on.
 Can you run `disassemble` in gdb to see what the faulting instruction is?

(gdb) disassemble Dump of assembler code for function _D2gc3gcx3Gcx16fullcollectshellMFZk: 0x00045358 <_D2gc3gcx3Gcx16fullcollectshellMFZk+0>: push {r4, r5, r6, r7, r8, r9, r10, r11, lr} 0x0004535c <_D2gc3gcx3Gcx16fullcollectshellMFZk+4>: vstmdb sp!, {d8-d15} 0x00045360 <_D2gc3gcx3Gcx16fullcollectshellMFZk+8>: add r11, sp, #96 ; 0x60 0x00045364 <_D2gc3gcx3Gcx16fullcollectshellMFZk+12>: sub sp, sp, #68 ; 0x44 0x00045368 <_D2gc3gcx3Gcx16fullcollectshellMFZk+16>: str r0, [r11, #-152] 0x0004536c <_D2gc3gcx3Gcx16fullcollectshellMFZk+20>: ldr r3, [r11, #-152] 0x00045370 <_D2gc3gcx3Gcx16fullcollectshellMFZk+24>: str r3, [r11, #-140] 0x00045374 <_D2gc3gcx3Gcx16fullcollectshellMFZk+28>: ldr r3, [r11, #-140] 0x00045378 <_D2gc3gcx3Gcx16fullcollectshellMFZk+32>: cmp r3, #0 ; 0x0 0x0004537c <_D2gc3gcx3Gcx16fullcollectshellMFZk+36>: beq 0x45390 <_D2gc3gcx3Gcx16fullcollectshellMFZk+56> 0x00045380 <_D2gc3gcx3Gcx16fullcollectshellMFZk+40>: ldr r3, [r11, #-140] 0x00045384 <_D2gc3gcx3Gcx16fullcollectshellMFZk+44>: mov r0, r3 0x00045388 <_D2gc3gcx3Gcx16fullcollectshellMFZk+48>: bl 0x4241c <_D2gc3g---Type <return> to continue, or q <return> to quit--- cx3Gcx11__invariantMFZv> 0x0004538c <_D2gc3gcx3Gcx16fullcollectshellMFZk+52>: b 0x453cc <_D2gc3gcx3Gcx16fullcollectshellMFZk+116> 0x00045390 <_D2gc3gcx3Gcx16fullcollectshellMFZk+56>: mov r3, #9 ; 0x9 0x00045394 <_D2gc3gcx3Gcx16fullcollectshellMFZk+60>: str r3, [r11, #-132] 0x00045398 <_D2gc3gcx3Gcx16fullcollectshellMFZk+64>: ldr r3, [pc, #184] ; 0x45458 <_D2gc3gcx3Gcx16fullcollectshellMFZk+256> 0x0004539c <_D2gc3gcx3Gcx16fullcollectshellMFZk+68>: str r3, [r11, #-128] 0x000453a0 <_D2gc3gcx3Gcx16fullcollectshellMFZk+72>: mov r3, #72 ; 0x48 0x000453a4 <_D2gc3gcx3Gcx16fullcollectshellMFZk+76>: str r3, [r11, #-124] 0x000453a8 <_D2gc3gcx3Gcx16fullcollectshellMFZk+80>: ldr r3, [pc, #172] ; 0x4545c <_D2gc3gcx3Gcx16fullcollectshellMFZk+260> 0x000453ac <_D2gc3gcx3Gcx16fullcollectshellMFZk+84>: str r3, [r11, #-120] 0x000453b0 <_D2gc3gcx3Gcx16fullcollectshellMFZk+88>: ldr r3, [pc, #168] ; 0x45460 <_D2gc3gcx3Gcx16fullcollectshellMFZk+264> 0x000453b4 <_D2gc3gcx3Gcx16fullcollectshellMFZk+92>: str r3, [sp] 0x000453b8 <_D2gc3gcx3Gcx16fullcollectshellMFZk+96>: sub r3, r11, #132 ; 0x84 0x000453bc <_D2gc3gcx3Gcx16fullcollectshellMFZk+100>: ldm r3, {r0, r1} ---Type <return> to continue, or q <return> to quit--- 0x000453c0 <_D2gc3gcx3Gcx16fullcollectshellMFZk+104>: sub r3, r11, #124 ; 0x7c 0x000453c4 <_D2gc3gcx3Gcx16fullcollectshellMFZk+108>: ldm r3, {r2, r3} 0x000453c8 <_D2gc3gcx3Gcx16fullcollectshellMFZk+112>: bl 0x21fd8 <_d_assert_msg> 0x000453cc <_D2gc3gcx3Gcx16fullcollectshellMFZk+116>: mov r3, #0 ; 0x0 0x000453d0 <_D2gc3gcx3Gcx16fullcollectshellMFZk+120>: str r3, [r11, #-136] 0x000453d4 <_D2gc3gcx3Gcx16fullcollectshellMFZk+124>: mov r3, #0 ; 0x0 0x000453d8 <_D2gc3gcx3Gcx16fullcollectshellMFZk+128>: str r3, [r11, #-104] 0x000453dc <_D2gc3gcx3Gcx16fullcollectshellMFZk+132>: sub r3, r11, #136 ; 0x88 0x000453e0 <_D2gc3gcx3Gcx16fullcollectshellMFZk+136>: str r3, [r11, #-136] 0x000453e4 <_D2gc3gcx3Gcx16fullcollectshellMFZk+140>: ldr r2, [r11, #-140] 0x000453e8 <_D2gc3gcx3Gcx16fullcollectshellMFZk+144>: ldr r3, [r11, #-136] 0x000453ec <_D2gc3gcx3Gcx16fullcollectshellMFZk+148>: mov r0, r2 0x000453f0 <_D2gc3gcx3Gcx16fullcollectshellMFZk+152>: mov r1, r3 0x000453f4 <_D2gc3gcx3Gcx16fullcollectshellMFZk+156>: bl 0x45468 <_D2gc3gcx3Gcx11fullcollectMFPvZk> ---Type <return> to continue, or q <return> to quit--- ---Type <return> to continue, or q <return> to quit--- 0x000453f8 <_D2gc3gcx3Gcx16fullcollectshellMFZk+160>: mov r3, r0 0x000453fc <_D2gc3gcx3Gcx16fullcollectshellMFZk+164>: str r3, [r11, #-104] 0x00045400 <_D2gc3gcx3Gcx16fullcollectshellMFZk+168>: ldr r3, [r11, #-104] 0x00045404 <_D2gc3gcx3Gcx16fullcollectshellMFZk+172>: str r3, [r11, #-108] 0x00045408 <_D2gc3gcx3Gcx16fullcollectshellMFZk+176>: ldr r3, [r11, #-140] 0x0004540c <_D2gc3gcx3Gcx16fullcollectshellMFZk+180>: cmp r3, #0 ; 0x0 0x00045410 <_D2gc3gcx3Gcx16fullcollectshellMFZk+184>: beq 0x45424 <_D2gc3gcx3Gcx16fullcollectshellMFZk+204> 0x00045414 <_D2gc3gcx3Gcx16fullcollectshellMFZk+188>: ldr r3, [r11, #-140] 0x00045418 <_D2gc3gcx3Gcx16fullcollectshellMFZk+192>: mov r0, r3 0x0004541c <_D2gc3gcx3Gcx16fullcollectshellMFZk+196>: bl 0x4241c <_D2gc3gcx3Gcx11__invariantMFZv> 0x00045420 <_D2gc3gcx3Gcx16fullcollectshellMFZk+200>: b 0x45444 <_D2gc3gcx3Gcx16fullcollectshellMFZk+236> 0x00045424 <_D2gc3gcx3Gcx16fullcollectshellMFZk+204>: mov r3, #0 ; 0x0 0x00045428 <_D2gc3gcx3Gcx16fullcollectshellMFZk+208>: str r3, [r11, #-116] 0x0004542c <_D2gc3gcx3Gcx16fullcollectshellMFZk+212>: ldr r3, [pc, #48] ---Type <return> to continue, or q <return> to quit--- ; 0x45464 <_D2gc3gcx3Gcx16fullcollectshellMFZk+268> 0x00045430 <_D2gc3gcx3Gcx16fullcollectshellMFZk+216>: str r3, [r11, #-112] 0x00045434 <_D2gc3gcx3Gcx16fullcollectshellMFZk+220>: sub r3, r11, #116 ; 0x74 0x00045438 <_D2gc3gcx3Gcx16fullcollectshellMFZk+224>: ldm r3, {r0, r1} 0x0004543c <_D2gc3gcx3Gcx16fullcollectshellMFZk+228>: mov r2, #0 ; 0x0 0x00045440 <_D2gc3gcx3Gcx16fullcollectshellMFZk+232>: bl 0x22018 <_d_assert> 0x00045444 <_D2gc3gcx3Gcx16fullcollectshellMFZk+236>: ldr r3, [r11, #-108] 0x00045448 <_D2gc3gcx3Gcx16fullcollectshellMFZk+240>: mov r0, r3 0x0004544c <_D2gc3gcx3Gcx16fullcollectshellMFZk+244>: sub sp, r11, #96 ; 0x60 0x00045450 <_D2gc3gcx3Gcx16fullcollectshellMFZk+248>: vldmia sp!, {d8-d15} 0x00045454 <_D2gc3gcx3Gcx16fullcollectshellMFZk+252>: pop {r4, r5, r6, r7, r8, r9, r10, r11, pc} 0x00045458 <_D2gc3gcx3Gcx16fullcollectshellMFZk+256>: andeq r12, r11, r0, asr r8 0x0004545c <_D2gc3gcx3Gcx16fullcollectshellMFZk+260>: andeq r12, r11, r12, asr r8 0x00045460 <_D2gc3gcx3Gcx16fullcollectshellMFZk+264>: andeq r0, r0, r9, lsr r9 ---Type <return> to continue, or q <return> to quit--- 0x00045464 <_D2gc3gcx3Gcx16fullcollectshellMFZk+268>: andeq r12, r11, r8, lsr #17 -- Matthew Caron, Build Engineer Sixnet, a Red Lion business | www.sixnet.com +1 (518) 877-5173 x138 office
Jun 04 2012
prev sibling next sibling parent Andrew Wiley <wiley.andrew.j gmail.com> writes:
--f46d0442715680644704c1a7e130
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Mon, Jun 4, 2012 at 4:31 AM, Matthew Caron <Matt.Caron redlion.net>wrote=
:

 On 06/01/2012 10:13 PM, Andrew Wiley wrote:

 On Fri, Jun 1, 2012 at 3:24 PM, Alex R=F8nne Petersen <alex lycus.org
 <mailto:alex lycus.org>> wrote:
    Please try building libphobos and libdruntime with
 -fno-section-anchors.


 You certainly need to do this, but -O0 means that section-anchors
 optimization is turned off anyway, so that isn't actually your problem.

Judging by: https://bitbucket.org/goshawk/**gdc/issue/120/fsection-** anchors-broken-on-arm<https://bitbucket.org/goshawk/gdc/issue/120/fsectio=

 (specifically https://bitbucket.org/goshawk/**gdc/issue/120/fsection-**
 anchors-broken-on-arm#comment-**686378<https://bitbucket.org/goshawk/gdc/=

 I thought that was fixed.

 I guess not. I'll build it with no-section-anchors from now on.


  Can you run `disassemble` in gdb to see what the faulting instruction is=


(gdb) disassemble Dump of assembler code for function _**D2gc3gcx3Gcx16fullcollectshell** MFZk: 0x00045358 <_**D2gc3gcx3Gcx16fullcollectshell**MFZk+0>: push {r4, r5, r6, r7, r8, r9, r10, r11, lr} 0x0004535c <_**D2gc3gcx3Gcx16fullcollectshell**MFZk+4>: vstmdb sp!, {d8-d15}

You're faulting on a VFP instruction. What hardware are you trying to target, and what is the output of `gdc -v` and `gcc -v` ? --f46d0442715680644704c1a7e130 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On Mon, Jun 4, 2012 at 4:31 AM, Matthew Caron <s= pan dir=3D"ltr">&lt;<a href=3D"mailto:Matt.Caron redlion.net" target=3D"_bl= ank">Matt.Caron redlion.net</a>&gt;</span> wrote:<br><blockquote class=3D"g= mail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-= color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"> <div class=3D"im">On 06/01/2012 10:13 PM, Andrew Wiley wrote:<br> </div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;p= adding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;bo= rder-left-style:solid"><div class=3D"im"> On Fri, Jun 1, 2012 at 3:24 PM, Alex R=F8nne Petersen &lt;<a href=3D"mailto= :alex lycus.org" target=3D"_blank">alex lycus.org</a><br></div><div class= =3D"im"> &lt;mailto:<a href=3D"mailto:alex lycus.org" target=3D"_blank">alex lycus.o= rg</a>&gt;&gt; wrote:<br> =A0 =A0Please try building libphobos and libdruntime with -fno-section-anc= hors.<br> <br> <br> You certainly need to do this, but -O0 means that section-anchors<br> optimization is turned off anyway, so that isn&#39;t actually your problem.= <br> </div></blockquote> <br> Judging by:<br> <br> <a href=3D"https://bitbucket.org/goshawk/gdc/issue/120/fsection-anchors-bro= ken-on-arm" target=3D"_blank">https://bitbucket.org/goshawk/<u></u>gdc/issu= e/120/fsection-<u></u>anchors-broken-on-arm</a><br> <br> (specifically <a href=3D"https://bitbucket.org/goshawk/gdc/issue/120/fsecti= on-anchors-broken-on-arm#comment-686378" target=3D"_blank">https://bitbucke= t.org/goshawk/<u></u>gdc/issue/120/fsection-<u></u>anchors-broken-on-arm#co= mment-<u></u>686378</a>), I thought that was fixed.<br> <br> I guess not. I&#39;ll build it with no-section-anchors from now on.<div cla= ss=3D"im"><br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding= -left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-l= eft-style:solid"> Can you run `disassemble` in gdb to see what the faulting instruction is?<b= r> </blockquote> <br> <br></div> (gdb) disassemble<br> Dump of assembler code for function _<u></u>D2gc3gcx3Gcx16fullcollectshell<= u></u>MFZk:<br> 0x00045358 &lt;_<u></u>D2gc3gcx3Gcx16fullcollectshell<u></u>MFZk+0&gt;: =A0= =A0 push =A0 =A0{r4, r5, r6, r7, r8, r9, r10, r11, lr}<br> 0x0004535c &lt;_<u></u>D2gc3gcx3Gcx16fullcollectshell<u></u>MFZk+4&gt;: =A0= =A0 vstmdb =A0sp!, {d8-d15}<br></blockquote><div>=A0</div><div>You&#39;re = faulting on a VFP instruction. What hardware are you trying to target, and = what is the output of `gdc -v` and `gcc -v`=A0?</div> <div>=A0</div></div> --f46d0442715680644704c1a7e130--
Jun 04 2012
prev sibling next sibling parent Matthew Caron <Matt.Caron redlion.net> writes:
On 06/04/2012 12:17 PM, Andrew Wiley wrote:
 You're faulting on a VFP instruction. What hardware are you trying to
 target, and what is the output of `gdc -v` and `gcc -v` ?

D'oh, that was it. It's compiled with softfp, and I'm on an armv5 with no hardware floating point. Recompiling libphobos with: -march=armv5t -mfloat-abi=soft -fno-section-anchors seems to fix it, now I just need to rebuild the whole toolchain the same way. Sorry for the trouble, but thanks a lot for the help -- Matthew Caron, Build Engineer Sixnet, a Red Lion business | www.sixnet.com +1 (518) 877-5173 x138 office
Jun 04 2012
prev sibling next sibling parent Johannes Pfau <nospam example.com> writes:
Am Mon, 4 Jun 2012 07:31:59 -0400
schrieb Matthew Caron <Matt.Caron redlion.net>:

 Judging by:
 
 https://bitbucket.org/goshawk/gdc/issue/120/fsection-anchors-broken-on-arm
 
 (specifically 
 https://bitbucket.org/goshawk/gdc/issue/120/fsection-anchors-broken-on-
rm#comment-686378), 
 I thought that was fixed.

No, that's only a partial fix. There's at least one other issue with -fsection-anchors which isn't fixed by that patch. Also the patch hasn't been committed yet IIRC. I had another look at the issue today though and posted some new information. Maybe that's enough for Iain to fix it?
Jun 11 2012
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 11 June 2012 17:58, Johannes Pfau <nospam example.com> wrote:
 Am Mon, 4 Jun 2012 07:31:59 -0400
 schrieb Matthew Caron <Matt.Caron redlion.net>:

 Judging by:

 https://bitbucket.org/goshawk/gdc/issue/120/fsection-anchors-broken-on-arm

 (specifically
 https://bitbucket.org/goshawk/gdc/issue/120/fsection-anchors-broken-on-arm#comment-686378),
 I thought that was fixed.

No, that's only a partial fix. There's at least one other issue with -fsection-anchors which isn't fixed by that patch. Also the patch hasn't been committed yet IIRC. I had another look at the issue today though and posted some new information. Maybe that's enough for Iain to fix it?

There are two things under my general consensus for this: 1. would be to re-implement dfrontend/todt.c entirely, so that we produce GCC trees directly from the toDt routines, rather than the dmd's intermediate backend representation and later blindly converting to GCC after all information about the type size is finalised. 2. would be to review the current implementation of how we record inheritance in classes and fix it up where possible to utilise the already existing macros in place to hold information about type inheritance and basetypes for the backend to better understand what information we are sending it. Regards -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Jun 11 2012
prev sibling next sibling parent Trass3r <un known.com> writes:
And I guess 1 means a lot more work but would be the better option apart  
 from that?!
Jun 11 2012
prev sibling next sibling parent Johannes Pfau <nospam example.com> writes:
Am Mon, 11 Jun 2012 18:30:37 +0100
schrieb Iain Buclaw <ibuclaw ubuntu.com>:
 
 There are two things under my general consensus for this:
 
 1. would be to re-implement dfrontend/todt.c entirely, so that we
 produce GCC trees directly from the toDt routines, rather than the
 dmd's intermediate backend representation and later blindly converting
 to GCC after all information about the type size is finalised.
 
 2. would be to review the current implementation of how we record
 inheritance in classes and fix it up where possible to utilise the
 already existing macros in place to hold information about type
 inheritance and basetypes for the backend to better understand what
 information we are sending it.

I'm not very familiar with the GDC glue code yet, but I'm not sure if 1 would help in this case. The problem is that ClassDeclaration::toSymbol() in d-decls.cc uses ClassDeclaration::classinfo->type->toCtype() to generate it's Stree field and therefore uses size = 76. Then outdata (in d-objfile.cc) calls check_static_sym which returns this Stree(size = 76). outdata the sets DECL_INITIAL(t) = dt2tree(sym->Sdt), and this dt2tree result produces data with size = 108. Now if we kept the initializer sym->Sdt as a tree instead of the dt* list stuff, we could still have size mismatches. So while getting rid of the intermediary dt_t representation sure has lots of other benefits, I don't see how it could be useful in this case. We'd have to somehow combine the dt_t creation (in this case it's actually not toDt, it's ClassDeclaration::toObjFile which creates the dt_t list) and ClassDeclaration::toSymbol() to really avoid this problem, but that's probably a lot of work. 2 seems like it probably wouldn't be ABI compatible to dmd. I don't care if we break ABI compatibility, just wanted to mention that. I guess we can't just change the size of classinfo->type->toCtype() to match the initializer size? We'd probably have to create a custom type for every ClassDeclaration then? Something like RECORD(classinfo->type->toCtype(); ubyte[x])? ---------------------------------------------------------------------- BTW: We should probably add something like if(DECL_INITIAL(t) != NULL_TREE) gcc_assert(DECL_SIZE(t) >= TYPE_SIZE(TREE_TYPE(DECL_INITIAL(t)))) (or probably those even need to be equal, I'm not sure if the gcc backend adds padding automatically) to outdata? Wouldn't this detect most of these bugs?
Jun 13 2012
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 13 June 2012 15:44, Johannes Pfau <nospam example.com> wrote:
 Am Mon, 11 Jun 2012 18:30:37 +0100
 schrieb Iain Buclaw <ibuclaw ubuntu.com>:
 There are two things under my general consensus for this:

 1. would be to re-implement dfrontend/todt.c entirely, so that we
 produce GCC trees directly from the toDt routines, rather than the
 dmd's intermediate backend representation and later blindly converting
 to GCC after all information about the type size is finalised.

 2. would be to review the current implementation of how we record
 inheritance in classes and fix it up where possible to utilise the
 already existing macros in place to hold information about type
 inheritance and basetypes for the backend to better understand what
 information we are sending it.

I'm not very familiar with the GDC glue code yet, but I'm not sure if 1 would help in this case. The problem is that ClassDeclaration::toSymbol() in d-decls.cc uses ClassDeclaration::classinfo->type->toCtype() to generate it's Stree field and therefore uses size = 76. Then outdata (in d-objfile.cc) calls check_static_sym which returns this Stree(size = 76). outdata the sets DECL_INITIAL(t) = dt2tree(sym->Sdt), and this dt2tree result produces data with size = 108. Now if we kept the initializer sym->Sdt as a tree instead of the dt* list stuff, we could still have size mismatches. So while getting rid of the intermediary dt_t representation sure has lots of other benefits, I don't see how it could be useful in this case. We'd have to somehow combine the dt_t creation (in this case it's actually not toDt, it's ClassDeclaration::toObjFile which creates the dt_t list) and ClassDeclaration::toSymbol() to really avoid this problem, but that's probably a lot of work.

I can check this, but the side of the issue when I checked some time ago I saw was that the initialiser is a typeless constructor that is raw casted into the type we are assigning it to, so one bad factor of that is we are relying on the member layout to match what was created by toDt.
 2 seems like it probably wouldn't be ABI compatible to dmd. I don't
 care if we break ABI compatibility, just wanted to mention that.

2 is more for better debug information for a class and interface declaration's inheritance tree. Ever notice that you can't access methods through the debugger, lest you want to ICE gdb? :-) There's a little bit of cludge and cleanup needed around that code area anyway, so it's on my TODO. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Jun 13 2012
prev sibling parent Johannes Pfau <nospam example.com> writes:
Am Wed, 13 Jun 2012 17:24:18 +0100
schrieb Iain Buclaw <ibuclaw ubuntu.com>:


 
 I can check this, but the side of the issue when I checked some time
 ago I saw was that the initialiser is a typeless constructor that is
 raw casted into the type we are assigning it to, so one bad factor of
 that is we are relying on the member layout to match what was created
 by toDt.

So DECL_INITIAL would do a type check? That would detect size mismatches of course and is probably a good idea.
 
 2 seems like it probably wouldn't be ABI compatible to dmd. I don't
 care if we break ABI compatibility, just wanted to mention that.

2 is more for better debug information for a class and interface declaration's inheritance tree. Ever notice that you can't access methods through the debugger, lest you want to ICE gdb? :-) There's a little bit of cludge and cleanup needed around that code area anyway, so it's on my TODO.

I haven't looked at GCCs inheritance implementation for C++ yet, maybe it's even possible to stay ABI compatible to dmd? Would be good to keep at least ClassInfo (as declared in druntime) consistent.
Jun 14 2012