Re: [Lightning] Porting GNU Smalltalk to lightning 2

[Paulo César Pereira de Andrade]

2014-11-21 19:54 GMT-02:00 Holger Hans Peter Freyther <address@hidden>:
> On Thu, Nov 20, 2014 at 09:40:12PM -0200, Paulo César Pereira de Andrade 
> wrote:
>
> Good Evening,

  Hi,

>> http://git.savannah.gnu.org/cgit/lightning.git/commit/?id=3f397228f5f1f27f3a8a264530a11895fbc9fb79
>
> I natively compiled on the TI Davinci and run make check. I am
> just reporting the first error here. It looks like str has the
> registers mixed up as well? You probably want to store to [r12]
> the value from register r4?

  It actually looks more like this:

  movi_f %f0 0.5 // or whatever 0x3f000000 is
  sti 0xe59fdfe0 %f0


> Starting program: /home/root/lightning/check/.libs/lightning ldsti.tst
> Cannot access memory at address 0x0
> Alignment trap: lightning (8325) PC=0xb6faf050 Instr=0xe584c000 
> Address=0x00000001 FSR 0x801
>
> Program received signal SIGSEGV, Segmentation fault.
> 0xb6faf050 in ?? ()
> (gdb) bt
> #0  0xb6faf050 in ?? ()
> #1  0xe1cc20f0 in ?? ()
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
> (gdb) x/10i $pc-16
>    0xb6faf040:  mov     r12, #1056964608        ; 0x3f000000
>    0xb6faf044:  str     r12, [r11, #-8]
>    0xb6faf048:  ldr     r12, [r11, #-8]
>    0xb6faf04c:  ldr     r6, [pc, #24]   ; 0xb6faf06c
> => 0xb6faf050:  str     r12, [r4]

my first guess is that it should have been "str r12, [r6]"
I cannot reproduce it in my test environment, but these days
all I do for arm is to run the tests in qemu (all other ports I
run tests in actual hardware....).

  Please make sure to build lightning with --enable-assertions.
All I can think of right now is that something is overwriting the
wrong field of the instruction being generated. A build with
--enable-assertions would fail to generate jit if there is an
overwrite of an "encoding" field (but there may be a bug in
the assertions to check it would not overwrite something
else).

>    0xb6faf054:  mov     r2, #0
>    0xb6faf058:  ldr     r3, [pc, #16]   ; 0xb6faf070
>    0xb6faf05c:  strd    r2, [r11, #-8]
>    0xb6faf060:  ldr     lr, [pc, #12]   ; 0xb6faf074
>    0xb6faf064:  ldrd    r2, [r11, #-8]
> (gdb) info reg
> r0             0x0      0
> r1             0xbefffd84       3204447620
> r2             0x44156bb8       1142254520
> r3             0x0      0
> r4             0x1      1
> r5             0x80000001       2147483649
> r6             0xe59fdfe0       3852460000
> r7             0xe14b20f8       3779797240
> r8             0x0      0
> r9             0xffe    4094
> r10            0x23a38  145976
> r11            0xbeffdbc8       3204438984
> r12            0x3f000000       1056964608
> sp             0xbeffdb80       0xbeffdb80
> lr             0xe1cc20f0       3788251376
> pc             0xb6faf050       0xb6faf050
> cpsr           0x60000010       1610612752

  Please try this:

$ cd check
$ cp ldsti.tst x.tst
$ vi x.tst

<< comment the line
 LDST(v0, v1, v2, r0, r1, r2, f0, f1, f2, f3, f4, f5)
either with // or an #if 0, #endif sequence >>

$ make debug
(gdb) b _jit_clear_state
(gdb) r -v x.tst
(gdb) p jit_cpu
(gdb) c

just in case, if I do the above (but s/x.tst/ldsti.tst), and after the
breakpoint, run

(gdb) set jit_cpu.version=5
(gdb) set jit_cpu.extend=1
(gdb) set jit_cpu.vfp=0
(gdb) set jit_cpu.neon=0
(gdb) c

it works for me :(

In the worst case, I may need, if possible to login in the board, hopefully
only for a few minutes, so that I could better understand what is going on.

Other useful version is output "gcc -v"

Thanks,
Paulo