masayuki2009 commented on pull request #5645:
URL: https://github.com/apache/incubator-nuttx/pull/5645#issuecomment-1059113053
@anchao
The original issue with sabre-6quad:netknsh (QEMU) still happens.
You can try the latest my branches with your patches.
Please note that gcc-arm-none-eabi-9-2020-q2-update must be used, because
I'm still not sure why the gcc-arm-none-eabi-10.3-2021.10 causes the undefined
instruction issue.
```
[ 15.740000] up_addrenv_select: addrenv=0x10843f24 oldenv=0x10847330
[ 15.740000] up_addrenv_select: text: set l1 entry (paddr=1811d000
vaddr=80000000)
[ 15.740000] up_addrenv_select: data: set l1 entry (paddr=18122000
vaddr=80100000)
[ 15.750000] up_addrenv_select: heap: set l1 entry (paddr=18124000
vaddr=80200000)
[ 15.750000] exec_module: Initialize the user heap (heapsize=1048576)
[ 15.760000] up_addrenv_kstackalloc: tcb=0x10847430 stacksize=3072
[ 15.760000] up_addrenv_clone: src=0x10843f24 dest=0x10843fc8
[ 15.760000] up_addrenv_restore: oldenv=0x10847330
[ 15.770000] up_addrenv_select: addrenv=0x10843fc8 oldenv=0
[ 15.770000] up_addrenv_select: text: set l1 entry (paddr=1811d000
vaddr=80000000)
[ 15.770000] up_addrenv_select: data: set l1 entry (paddr=18122000
vaddr=80100000)
[ 15.770000] up_addrenv_select: heap: set l1 entry (paddr=18124000
vaddr=80200000)
Set thread priority to 10
Set thread policy to SCHED_RR
Start thread #0
[ 15.780000] up_addrenv_attach: group=0x10843f80 tcb=0x10847430
[ 15.780000] up_addrenv_kstackalloc: tcb=0x108475d0 stacksize=3072
thread #0 started, looking for primes < 10000, doing 10 run(s)
[ 17.600000] arm_dataabort: Data abort. PC: 80001bb2 DFAR: 1084361c DFSR:
0000000d
[ 17.600000] up_assert: Assertion failed at file:armv7-a/arm_dataabort.c
line: 161 task: lpwork
[ 17.600000] arm_registerdump: R0: 80204698 R1: 1084360c R2: 80204698 R3:
1084360c
[ 17.600000] arm_registerdump: R4: 00000000 R5: 00000000 R6: 00000000 FP:
80204678
[ 17.600000] arm_registerdump: R8: 00000000 SB: 00000000 SL: 00000000 R11:
00000000
[ 17.600000] arm_registerdump: IP: 10807693 SP: 80204678 LR: 80001725 PC:
80001bb2
...
```
The text region of the getprime (elf) starts at 0x8000:0000,
So, the `PC: 80001bb2` means the offset is 0x1bb2.
It seems that the exception happened in lib_stdoutstream() which is linked
with getprime.
As you can see from the register dump, `R3: 1084360c` shows the address in
the kernel area.
That's why the dataabort happened.
Here, r3 is loaded from `[r7, #0]` and r7 `FP: 80204678` shows the address
is in the userland heap (i.e. user stack), so this might be correct but its
content (i.e. the variable `stream`) is corrupted.
```
void lib_stdoutstream(FAR struct lib_stdoutstream_s *outstream,
FAR FILE *stream)
{
1b9a: b480 push {r7}
1b9c: b083 sub sp, #12
1b9e: af00 add r7, sp, #0
1ba0: 6078 str r0, [r7, #4]
1ba2: 6039 str r1, [r7, #0]
/* Select the put operation */
outstream->public.put = stdoutstream_putc;
1ba4: 687a ldr r2, [r7, #4]
1ba6: f240 0300 movw r3, #0
1ba6: R_ARM_THM_MOVW_ABS_NC stdoutstream_putc
1baa: f2c0 0300 movt r3, #0
1baa: R_ARM_THM_MOVT_ABS stdoutstream_putc
1bae: 6013 str r3, [r2, #0]
* opened in binary mode. In binary mode, the newline has no special
* meaning.
*/
#ifndef CONFIG_STDIO_DISABLE_BUFFERING
if (stream->fs_bufstart != NULL && (stream->fs_oflags & O_BINARY) == 0)
1bb0: 683b ldr r3, [r7, #0]
1bb2: 691b ldr r3, [r3, #16] <== here
1bb4: 2b00 cmp r3, #0
1bb6: d00d beq.n 1bd4 <lib_stdoutstream+0x3a>
1bb8: 683b ldr r3, [r7, #0]
1bba: f8b3 3060 ldrh.w r3, [r3, #96] ; 0x60
1bbe: f403 7380 and.w r3, r3, #256 ; 0x100
1bc2: 2b00 cmp r3, #0
1bc4: d106 bne.n 1bd4 <lib_stdoutstream+0x3a>
{
outstream->public.flush = stdoutstream_flush;
1bc6: 687a ldr r2, [r7, #4]
1bc8: f240 0300 movw r3, #0
1bc8: R_ARM_THM_MOVW_ABS_NC stdoutstream_flush
1bcc: f2c0 0300 movt r3, #0
1bcc: R_ARM_THM_MOVT_ABS stdoutstream_flush
1bd0: 6093 str r3, [r2, #8]
1bd2: e005 b.n 1be0 <lib_stdoutstream+0x46>
}
else
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
