picotool elf2uf2 fails on complex code - clang #2463

New issue

Open

opened 2025-05-12 17:13:27 -05:00 by Ivan-Voronyuk · 2 comments

Ivan-Voronyuk commented

2025-05-12 17:13:27 -05:00

(Migrated from github.com)

Actual problem

Background:

For some reason (I really don't know why) clang generates .got section in the .elf file on some scenarios even with PIE and everything related to PIE disabled. It can't be deleted with stripping the elf file. If you delete it with 'objcopy' it won't fix the problem.
The section is not used anywhere:

The file has no relocations
The address of any byte in .got section never appears in the disassembly
The section consists of 4 bytes and contains something like this (I got this with llvm-objdump -s -j .got main.elf):

Contents of section .got:
 20001298 08000000                             ....

That is probably useless.

Outcome:

picotool elf2uf2 fails with ELF contains memory contents for uninitialized memory at ... error.
The .got section must be loaded into SRAM address space. This is impossible to reproduce using UF2 file format, as I know.

How to reproduce:

That happened to me when I tried to create union of a fitfield structure and an integer. Some std:: functions also trigger this behavior.
To be precise, I currently use clang 18.1.3 (1ubuntu1) and LLVM-ET-Arm-18.1.3-Linux-x86_64 toolkit.

Workaround

Filling the section with zeros as if it is unitialized works just fine. Considering this I suggest adding an option for elf2uf2 to force assemble uf2 with sections in SRAM forcibly left uninitialized.

A better long-term solution would be to implement a runtime loader for initialized data located in SRAM. This would require significant effort and might be overkill

## Actual problem ### Background: For some reason (I really don't know why) `clang` generates `.got` section in the `.elf` file on some scenarios even with PIE and everything related to PIE disabled. It can't be deleted with stripping the elf file. If you delete it with 'objcopy' it won't fix the problem. The section is not used anywhere: 1. The file has no relocations 2. The address of any byte in `.got` section never appears in the disassembly 3. The section consists of 4 bytes and contains something like this (I got this with `llvm-objdump -s -j .got main.elf`): ``` Contents of section .got: 20001298 08000000 .... ``` That is probably useless. ### Outcome: picotool elf2uf2 fails with `ELF contains memory contents for uninitialized memory at ...` error. The `.got` section must be loaded into SRAM address space. This is impossible to reproduce using UF2 file format, as I know. ## How to reproduce: That happened to me when I tried to create union of a fitfield structure and an integer. Some std:: functions also trigger this behavior. To be precise, I currently use `clang 18.1.3 (1ubuntu1)` and `LLVM-ET-Arm-18.1.3-Linux-x86_64` toolkit. ## Workaround Filling the section with zeros as if it is unitialized works just fine. Considering this I suggest adding an option for elf2uf2 to force assemble uf2 with sections in SRAM forcibly left uninitialized. A better long-term solution would be to implement a runtime loader for initialized data located in SRAM. This would require significant effort and might be overkill

will-v-pi commented

2025-06-13 04:37:55 -05:00

(Migrated from github.com)