Building lbforth on arm 64bit Angstrom Linux #97
Labels
Comments
|
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.
|
|
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 ***@***.***> 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
<#97 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABDAWSQ2CVBJFQGAR7MOPBDS23LYHANCNFSM4WKVMDYA>
.
|
|
I believe this should work: Note, nothing after |
|
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 ***@***.***> 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
<#97 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABDAWSQICBNZSGGAD6ITATLS23TTZANCNFSM4WKVMDYA>
.
|
|
Oh, you don't have a working Lisp. I used "apt-get install sbcl". I build it and here's a tarball. |
|
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
<https://github.com/larsbrinkhoff/lbForth/files/5844306/lbForth-arm.zip>
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#97 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABDAWSTWPOJOAFJZ24DSBGLS24J73ANCNFSM4WKVMDYA>
.
|
|
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. |
|
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 ***@***.***> 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
<#97 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABDAWSXKCKU3IWORNOL63VDS24U4BANCNFSM4WKVMDYA>
.
|
|
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 ***@***.***> 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 ***@***.***>
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
> <#97 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/ABDAWSXKCKU3IWORNOL63VDS24U4BANCNFSM4WKVMDYA>
> .
>
|
|
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 ***@***.***> 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 ***@***.***> 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 ***@***.***>
> 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
>> <#97 (comment)>,
>> or unsubscribe
>> <https://github.com/notifications/unsubscribe-auth/ABDAWSXKCKU3IWORNOL63VDS24U4BANCNFSM4WKVMDYA>
>> .
>>
>
|
|
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? |
|
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 ***@***.***> 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
<#97 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABDAWSTIDFDBZDFNZF4XN4TS27EVDANCNFSM4WKVMDYA>
.
|
|
It should look something like this: And then the last part would be the machine code around the failure point. |
|
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 ***@***.***> 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
<#97 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABDAWSSNNHJS36YXNKC3P3LS27UEBANCNFSM4WKVMDYA>
.
|
|
Oops, sorry! Please use `disassemble $pc-16, $pc+32` instead.
|
|
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: ; <UNDEFINED> instruction: 0xffffffe0
0x0805c3b0: ; <UNDEFINED> instruction: 0xffffffa0
0x0805c3b4: ; <UNDEFINED> instruction: 0xffffff9f
0x0805c3b8: ; <UNDEFINED> instruction: 0xffffff9f
0x0805c3bc: ; <UNDEFINED> instruction: 0xffffff3e
0x0805c3c0: ; <UNDEFINED> instruction: 0xffffffff
0x0805c3c4: andeq r0, r0, r1
0x0805c3c8: ; <UNDEFINED> 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: ; <UNDEFINED> instruction: 0xffffffe0
0x0805c3b0: ; <UNDEFINED> instruction: 0xffffffa0
0x0805c3b4: ; <UNDEFINED> instruction: 0xffffff9f
0x0805c3b8: ; <UNDEFINED> instruction: 0xffffff9f
0x0805c3bc: ; <UNDEFINED> instruction: 0xffffff3e
0x0805c3c0: ; <UNDEFINED> instruction: 0xffffffff
0x0805c3c4: andeq r0, r0, r1
0x0805c3c8: ; <UNDEFINED> instruction: 0xffffffff
0x0805c3cc: ; <UNDEFINED> instruction: 0xffffff88
0x0805c3d0: ; <UNDEFINED> instruction: 0xffffffe0
0x0805c3d4: ; <UNDEFINED> instruction: 0xffffffc0
0x0805c3d8: ; <UNDEFINED> instruction: 0xffffffff
0x0805c3dc: andeq r0, r0, r1
0x0805c3e0: andeq r0, r0, r1
0x0805c3e4: ; <UNDEFINED> instruction: 0xffffffff
0x0805c3e8: andeq r0, r0, r8
End of assembler dump.
(g
…On Thu, Jan 21, 2021 at 10:00 AM Lars Brinkhoff ***@***.***> 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
<#97 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABDAWSQLHALZ7JVWU5OFSU3S3A6P5ANCNFSM4WKVMDYA>
.
|
|
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.
|
|
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: ; <UNDEFINED> instruction: 0xffffffe0
0x0805c3b0: ; <UNDEFINED> instruction: 0xffffffa0
0x0805c3b4: ; <UNDEFINED> instruction: 0xffffff9f
0x0805c3b8: ; <UNDEFINED> instruction: 0xffffff9f
0x0805c3bc: ; <UNDEFINED> instruction: 0xffffff3e
0x0805c3c0: ; <UNDEFINED> instruction: 0xffffffff
0x0805c3c4: andeq r0, r0, r1
0x0805c3c8: ; <UNDEFINED> 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 ***@***.***> 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
<#97 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABDAWSRGI5B4XMVY45BQHRTS3CI65ANCNFSM4WKVMDYA>
.
|
|
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 ***@***.***> 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: ; <UNDEFINED> instruction: 0xffffffe0
0x0805c3b0: ; <UNDEFINED> instruction: 0xffffffa0
0x0805c3b4: ; <UNDEFINED> instruction: 0xffffff9f
0x0805c3b8: ; <UNDEFINED> instruction: 0xffffff9f
0x0805c3bc: ; <UNDEFINED> instruction: 0xffffff3e
0x0805c3c0: ; <UNDEFINED> instruction: 0xffffffff
0x0805c3c4: andeq r0, r0, r1
0x0805c3c8: ; <UNDEFINED> 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 ***@***.***>
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
> <#97 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/ABDAWSRGI5B4XMVY45BQHRTS3CI65ANCNFSM4WKVMDYA>
> .
>
|
|
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 ***@***.***> 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 ***@***.***> 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: ; <UNDEFINED> instruction: 0xffffffe0
> 0x0805c3b0: ; <UNDEFINED> instruction: 0xffffffa0
> 0x0805c3b4: ; <UNDEFINED> instruction: 0xffffff9f
> 0x0805c3b8: ; <UNDEFINED> instruction: 0xffffff9f
> 0x0805c3bc: ; <UNDEFINED> instruction: 0xffffff3e
> 0x0805c3c0: ; <UNDEFINED> instruction: 0xffffffff
> 0x0805c3c4: andeq r0, r0, r1
> 0x0805c3c8: ; <UNDEFINED> 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 ***@***.***>
> 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
>> <#97 (comment)>,
>> or unsubscribe
>> <https://github.com/notifications/unsubscribe-auth/ABDAWSRGI5B4XMVY45BQHRTS3CI65ANCNFSM4WKVMDYA>
>> .
>>
>
|
I don't think so.
You could remove it and replace all instances of
Try something like this in targets/arm/nucleus.fth: |
|
Hi,
Thanks for your reply.
<quote>
Try something like this in targets/arm/nucleus.fth:
code bkpt
bkpt,
next,
end-code
</quote>
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 ***@***.***> 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 <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
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#97 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABDAWSQ7ADZTGGDV72AMJXTS3EOBDANCNFSM4WKVMDYA>
.
|
|
Hi,
> 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.
: 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 ***@***.***> 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 <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
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#97 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABDAWSQ7ADZTGGDV72AMJXTS3EOBDANCNFSM4WKVMDYA>
.
|
|
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 ***@***.***> wrote:
Hi,
>> 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.
: 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 ***@***.***>
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 <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
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> <#97 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/ABDAWSQ7ADZTGGDV72AMJXTS3EOBDANCNFSM4WKVMDYA>
> .
>
|
|
Sorry, it should be I get this: |
|
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 ***@***.***> 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
<#97 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABDAWSTLQKDB2VG63QV7GY3S3MZDXANCNFSM4WKVMDYA>
.
|
|
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. |
|
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 ***@***.***> 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
<#97 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABDAWSVCKJHWW7Y7CAL6PY3S3O4EFANCNFSM4WKVMDYA>
.
|
|
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 ***@***.***> 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 ***@***.***>
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
> <#97 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/ABDAWSVCKJHWW7Y7CAL6PY3S3O4EFANCNFSM4WKVMDYA>
> .
>
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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
The text was updated successfully, but these errors were encountered: