search

larsbrinkhoff / lbForth

Self-hosting metacompiled Forth, bootstrapping from a few lines of C; targets Linux, Windows, ARM, RISC-V, 68000, PDP-11, asm.js.
GNU General Public License v3.0
439 stars 113 forks source link

Building lbforth on arm 64bit Angstrom Linux #97

Open Phi-Ho opened 3 years ago

Phi-Ho commented 3 years ago

Greetings,

I am trying to build lbforth on this platform:

root@de10-nano:~ uname -a Linux de10-nano 4.1.33-ltsi-altera #1 SMP Thu Mar 30 10:37:56 PDT 2017 armv7l GNU/Linux root@de10-nano:~

and got this error:

$ make TARGET=arm OS=linux make -ftargets/c/bootstrap.mk make[1]: Entering directory '/home/hph/lbForth' make[1]: Circular kernel.c <- b-forth dependency dropped. gcc -m32 -O2 -fomit-frame-pointer -fno-unit-at-a-time -Itargets/c targets/c/params.c -o params gcc: error: unrecognized command line option '-m32' make[1]: [targets/c/forth.mk:25: params] Error 1 make[1]: Leaving directory '/home/hph/lbForth' make: [Makefile:27: b-forth] Error 2 de10-nano:~/lbForth$

How can lbforth be built on a 64bit Arm Linux platform?

Regards,

phiho

larsbrinkhoff commented 3 years ago

Uname says armv7, is that A32 or A64?

lbForth only supports the classic A32 instruction set. But I believe Aarch64 should support that. Your error is due to the -m32 option which gcc doesn't like. Is there something else to make gcc build for a 32-bit target? Maybe try just to drop -m32.

Phi-Ho commented 3 years ago

Hi,

I think it is 64 bit. I am really new to this platform.

Maybe a meta copy of lbforth for ARM would work? Do you happen to have that available?

Thank you,

phiho

On Wed, Jan 20, 2021 at 8:34 AM Lars Brinkhoff notifications@github.com wrote:

Uname says armv7, is that A32 or A64?

lbForth only supports the classic A32 instruction set. But I believe Aarch64 should support that. Your error is due to the -m32 option which gcc doesn't like. Is there something else to make gcc build for a 32-bit target? Maybe try just to drop -m32.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/larsbrinkhoff/lbForth/issues/97#issuecomment-763609009, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABDAWSQ2CVBJFQGAR7MOPBDS23LYHANCNFSM4WKVMDYA .

larsbrinkhoff commented 3 years ago

I believe this should work:

make TARGET=arm OS=linux M32=

Note, nothing after M32=. This is to disable the use of -m32 which isn't supported with the ARM gcc.

Phi-Ho commented 3 years ago

Hi,

Thank you.

I am trying to build clisp on this platform with:

./configure --ignore-absence-of-libsigsegv

and make failed with tons "undefined reference" errors.

phiho

On Wed, Jan 20, 2021 at 9:42 AM Lars Brinkhoff notifications@github.com wrote:

I believe this should work:

make TARGET=arm OS=linux M32=

Note, nothing after M32=. This is to disable the use of -m32 which isn't supported with the ARM gcc.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/larsbrinkhoff/lbForth/issues/97#issuecomment-763651965, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABDAWSQICBNZSGGAD6ITATLS23TTZANCNFSM4WKVMDYA .

larsbrinkhoff commented 3 years ago

Oh, you don't have a working Lisp. I used "apt-get install sbcl".

I build it and here's a tarball. lbForth-arm.zip

Phi-Ho commented 3 years ago

Hi,

Thank you so much. It is a bit strange. arm-forth and forth core dumped, occasionally not b-forth is always OK Any reasons for this behavior?

Thanks, again for your help. It is much appreciated.

Cheers,

phiho

de10-nano:~/lbForth-arm/lbForth$ ./arm-forth lbForth Illegal instruction (core dumped)

de10-nano:~/lbForth-arm/lbForth$ ./forth lbForth Illegal instruction (core dumped)

de10-nano:~/lbForth-arm/lbForth$ ./b-forth lbForth 1 2 3 4 ok ok .s

<4> 1 2 3 4 ok bye de10-nano:~/lbForth-arm/lbForth$ ./forth lbForth ok bye de10-nano:~/lbForth-arm/lbForth$ ./arm-forth lbForth Illegal instruction (core dumped) de10-nano:~/lbForth-arm/lbForth$ On Wed, Jan 20, 2021 at 12:53 PM Lars Brinkhoff wrote: > Oh, you don't have a working Lisp. I used "apt-get install sbcl". > > I build it and here's a tarball. > lbForth-arm.zip > > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > , > or unsubscribe > > . >
larsbrinkhoff commented 3 years ago

I have no explanation for why arm-forth and fort dump core. Possibly something about them being ELF files written from Forth itself. They seem to work reliably on my Raspberry Pi, but maybe something in the operating system you use is different.

b-forth is the bootstrap Forth build with the C compiler, so it's an ordinary binary executable.

