View mode: basic / threaded / horizontal-split · Log in · Help
June 01, 2012
libphobos on ARM
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
June 01, 2012
Re: libphobos on ARM
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
June 02, 2012
Re: libphobos on ARM
On Fri, Jun 1, 2012 at 3:24 PM, Alex Rønne Petersen <alex@lycus.org> wrote:

> 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.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 _**D2gc3gcx3Gcx16fullcollectshell**MFZk (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 _**D2gc3gcx3Gcx16fullcollectshell**MFZk (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 _**D2gc3gcx2GC18fullCollectNoStac**kMFZv (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.
>
>
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?
June 04, 2012
Re: libphobos on ARM
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-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?


(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
June 04, 2012
Re: libphobos on ARM
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ø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<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<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?
>>
>
>
> (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` ?
June 05, 2012
Re: libphobos on ARM
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
June 11, 2012
Re: libphobos on ARM
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?
June 11, 2012
Re: libphobos on ARM
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';
June 11, 2012
Re: libphobos on ARM
And I guess 1 means a lot more work but would be the better option apart  
from that?!
June 13, 2012
Re: libphobos on ARM
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?
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home