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