Phi-Ho commented 3 years ago

Hi,

Can you give me the files generated by lisp so that I can bypass the lisp steps?

Thanks,

phiho

On Wed, Jan 20, 2021 at 2:25 PM Lars Brinkhoff notifications@github.com wrote:

I have no explanation for why arm-forth and fort dump core. Possibly something about them being ELF files written from Forth itself. They seem to work reliably on my Raspberry Pi, but maybe something in the operating system you use is different.

b-forth is the bootstrap Forth build with the C compiler, so it's an ordinary binary executable.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/larsbrinkhoff/lbForth/issues/97#issuecomment-763877891, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABDAWSXKCKU3IWORNOL63VDS24U4BANCNFSM4WKVMDYA .

Phi-Ho commented 3 years ago

Hi,

Just FYI, I am using your b-forth to metacompile lb-forth on my platform and the newly created lb4's also behave like your arm-forth and forth. I also tried to strip b-forth but that did not make any differences.

phiho

On Wed, Jan 20, 2021 at 2:39 PM ph h hohoangphi@gmail.com wrote:

Hi,

Can you give me the files generated by lisp so that I can bypass the lisp steps?

Thanks,

phiho

On Wed, Jan 20, 2021 at 2:25 PM Lars Brinkhoff notifications@github.com wrote:

I have no explanation for why arm-forth and fort dump core. Possibly something about them being ELF files written from Forth itself. They seem to work reliably on my Raspberry Pi, but maybe something in the operating system you use is different.

b-forth is the bootstrap Forth build with the C compiler, so it's an ordinary binary executable.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/larsbrinkhoff/lbForth/issues/97#issuecomment-763877891, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABDAWSXKCKU3IWORNOL63VDS24U4BANCNFSM4WKVMDYA .

Phi-Ho commented 3 years ago

Hi,

I am trying to locate the issue by sprinkling emit throughout core.fth and it looks like this definition:

: unresolved postpone postpone postpone >mark ; immediate

was causing the problem.

Please find appended below the emit's in core.fth and the test runs console output . Please note that "91 emit" print [ and "93 emit" print ]

What do you think?

Regards,

phiho

69 emit

: postpone parse-name postpone-name ; compile-only

69 emit 91 emit

: unresolved postpone postpone postpone >mark ; immediate

93 emit 70 emit

: ahead unresolved branch ; compile-only : if unresolved 0branch ; compile-only : then >resolve ; compile-only

70 emit

: resolving postpone postpone postpone <resolve ; immediate

The test runs gave this:

de10-nano:~/lbForth$ ./lb4-2 lbForth ABCDEF[]FFFFFG0 1 2 3 4 5 ok bye

