D.gnu - libphobos on ARM
- Matthew Caron (130/130) Jun 01 2012 Hey folks,
- =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= (6/129) Jun 01 2012 Please try building libphobos and libdruntime with -fno-section-anchors.
- Andrew Wiley (16/185) Jun 01 2012 org/goshawk/gdc/wiki/crosstool-ng>
- Matthew Caron (145/151) Jun 04 2012 Judging by:
- Johannes Pfau (7/14) Jun 11 2012 No, that's only a partial fix. There's at least one other issue with
- Iain Buclaw (15/29) Jun 11 2012 There are two things under my general consensus for this:
- Trass3r (2/2) Jun 11 2012 And I guess 1 means a lot more work but would be the better option apart...
- Johannes Pfau (33/46) Jun 13 2012 I'm not very familiar with the GDC glue code yet, but I'm not sure if 1
- Iain Buclaw (14/48) Jun 13 2012 I can check this, but the side of the issue when I checked some time
- Johannes Pfau (7/25) Jun 14 2012 So DECL_INITIAL would do a type check? That would detect size
- Andrew Wiley (7/33) Jun 04 2012 n-anchors-broken-on-arm>
- Matthew Caron (13/15) Jun 04 2012 D'oh, that was it.
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 bits=1, alloc_size=0x0) at /home/mattc/workspace/d/buildder/.build/src/gcc-4.6.2/libphobos/gc/gcx.d:1224 No locals. ba=<value optimized out>) at /home/mattc/workspace/d/buildder/.build/src/gcc-4.6.2/libphobos/gc/gc.d:201 No locals. 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 access memory at address 0x1 ) at /home/mattc/workspace/d/buildder/.build/src/gcc-4.6.2/libphobos/gc/gcx.d:245 No locals. 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} at /home/mattc/workspace/d/buildder/.build/src/gcc-4.6.2/libphobos/gc/gc.d:133 No locals. at /home/mattc/workspace/d/buildder/.build/src/gcc-4.6.2/libphobos/rt/dmain2.d:67 No locals. {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. 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
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 bits=1, alloc_size=0x0) at /home/mattc/workspace/d/buildder/.build/src/gcc-4.6.2/libphobos/gc/gcx.d:1224 No locals. ba=<value optimized out>) at /home/mattc/workspace/d/buildder/.build/src/gcc-4.6.2/libphobos/gc/gc.d:201 No locals. 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 memory at address 0x1 ) at /home/mattc/workspace/d/buildder/.build/src/gcc-4.6.2/libphobos/gc/gcx.d:245 No locals. 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} at /home/mattc/workspace/d/buildder/.build/src/gcc-4.6.2/libphobos/gc/gc.d:133 No locals. at /home/mattc/workspace/d/buildder/.build/src/gcc-4.6.2/libphobos/rt/dmain2.d:67 No locals. {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. 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
Andrew Wiley <wiley.andrew.j gmail.com> 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:org/goshawk/gdc/wiki/crosstool-ng>Hey folks, So, I've used the instructions and code here: https://bitbucket.org/goshawk/**gdc/wiki/crosstool-ng<https://bitbucket.=cx.d: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=8,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 fullessbits=3D1, alloc_size=3D0x0) at /home/mattc/workspace/d/**buildder/.build/src/gcc-4.6.2/** libphobos/gc/gcx.d:1224 No locals. ba=3D<value optimized out>) at /home/mattc/workspace/d/**buildder/.build/src/gcc-4.6.2/** libphobos/gc/gc.d:201 No locals. 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=cx.d: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=18)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 access memory at address 0x1 ) at /home/mattc/workspace/d/**buildder/.build/src/gcc-4.6.2/** libphobos/gc/gcx.d:245 No locals.,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=4},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=r =3D 0x0,interfaces =3D {length =3D 0, ptr =3D 0x0}, base =3D 0xda804, destructo=length =3DclassInvariant =3D 0, m_flags =3D 54, deallocator =3D 0x0, m_offTi =3D {=?0, ptr =3D 0x0}, defaultConstructor =3D 0x0, xgetMembers =3D 0} at /home/mattc/workspace/d/**buildder/.build/src/gcc-4.6.2/** libphobos/gc/gc.d:133 No locals. at /home/mattc/workspace/d/**buildder/.build/src/gcc-4.6.2/** libphobos/rt/dmain2.d:67 No locals. {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. 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=You certainly need to do this, but -O0 means that 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?Please try building libphobos and libdruntime with -fno-section-anchors.
Jun 01 2012
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, 0x00045364 <_D2gc3gcx3Gcx16fullcollectshellMFZk+12>: sub sp, sp, 0x00045368 <_D2gc3gcx3Gcx16fullcollectshellMFZk+16>: str r0, 0x0004536c <_D2gc3gcx3Gcx16fullcollectshellMFZk+20>: ldr r3, 0x00045370 <_D2gc3gcx3Gcx16fullcollectshellMFZk+24>: str r3, 0x00045374 <_D2gc3gcx3Gcx16fullcollectshellMFZk+28>: ldr r3, ; 0x0 0x0004537c <_D2gc3gcx3Gcx16fullcollectshellMFZk+36>: beq 0x45390 <_D2gc3gcx3Gcx16fullcollectshellMFZk+56> 0x00045380 <_D2gc3gcx3Gcx16fullcollectshellMFZk+40>: ldr r3, 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> ; 0x9 0x00045394 <_D2gc3gcx3Gcx16fullcollectshellMFZk+60>: str r3, 0x00045398 <_D2gc3gcx3Gcx16fullcollectshellMFZk+64>: ldr r3, [pc, 0x0004539c <_D2gc3gcx3Gcx16fullcollectshellMFZk+68>: str r3, ; 0x48 0x000453a4 <_D2gc3gcx3Gcx16fullcollectshellMFZk+76>: str r3, 0x000453a8 <_D2gc3gcx3Gcx16fullcollectshellMFZk+80>: ldr r3, [pc, 0x000453ac <_D2gc3gcx3Gcx16fullcollectshellMFZk+84>: str r3, 0x000453b0 <_D2gc3gcx3Gcx16fullcollectshellMFZk+88>: ldr r3, [pc, 0x000453b4 <_D2gc3gcx3Gcx16fullcollectshellMFZk+92>: str r3, [sp] 0x000453b8 <_D2gc3gcx3Gcx16fullcollectshellMFZk+96>: sub r3, r11, 0x000453bc <_D2gc3gcx3Gcx16fullcollectshellMFZk+100>: ldm r3, {r0, r1} ---Type <return> to continue, or q <return> to quit--- 0x000453c0 <_D2gc3gcx3Gcx16fullcollectshellMFZk+104>: sub r3, r11, 0x000453c4 <_D2gc3gcx3Gcx16fullcollectshellMFZk+108>: ldm r3, {r2, r3} 0x000453c8 <_D2gc3gcx3Gcx16fullcollectshellMFZk+112>: bl 0x21fd8 <_d_assert_msg> ; 0x0 0x000453d0 <_D2gc3gcx3Gcx16fullcollectshellMFZk+120>: str r3, ; 0x0 0x000453d8 <_D2gc3gcx3Gcx16fullcollectshellMFZk+128>: str r3, 0x000453dc <_D2gc3gcx3Gcx16fullcollectshellMFZk+132>: sub r3, r11, 0x000453e0 <_D2gc3gcx3Gcx16fullcollectshellMFZk+136>: str r3, 0x000453e4 <_D2gc3gcx3Gcx16fullcollectshellMFZk+140>: ldr r2, 0x000453e8 <_D2gc3gcx3Gcx16fullcollectshellMFZk+144>: ldr r3, 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, 0x00045400 <_D2gc3gcx3Gcx16fullcollectshellMFZk+168>: ldr r3, 0x00045404 <_D2gc3gcx3Gcx16fullcollectshellMFZk+172>: str r3, 0x00045408 <_D2gc3gcx3Gcx16fullcollectshellMFZk+176>: ldr r3, ; 0x0 0x00045410 <_D2gc3gcx3Gcx16fullcollectshellMFZk+184>: beq 0x45424 <_D2gc3gcx3Gcx16fullcollectshellMFZk+204> 0x00045414 <_D2gc3gcx3Gcx16fullcollectshellMFZk+188>: ldr r3, 0x00045418 <_D2gc3gcx3Gcx16fullcollectshellMFZk+192>: mov r0, r3 0x0004541c <_D2gc3gcx3Gcx16fullcollectshellMFZk+196>: bl 0x4241c <_D2gc3gcx3Gcx11__invariantMFZv> 0x00045420 <_D2gc3gcx3Gcx16fullcollectshellMFZk+200>: b 0x45444 <_D2gc3gcx3Gcx16fullcollectshellMFZk+236> ; 0x0 0x00045428 <_D2gc3gcx3Gcx16fullcollectshellMFZk+208>: str r3, 0x0004542c <_D2gc3gcx3Gcx16fullcollectshellMFZk+212>: ldr r3, [pc, ; 0x45464 <_D2gc3gcx3Gcx16fullcollectshellMFZk+268> 0x00045430 <_D2gc3gcx3Gcx16fullcollectshellMFZk+216>: str r3, 0x00045434 <_D2gc3gcx3Gcx16fullcollectshellMFZk+220>: sub r3, r11, 0x00045438 <_D2gc3gcx3Gcx16fullcollectshellMFZk+224>: ldm r3, {r0, r1} ; 0x0 0x00045440 <_D2gc3gcx3Gcx16fullcollectshellMFZk+232>: bl 0x22018 <_d_assert> 0x00045444 <_D2gc3gcx3Gcx16fullcollectshellMFZk+236>: ldr r3, 0x00045448 <_D2gc3gcx3Gcx16fullcollectshellMFZk+240>: mov r0, r3 0x0004544c <_D2gc3gcx3Gcx16fullcollectshellMFZk+244>: sub sp, r11, 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, -- Matthew Caron, Build Engineer Sixnet, a Red Lion business | www.sixnet.com +1 (518) 877-5173 x138 office
Jun 04 2012
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
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>: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';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?
Jun 11 2012
And I guess 1 means a lot more work but would be the better option apart from that?!
Jun 11 2012
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
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>: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.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.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
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.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.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.
Jun 14 2012
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:n-anchors-broken-on-arm>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/=issue/120/fsection-anchors-broken-on-arm#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=?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` ?(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}
Jun 04 2012
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