RTEMS | HardFault in __libc_init_array due to invalid constructor pointer on ATSAMV71 (RTEMS 6.1) (#5270)
Luís Neto (@ln)
gitlab at rtems.org
Tue Jun 17 16:42:17 UTC 2025
Luís Neto created an issue: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5270
## Summary
A HardFault is consistently observed during application startup on the ATSAMV71 target when building and running the standard hello.exe sample from RTEMS 6.1. The fault occurs within the __libc_init_array function, indicating an issue with global static initialization.
## Target Hardware Details:
**Processor Architecture:** `ARM Cortex-M7`
**Chip Family/Model:** `ATSAMV711Q21`
**Board Support Package (BSP):** `atsamv` (specifically, `arm/atsamv` as used in the sb-set-builder configuration)
## Build Environment:
**OS:** Linux Ubuntu 22.04 LTS
**RTEMS Source:** Download from https://ftp.rtems.org/pub/rtems/releases/6/6.1/sources/rtems-6.1.tar.xz
**RTEMS Source Builder:** Download from https://ftp.rtems.org/pub/rtems/releases/6/6.1/sources/rtems-source-builder-6.1.tar.xz
## Steps to reproduce
### 1. Build the RTEMS Toolchain using RSB:
```
../source-builder/sb-set-builder --prefix=/home/ln/samv71/rtems/6.1 --target=rtems-arm --with-rtems-bsp=arm/atsam --with-rtems-tests=yes --with-rtems-bspopts="ATSAM_CHIP=samv71q21" 6/rtems-arm
export PATH=/home/ln/samv71/rtems/6.1/bin:"$PATH"
```
### 2. Build the RTEMS `hello.exe` Sample:
```
1. ~/samv71/src/rtems-6.1$ ./waf bspdefaults --rtems-bsp=arm/atsamv > config.ini
2. ~/samv71/src/rtems-6.1$ ./waf clean
3. ~/samv71/src/rtems-6.1$ ./waf build
4. ~/samv71/src/rtems-6.1$ ./waf install
5. ~/samv71/src/rtems-6.1$ cp build/arm/atsamv/testsuites/samples/hello.exe build/arm/atsamv/testsuites/samples/hello.elf
```
### 3. Run the `hello.exe` Application:
Flash the eval board using `MPLAB X IDE v6.25`.
## Expected Behavior:
The application should initialize successfully and print "Hello from RTEMS!" to the console.
## Actual Undesired Behavior:
The application crashes with a HardFault immediately during startup.
## Crash Analysis:
Upon inspecting the fault registers (captured from the HardFault handler), the following values were observed:
**PC:** `0xFFFFFFFE`
**LR:** `0x0040a5db`
**SP:** `0x20404f28`
**MMFSR:** `0x00000001` (IACCVIOL bit is set)
**MMFARVALID:** 0
The **PC** = `0xFFFFFFFE` combined with **IACCVIOL** = 1 indicates an Instruction Access Violation, meaning the processor attempted to fetch and execute an instruction from an invalid memory address.
Disassembly of `hello.exe` around the LR address (`0x0040a5db`) shows the context within `__libc_init_array`:
```
0040a5a0 <__libc_init_array>:
40a5a0: 4b0f ldr r3, [pc, #60] @ (40a5e0 <__libc_init_array+0x40>)
40a5a2: b570 push {r4, r5, r6, lr}
40a5a4: 4d0f ldr r5, [pc, #60] @ (40a5e4 <__libc_init_array+0x44>)
40a5a6: 42ab cmp r3, r5
40a5a8: eba3 0605 sub.w r6, r3, r5
40a5ac: d007 beq.n 40a5be <__libc_init_array+0x1e>
40a5ae: 10b6 asrs r6, r6, #2
40a5b0: 2400 movs r4, #0
40a5b2: 3401 adds r4, #1
40a5b4: f855 3b04 ldr.w r3, [r5], #4
40a5b8: 4798 blx r3
40a5ba: 42a6 cmp r6, r4
40a5bc: d8f9 bhi.n 40a5b2 <__libc_init_array+0x12>
40a5be: 4d0a ldr r5, [pc, #40] @ (40a5e8 <__libc_init_array+0x48>)
40a5c0: f002 fa66 bl 40ca90 <_init>
40a5c4: 4b09 ldr r3, [pc, #36] @ (40a5ec <__libc_init_array+0x4c>)
40a5c6: 1b5e subs r6, r3, r5
40a5c8: 42ab cmp r3, r5
40a5ca: ea4f 06a6 mov.w r6, r6, asr #2
40a5ce: d006 beq.n 40a5de <__libc_init_array+0x3e>
40a5d0: 2400 movs r4, #0
40a5d2: 3401 adds r4, #1
40a5d4: f855 3b04 ldr.w r3, [r5], #4
40a5d8: 4798 blx r3
40a5da: 42a6 cmp r6, r4
40a5dc: d8f9 bhi.n 40a5d2 <__libc_init_array+0x32>
40a5de: bd70 pop {r4, r5, r6, pc}
40a5e0: 0040ea2c .word 0x0040ea2c
40a5e4: 0040ea2c .word 0x0040ea2c
40a5e8: 0040ea2c .word 0x0040ea2c
40a5ec: 0040ea30 .word 0x0040ea30
```
At the point of crash:
The `ldr.w r3, [r5], #4` instruction at `0x40a5d4` loads a value into `r3`.
The `r5` value at crash (`0x0040ea30`) indicates that the load happened from `0x0040ea2c` (since `r5` is incremented by 4 after the load).
The `objdump -s -j .init_array hello.exe` confirms the content at `0x40ea2c`:
```
Contents of section .init_array:
40ea2c ad044000
(Which, in little-endian, means 0x004004ad).
```
Therefore, the `blx r3` instruction at `0x40a5d8` attempts to jump to `0x004004ad`.
Further `addr2line` reveals:
`addr2line -e hello.exe 0x004004ad output: crtstuff.c:?`
However, this entry contains the address `0x004004ad`, which is not a valid executable function pointer. Instead, it points to data or misaligned, non-executable bytes within the `frame_dummy` function (part of `crtstuff.c` and `libgcc`). Executing this address triggers the Instruction Access Violation.
This indicates that a corrupted or incorrect address has been placed as the initial constructor entry in the `.init_array` section during the compilation and linking of the `hello.exe` sample. This suggests a potential issue within the RTEMS 6.1 toolchain components (specifically libgcc/Newlib's) for this target.
--
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5270
You're receiving this email because of your account on gitlab.rtems.org.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/bugs/attachments/20250617/b9d56500/attachment-0001.htm>
More information about the bugs
mailing list