de10-nano:~/lbForth$ ./lb4-2 lbForth ABCDEE[Segmentation fault (core dumped) de10-nano:~/lbForth$ ./lb4-2 lbForth ABCDEE[Illegal instruction (core dumped)

de10-nano:~/lbForth$ ./lb4-2 lbForth ABCDEE[]FFFFFG0 1 2 3 4 5 ok bye

de10-nano:~/lbForth$ ./lb4-2 lbForth ABCDEE[Illegal instruction (core dumped)

de10-nano:~/lbForth$ ./lb4-3 lbForth ABCDEE[]FFFFFG0 1 2 3 4 5 ok bye

de10-nano:~/lbForth$ ./lb4-4 lbForth ABCDEE[]FFFFFG0 1 2 3 4 5 ok bye

de10-nano:~/lbForth$ ./lb4-1 lbForth ABCDEE[Illegal instruction (core dumped)

de10-nano:~/lbForth$ ./lb4-1 lbForth ABCDEE[]FFFFFG0 1 2 3 4 5 ok

On Wed, Jan 20, 2021 at 4:16 PM ph h hohoangphi@gmail.com wrote:

Hi,

Just FYI, I am using your b-forth to metacompile lb-forth on my platform and the newly created lb4's also behave like your arm-forth and forth. I also tried to strip b-forth but that did not make any differences.

phiho

On Wed, Jan 20, 2021 at 2:39 PM ph h hohoangphi@gmail.com wrote:

Hi,

Can you give me the files generated by lisp so that I can bypass the lisp steps?

Thanks,

phiho

On Wed, Jan 20, 2021 at 2:25 PM Lars Brinkhoff notifications@github.com wrote:

I have no explanation for why arm-forth and fort dump core. Possibly something about them being ELF files written from Forth itself. They seem to work reliably on my Raspberry Pi, but maybe something in the operating system you use is different.

b-forth is the bootstrap Forth build with the C compiler, so it's an ordinary binary executable.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/larsbrinkhoff/lbForth/issues/97#issuecomment-763877891, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABDAWSXKCKU3IWORNOL63VDS24U4BANCNFSM4WKVMDYA .

larsbrinkhoff commented 3 years ago

It's worrying that the error comes and goes randomly.

But the good news is that you have narrowed down to a specific location, so that part isn't random.

Do you have a debugger on the target? If you could run lbForth under the debugger, hopefully it should stop and display the point where it crashes. What is the "illegal instruction" it's trying to execute?

Phi-Ho commented 3 years ago

Hi,

Now we know where it is happening but not when it is happening.

gdb is available on this platform, please advise how you would like to set up a debugging session.

Thanks,

phiho

On Thu, Jan 21, 2021 at 1:46 AM Lars Brinkhoff notifications@github.com wrote:

It's worrying that the error comes and goes randomly.

But the good news is that you have narrowed down to a specific location, so that part isn't random.

Do you have a debugger on the target? If you could run lbForth under the debugger, hopefully it should stop and display the point where it crashes. What is the "illegal instruction" it's trying to execute?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/larsbrinkhoff/lbForth/issues/97#issuecomment-764421213, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABDAWSTIDFDBZDFNZF4XN4TS27EVDANCNFSM4WKVMDYA .

larsbrinkhoff commented 3 years ago

It should look something like this:

$ gdb arm-forth
GNU gdb [...]
Copyright (C) 2016 Free Software Foundation, Inc.
[...]
(gdb) run
Starting program: /home/lars/src/lbForth/forth
lbForth
Program received signal SIGILL
0x080485e1 in ?? ()
(gdb) disassemble $pc-10, $pc+20
Dump of assembler code from 0x80485d7 to 0x80485f5:

And then the last part would be the machine code around the failure point.

Phi-Ho commented 3 years ago

Hi,

de10-nano:~/lbForth$ gdb ./forth GNU gdb (Linaro GDB) 7.8-2014.09 Copyright (C) 2014 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html

This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "arm-angstrom-linux-gnueabi". Type "show configuration" for configuration details. For bug reporting instructions, please see: http://bugs.linaro.org. Find the GDB manual and other documentation resources online at: http://www.gnu.org/software/gdb/documentation/. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from ./forth...(no debugging symbols found)...done. Breakpoint 1 at 0x804aa18 Cannot access memory at address 0x0 Cannot access memory at address 0x0 lbForth ABCDE[Cannot access memory at address 0x0

Program received signal SIGSEGV, Segmentation fault. 0x0804af40 in ?? () (gdb) (gdb) disassemble $pc-10, $pc+20 Dump of assembler code from 0x804af36 to 0x804af54: 0x0804af36: rsbsvc r7, r4, pc, ror #6 0x0804af3a: stclcs 14, cr6, [r5, #-444]! ; 0xfffffe44 0x0804af3e: strbvs r6, [sp, #-366]! ; 0x16e 0x0804af42: cdpge 4, 14, cr1, cr8, cr0, {0} 0x0804af46: svcge 0x000c0804 0x0804af4a: cdpge 8, 12, cr0, cr0, cr4, {0} 0x0804af4e: strbls r0, [r8, #2052]! ; 0x804 0x0804af52: svchi 0x00800804 End of assembler dump. (gdb)

And then the last part would be the machine coud around the failure point.

How can we relate the gdb disassembly to where in 'forth' ?

Is 'forth' trying to compile ' unresolved ' to address 0x00:

: unresolved postpone postpone postpone >mark ; immediate

This compilation looks rather simple, doesn't it.

Thanks,

phiho

On Thu, Jan 21, 2021 at 3:58 AM Lars Brinkhoff notifications@github.com wrote:

It should look something like this:

$ gdb arm-forth GNU gdb [...] Copyright (C) 2016 Free Software Foundation, Inc. [...] (gdb) run Starting program: /home/lars/src/lbForth/forth lbForth Program received signal SIGILL 0x080485e1 in ?? () (gdb) disassemble $pc-10, $pc+20 Dump of assembler code from 0x80485d7 to 0x80485f5:

And then the last part would be the machine coud around the failure point.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/larsbrinkhoff/lbForth/issues/97#issuecomment-764485297, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABDAWSSNNHJS36YXNKC3P3LS27UEBANCNFSM4WKVMDYA .

larsbrinkhoff commented 3 years ago

Oops, sorry! Please use disassemble $pc-16, $pc+32 instead.

Phi-Ho commented 3 years ago

Here we go:

de10-nano:~/lbForth$ gdb ./arm-forth GNU gdb (Linaro GDB) 7.8-2014.09 Copyright (C) 2014 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html

This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "arm-angstrom-linux-gnueabi". Type "show configuration" for configuration details. For bug reporting instructions, please see: http://bugs.linaro.org. Find the GDB manual and other documentation resources online at: http://www.gnu.org/software/gdb/documentation/. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from ./arm-forth...(no debugging symbols found)...done. Breakpoint 1 at 0x804aa18 Cannot access memory at address 0x0 Cannot access memory at address 0x0 lbForth ABCDE[]JKLMNOP0 1 2 3 4 5 ok bye [Inferior 1 (process 3480) exited normally]

(gdb) run Starting program: /home/hph/lbForth/arm-forth Cannot access memory at address 0x0 Cannot access memory at address 0x0 lbForth ABCDE[]JKLMNOP0 1 2 3 4 5 ok bye [Inferior 1 (process 3483) exited normally]

(gdb) run Starting program: /home/hph/lbForth/arm-forth Cannot access memory at address 0x0 Cannot access memory at address 0x0 lbForth ABCDE[Cannot access memory at address 0x0

Program received signal SIGILL, Illegal instruction. 0x0805c3ac in ?? () (gdb) disassemble $pc-16, $pc+32 Dump of assembler code from 0x805c39c to 0x805c3cc: 0x0805c39c: andeq r0, r0, r0 0x0805c3a0: andeq r0, r0, r0 0x0805c3a4: andeq r0, r0, r0 0x0805c3a8: andeq r0, r0, r0 => 0x0805c3ac: ; instruction: 0xffffffe0 0x0805c3b0: ; instruction: 0xffffffa0 0x0805c3b4: ; instruction: 0xffffff9f 0x0805c3b8: ; instruction: 0xffffff9f 0x0805c3bc: ; instruction: 0xffffff3e 0x0805c3c0: ; instruction: 0xffffffff 0x0805c3c4: andeq r0, r0, r1 0x0805c3c8: ; instruction: 0xffffffff End of assembler dump. (gdb) disassemble $pc-32, $pc+64 Dump of assembler code from 0x805c38c to 0x805c3ec: 0x0805c38c: andeq r0, r0, r0 0x0805c390: andeq r0, r0, r0 0x0805c394: andeq r0, r0, r0 0x0805c398: andeq r0, r0, r0 0x0805c39c: andeq r0, r0, r0 0x0805c3a0: andeq r0, r0, r0 0x0805c3a4: andeq r0, r0, r0 0x0805c3a8: andeq r0, r0, r0 => 0x0805c3ac: ; instruction: 0xffffffe0 0x0805c3b0: ; instruction: 0xffffffa0 0x0805c3b4: ; instruction: 0xffffff9f 0x0805c3b8: ; instruction: 0xffffff9f 0x0805c3bc: ; instruction: 0xffffff3e 0x0805c3c0: ; instruction: 0xffffffff 0x0805c3c4: andeq r0, r0, r1 0x0805c3c8: ; instruction: 0xffffffff 0x0805c3cc: ; instruction: 0xffffff88 0x0805c3d0: ; instruction: 0xffffffe0 0x0805c3d4: ; instruction: 0xffffffc0 0x0805c3d8: ; instruction: 0xffffffff 0x0805c3dc: andeq r0, r0, r1 0x0805c3e0: andeq r0, r0, r1 0x0805c3e4: ; instruction: 0xffffffff 0x0805c3e8: andeq r0, r0, r8 End of assembler dump. (g

On Thu, Jan 21, 2021 at 10:00 AM Lars Brinkhoff notifications@github.com wrote:

Oops, sorry! Please use disassemble $pc-16, $pc+32 instead.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/larsbrinkhoff/lbForth/issues/97#issuecomment-764702473, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABDAWSQLHALZ7JVWU5OFSU3S3A6P5ANCNFSM4WKVMDYA .

larsbrinkhoff commented 3 years ago

Thank you. It looks like the disassembly isn't any part of the lbForth code. So there was probably a bad jump going to a random address.

Unfortunately there's no clue why this happens, so I can't do much about it.

Phi-Ho commented 3 years ago

Hi,

It looks like the disassembly isn't any part of the lbForth code. So there was probably a bad jump going to a random address.

Is there a feature in gdb that shows the instruction before the current PC in the flow?

I am wondering why " Cannot access memory at address 0x0" also happened at the beginning when arm-forth was started even though there were no segfaults later on.

Reading symbols from ./arm-forth...(no debugging symbols found)...done. Breakpoint 1 at 0x804aa18 Cannot access memory at address 0x0 Cannot access memory at address 0x0 lbForth ABCDE[]JKLMNOP0 1 2 3 4 5 ok bye [Inferior 1 (process 3480) exited normally]

(gdb) run Starting program: /home/hph/lbForth/arm-forth Cannot access memory at address 0x0 Cannot access memory at address 0x0 lbForth ABCDE[]JKLMNOP0 1 2 3 4 5 ok bye

Please note that the disassembly I just sent is from a different run of gdb from the one sent before. I kept running arm-forth from the same gdb instance and got another seg fault, the PC seems to point to the same location 0x0805c3ac:

(gdb) disassemble $pc-16, $pc+32 Dump of assembler code from 0x805c39c to 0x805c3cc: 0x0805c39c: andeq r0, r0, r0 0x0805c3a0: andeq r0, r0, r0 0x0805c3a4: andeq r0, r0, r0 0x0805c3a8: andeq r0, r0, r0 => 0x0805c3ac: ; instruction: 0xffffffe0 0x0805c3b0: ; instruction: 0xffffffa0 0x0805c3b4: ; instruction: 0xffffff9f 0x0805c3b8: ; instruction: 0xffffff9f 0x0805c3bc: ; instruction: 0xffffff3e 0x0805c3c0: ; instruction: 0xffffffff 0x0805c3c4: andeq r0, r0, r1 0x0805c3c8: ; instruction: 0xffffffff End of assembler dump. (gdb)

I have another question, can this ' unresolved '

: unresolved postpone postpone postpone >mark ; immediate

be refactored or implemented differently?

Thank you for your help.

Regards,

phiho

On Thu, Jan 21, 2021 at 4:02 PM Lars Brinkhoff notifications@github.com wrote:

Thank you. It looks like the disassembly isn't any part of the lbForth code. So there was probably a bad jump going to a random address.

Unfortunately there's no clue why this happens, so I can't do much about it.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/larsbrinkhoff/lbForth/issues/97#issuecomment-764939783, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABDAWSRGI5B4XMVY45BQHRTS3CI65ANCNFSM4WKVMDYA .

Phi-Ho commented 3 years ago

P.S: Backtrace stopped: previous frame identical to this frame (corrupt stack?)

(gdb) run Starting program: /home/hph/lbForth/arm-forth Cannot access memory at address 0x0 Cannot access memory at address 0x0 lbForth ABCDE[Cannot access memory at address 0x0

Program received signal SIGILL, Illegal instruction. 0x0805c3ac in ?? () (gdb) backtrace

0 0x0805c3ac in ?? ()

1 0x00000000 in ?? ()

Backtrace stopped: previous frame identical to this frame (corrupt stack?) (gdb)

On Thu, Jan 21, 2021 at 4:26 PM ph h hohoangphi@gmail.com wrote:

Hi,

It looks like the disassembly isn't any part of the lbForth code. So there was probably a bad jump going to a random address.

Is there a feature in gdb that shows the instruction before the current PC in the flow?

I am wondering why " Cannot access memory at address 0x0" also happened at the beginning when arm-forth was started even though there were no segfaults later on.

Reading symbols from ./arm-forth...(no debugging symbols found)...done. Breakpoint 1 at 0x804aa18 Cannot access memory at address 0x0 Cannot access memory at address 0x0 lbForth ABCDE[]JKLMNOP0 1 2 3 4 5 ok bye [Inferior 1 (process 3480) exited normally]

(gdb) run Starting program: /home/hph/lbForth/arm-forth Cannot access memory at address 0x0 Cannot access memory at address 0x0 lbForth ABCDE[]JKLMNOP0 1 2 3 4 5 ok bye

Please note that the disassembly I just sent is from a different run of gdb from the one sent before. I kept running arm-forth from the same gdb instance and got another seg fault, the PC seems to point to the same location 0x0805c3ac:

(gdb) disassemble $pc-16, $pc+32 Dump of assembler code from 0x805c39c to 0x805c3cc: 0x0805c39c: andeq r0, r0, r0 0x0805c3a0: andeq r0, r0, r0 0x0805c3a4: andeq r0, r0, r0 0x0805c3a8: andeq r0, r0, r0 => 0x0805c3ac: ; instruction: 0xffffffe0 0x0805c3b0: ; instruction: 0xffffffa0 0x0805c3b4: ; instruction: 0xffffff9f 0x0805c3b8: ; instruction: 0xffffff9f 0x0805c3bc: ; instruction: 0xffffff3e 0x0805c3c0: ; instruction: 0xffffffff 0x0805c3c4: andeq r0, r0, r1 0x0805c3c8: ; instruction: 0xffffffff End of assembler dump. (gdb)

I have another question, can this ' unresolved '

: unresolved postpone postpone postpone >mark ; immediate

be refactored or implemented differently?

Thank you for your help.

Regards,

phiho

On Thu, Jan 21, 2021 at 4:02 PM Lars Brinkhoff notifications@github.com wrote:

Thank you. It looks like the disassembly isn't any part of the lbForth code. So there was probably a bad jump going to a random address.

Unfortunately there's no clue why this happens, so I can't do much about it.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/larsbrinkhoff/lbForth/issues/97#issuecomment-764939783, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABDAWSRGI5B4XMVY45BQHRTS3CI65ANCNFSM4WKVMDYA .

Phi-Ho commented 3 years ago

PPS: Can we implement a debug word in lbForth kernel using this instruction (p344 ARM® Architecture Reference Manual ARMv7-A and ARMv7-R edition):

A8.8.24 BKPT Breakpoint causes a software breakpoint to occur. Breakpoint is always unconditional, even when inside an IT block. imm32 = ZeroExtend(imm8, 32); // imm32 is for assembly/disassembly only and is ignored by hardware. imm32 = ZeroExtend(imm12:imm4, 32); // imm32 is for assembly/disassembly only and is ignored by hardware. if cond != ‘1110’ then UNPREDICTABLE; // BKPT must be encoded with AL condition

On Thu, Jan 21, 2021 at 5:29 PM ph h hohoangphi@gmail.com wrote:

P.S: Backtrace stopped: previous frame identical to this frame (corrupt stack?)

(gdb) run Starting program: /home/hph/lbForth/arm-forth Cannot access memory at address 0x0 Cannot access memory at address 0x0 lbForth ABCDE[Cannot access memory at address 0x0

Program received signal SIGILL, Illegal instruction. 0x0805c3ac in ?? () (gdb) backtrace

0 0x0805c3ac in ?? ()

1 0x00000000 in ?? ()

Backtrace stopped: previous frame identical to this frame (corrupt stack?) (gdb)

On Thu, Jan 21, 2021 at 4:26 PM ph h hohoangphi@gmail.com wrote:

Hi,

It looks like the disassembly isn't any part of the lbForth code. So there was probably a bad jump going to a random address.

Is there a feature in gdb that shows the instruction before the current PC in the flow?

I am wondering why " Cannot access memory at address 0x0" also happened at the beginning when arm-forth was started even though there were no segfaults later on.

Reading symbols from ./arm-forth...(no debugging symbols found)...done. Breakpoint 1 at 0x804aa18 Cannot access memory at address 0x0 Cannot access memory at address 0x0 lbForth ABCDE[]JKLMNOP0 1 2 3 4 5 ok bye [Inferior 1 (process 3480) exited normally]

(gdb) run Starting program: /home/hph/lbForth/arm-forth Cannot access memory at address 0x0 Cannot access memory at address 0x0 lbForth ABCDE[]JKLMNOP0 1 2 3 4 5 ok bye

Please note that the disassembly I just sent is from a different run of gdb from the one sent before. I kept running arm-forth from the same gdb instance and got another seg fault, the PC seems to point to the same location 0x0805c3ac:

(gdb) disassemble $pc-16, $pc+32 Dump of assembler code from 0x805c39c to 0x805c3cc: 0x0805c39c: andeq r0, r0, r0 0x0805c3a0: andeq r0, r0, r0 0x0805c3a4: andeq r0, r0, r0 0x0805c3a8: andeq r0, r0, r0 => 0x0805c3ac: ; instruction: 0xffffffe0 0x0805c3b0: ; instruction: 0xffffffa0 0x0805c3b4: ; instruction: 0xffffff9f 0x0805c3b8: ; instruction: 0xffffff9f 0x0805c3bc: ; instruction: 0xffffff3e 0x0805c3c0: ; instruction: 0xffffffff 0x0805c3c4: andeq r0, r0, r1 0x0805c3c8: ; instruction: 0xffffffff End of assembler dump. (gdb)

I have another question, can this ' unresolved '

: unresolved postpone postpone postpone >mark ; immediate

be refactored or implemented differently?

Thank you for your help.

Regards,

phiho

On Thu, Jan 21, 2021 at 4:02 PM Lars Brinkhoff notifications@github.com wrote:

Thank you. It looks like the disassembly isn't any part of the lbForth code. So there was probably a bad jump going to a random address.

Unfortunately there's no clue why this happens, so I can't do much about it.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/larsbrinkhoff/lbForth/issues/97#issuecomment-764939783, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABDAWSRGI5B4XMVY45BQHRTS3CI65ANCNFSM4WKVMDYA .

larsbrinkhoff commented 3 years ago

Is there a feature in gdb that shows the instruction before the current PC in the flow?

I don't think so.

I have another question, can this ' unresolved ' [...] be refactored or implemented differently?

You could remove it and replace all instances of unresolved <foo> with [ ' <foo> ] literal , >mark... I think.

Can we implement a debug word

Try something like this in targets/arm/nucleus.fth:

code bkpt
   bkpt,
   next,
end-code
Phi-Ho commented 3 years ago

Hi,

Thanks for your reply.

Try something like this in targets/arm/nucleus.fth: code bkpt bkpt, next, end-code

de10-nano:~/lbForth$ echo "include targets/arm/build.fth" | ./b-forth lbForth ok

Stack underflow de10-nano:~/lbForth$

Doesn't this look strange?

Does it work on your Pi

Regards,

phiho

On Fri, Jan 22, 2021 at 1:52 AM Lars Brinkhoff notifications@github.com wrote:

Is there a feature in gdb that shows the instruction before the current PC in the flow?

I don't think so.

I have another question, can this ' unresolved ' [...] be refactored or implemented differently?

You could remove it and replace all instances of unresolved with [ ' ] literal , >mark... I think.

Can we implement a debug word

Try something like this in targets/arm/nucleus.fth:

code bkpt bkpt, next, end-code

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/larsbrinkhoff/lbForth/issues/97#issuecomment-765177860, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABDAWSQ7ADZTGGDV72AMJXTS3EOBDANCNFSM4WKVMDYA .

Phi-Ho commented 3 years ago

Hi,

I have another question, can this ' unresolved ' [...] be refactored or implemented differently?

You could remove it and replace all instances of unresolved with [ ' ] literal , >mark... I think.

: ahead [ ' branch ] literal , >mark ; compile-only \ : ahead unresolved branch ; compile-only

\ : if unresolved 0branch ; compile-only : if [ ' 0branch ] literal , >mark ; compile-only

This doesn't seem to help:

de10-nano:~/lbForth$ ./lb4-bp1 lbForth Segmentation fault (core dumped) de10-nano:~/lbForth$ ./lb4-bp1 lbForth Illegal instruction (core dumped) de10-nano:~/lbForth$ ./lb4-bp1 lbForth Illegal instruction (core dumped) de10-nano:~/lbForth$ ./lb4-bp1 lbForth Illegal instruction (core dumped) de10-nano:~/lbForth$ ./lb4-bp1 lbForth ok bye de10-nano:~/lbForth$

It looks like a certain sequence of words causing the segment fault?

Regards,

phiho

On Fri, Jan 22, 2021 at 1:52 AM Lars Brinkhoff notifications@github.com wrote:

Is there a feature in gdb that shows the instruction before the current PC in the flow?

I don't think so.

I have another question, can this ' unresolved ' [...] be refactored or implemented differently?

You could remove it and replace all instances of unresolved with [ ' ] literal , >mark... I think.

Can we implement a debug word

Try something like this in targets/arm/nucleus.fth:

code bkpt bkpt, next, end-code

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/larsbrinkhoff/lbForth/issues/97#issuecomment-765177860, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABDAWSQ7ADZTGGDV72AMJXTS3EOBDANCNFSM4WKVMDYA .

Phi-Ho commented 3 years ago

P.S: I tried at the top and the end of targets/arm/nucleus.fth.

1/- At the top

\ -- forth -- Copyright 2016 Lars Brinkhoff

\ Nucleus for ARM.

include targets/arm/next.fth

hex target exe-code

code bkpt bkpt, next, end-code

code sp@ S push, next, end-code

de10-nano:~/lbForth$ echo "include targets/arm/build.fth" | ./b-forth > lb4-bp-top

de10-nano:~/lbForth$ cat lb4-bp-top lbForth ok

Stack underflow de10-nano:~/lbForth$

2/- At the end:

code rshift W pop, S ) T ldr, T W lsr T mov, S ) T str, next, end-code

code bkpt bkpt, next, end-code

decimal

de10-nano:~/lbForth$ echo "include targets/arm/build.fth" | ./b-forth > lb4-bp-bottom de10-nano:~/lbForth$ de10-nano:~/lbForth$ cat lb4-bp-bottom lbForth ok

Stack underflow de10-nano:~/lbForth$

On Fri, Jan 22, 2021 at 4:17 PM ph h hohoangphi@gmail.com wrote:

Hi,

I have another question, can this ' unresolved ' [...] be refactored or implemented differently?

You could remove it and replace all instances of unresolved with [ ' ] literal , >mark... I think.

: ahead [ ' branch ] literal , >mark ; compile-only \ : ahead unresolved branch ; compile-only

\ : if unresolved 0branch ; compile-only : if [ ' 0branch ] literal , >mark ; compile-only

This doesn't seem to help:

de10-nano:~/lbForth$ ./lb4-bp1 lbForth Segmentation fault (core dumped) de10-nano:~/lbForth$ ./lb4-bp1 lbForth Illegal instruction (core dumped) de10-nano:~/lbForth$ ./lb4-bp1 lbForth Illegal instruction (core dumped) de10-nano:~/lbForth$ ./lb4-bp1 lbForth Illegal instruction (core dumped) de10-nano:~/lbForth$ ./lb4-bp1 lbForth ok bye de10-nano:~/lbForth$

It looks like a certain sequence of words causing the segment fault?

Regards,

phiho

On Fri, Jan 22, 2021 at 1:52 AM Lars Brinkhoff notifications@github.com wrote:

Is there a feature in gdb that shows the instruction before the current PC in the flow?

I don't think so.

I have another question, can this ' unresolved ' [...] be refactored or implemented differently?

You could remove it and replace all instances of unresolved with [ ' ] literal , >mark... I think.

Can we implement a debug word

Try something like this in targets/arm/nucleus.fth:

code bkpt bkpt, next, end-code

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/larsbrinkhoff/lbForth/issues/97#issuecomment-765177860, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABDAWSQ7ADZTGGDV72AMJXTS3EOBDANCNFSM4WKVMDYA .

larsbrinkhoff commented 3 years ago

Sorry, it should be 0 # bkpt,. Apparently the BKPT instruction includes an immediate number.

I get this: 


lbForth
ok
: foo ." hello" cr ;
 ok
foo
hello
 ok
: bar ." 1" bkpt ." 2" ;
 ok
bar
1Trace/breakpoint trap
Phi-Ho commented 3 years ago

Hi,

Thank you so much, there may be some light at the end of the tunnel ;-)

Before the break point was inserted:

Program received signal SIGILL, Illegal instruction. 0x0805c3c8 in ?? ()

The breakpoint bp0 was inserted like so:

==================== : postpone parse-name postpone-name ; compile-only

bp0

: unresolved postpone postpone postpone >mark ; immediate

Program received signal SIGTRAP, Trace/breakpoint trap. 0x0804823c in ?? ()

Please find appended below "disassemble $pc-32, $pc+64 ", hopefully you can tell what is going on in the " unresolved "

Cheers,

phiho

(gdb) disassemble $pc-32, $pc+64 Dump of assembler code from 0x804821c to 0x804827c: 0x0804821c: svc 0x00000000 0x08048220: str r0, [r9] 0x08048224: ldr r4, [r5], #4 0x08048228: ldr pc, [r4] 0x0804822c: rsbscc r6, r0, r3, lsl #4 0x08048230: stceq 0, cr0, [r0], {-0} 0x08048234: stmdaeq r4, {r4, r9, pc} 0x08048238: stmdaeq r4, {r2, r3, r4, r5, r9, pc} => 0x0804823c: bkpt 0x0000 0x08048240: ldr r4, [r5], #4 0x08048244: ldr pc, [r4] 0x08048248: rsbsmi r7, r0, r3, lsl #6 0x0804824c: stceq 0, cr0, [r0], {-0} 0x08048250: stmdaeq r4, {r3, r4, r5, r9, pc} 0x08048254: stmdaeq r4, {r3, r4, r6, r9, pc} 0x08048258: str r9, [r9, #-4]! 0x0804825c: ldr r4, [r5], #4 0x08048260: ldr pc, [r4] 0x08048264: cmncs r0, r3, lsl #6 0x08048268: stceq 0, cr0, [r0], {-0} 0x0804826c: stmdaeq r4, {r2, r4, r6, r9, pc} 0x08048270: stmdaeq r4, {r2, r4, r5, r6, r9, pc} 0x08048274: ldr r9, [r9], #4 0x08048278: ldr r4, [r5], #4 End of assembler dump. (gdb)

On Sat, Jan 23, 2021 at 3:51 PM Lars Brinkhoff notifications@github.com wrote:

Sorry, it should be 0 # bkpt,. Apparently the BKPT instruction includes an immediate number.

I get this:

lbForth ok : foo ." hello" cr ; ok foo hello ok : bar ." 1" bkpt ." 2" ; ok bar 1Trace/breakpoint trap

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/larsbrinkhoff/lbForth/issues/97#issuecomment-766177164, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABDAWSTLQKDB2VG63QV7GY3S3MZDXANCNFSM4WKVMDYA .

larsbrinkhoff commented 3 years ago

This by itself doesn't tell us much, but it's a start to go a head and see what happens next. Maybe you can single step and see what is going on with the "unresolved" definition and where it goes astray.

Phi-Ho commented 3 years ago

Hi,

How can I use the User-defined commands, gdb is not very helpful. (Please see below)

Thanks,

phiho

(gdb) help user-defined User-defined commands. The commands in this class are those defined by the user. Use the "define" command to define a command.

List of commands:

forth-step -- User-defined forth-word -- User-defined s -- User-defined

Type "help" followed by command name for full documentation. Type "apropos word" to search for commands related to "word". Command name abbreviations are allowed if unambiguous. (gdb) help forth-step User-defined. (gdb) help forth-word User-defined. (gdb) help s User-defined. (gdb)

On Sun, Jan 24, 2021 at 1:22 AM Lars Brinkhoff notifications@github.com wrote:

This by itself doesn't tell us much, but it's a start to go a head and see what happens next. Maybe you can single step and see what is going on with the "unresolved" definition and where it goes astray.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/larsbrinkhoff/lbForth/issues/97#issuecomment-766299494, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABDAWSVCKJHWW7Y7CAL6PY3S3O4EFANCNFSM4WKVMDYA .

Phi-Ho commented 3 years ago

PS: I can try it on Ubuntu 18 too. It happens the same way on that platform.

On Sun, Jan 24, 2021 at 1:29 AM ph h hohoangphi@gmail.com wrote:

Hi,

How can I use the User-defined commands, gdb is not very helpful. (Please see below)

Thanks,

phiho

(gdb) help user-defined User-defined commands. The commands in this class are those defined by the user. Use the "define" command to define a command.

List of commands:

forth-step -- User-defined forth-word -- User-defined s -- User-defined

Type "help" followed by command name for full documentation. Type "apropos word" to search for commands related to "word". Command name abbreviations are allowed if unambiguous. (gdb) help forth-step User-defined. (gdb) help forth-word User-defined. (gdb) help s User-defined. (gdb)

On Sun, Jan 24, 2021 at 1:22 AM Lars Brinkhoff notifications@github.com wrote:

This by itself doesn't tell us much, but it's a start to go a head and see what happens next. Maybe you can single step and see what is going on with the "unresolved" definition and where it goes astray.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/larsbrinkhoff/lbForth/issues/97#issuecomment-766299494, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABDAWSVCKJHWW7Y7CAL6PY3S3O4EFANCNFSM4WKVMDYA .