Reports error on thumbv6m

[andrewdavidmackenzie]

I have been building my UF2 files for Pico/Pico2 using:

elf2uf2-rs target/thumbv6m-none-eabi/release/porky target/thumbv6m-none-eabi/release/porky_pico_w.uf2
Error: "Unrecognized ABI"

this just started failing in CI (GH Actions) recently.

I updated rust (via rustup) my machine and now it fails there with the same info.

Is anyone else seeing this error on this target, and any idea how to fix it?

[andrewdavidmackenzie]

I have two local machines (both mac M2/M3), with same version of rustc and same version of elf2uf2-rs installed, with one working and the other not.

Here is an example of a build failing in GH Actions (ubuntu):
https://github.com/andrewdavidmackenzie/pigg/actions/runs/15519389151/job/43690581699?pr=1011

I hessitate to touch the one that's working (rustup update) or similar in an attempt to understand what's the difference.

Any suggestions to help debug?

[andrewdavidmackenzie]

Any thoughts anyone?

[robjwells]

The source of the error seems to be when checking the elf header:

elf2uf2-rs/src/elf.rs

Lines 73 to 75 in 3d031e6

	if eh.common.abi != 0 {
	return Err("Unrecognized ABI".into());
	}

Perhaps you could compare the output of readelf -h for the two files?

This is what I get for an elf file created by Rust 1.86 for the same thumbv6-none-eabi architecture (an Embassy project targeting a Pico):

ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           ARM
  Version:                           0x1
  Entry point address:               0x100001c1
  Start of program headers:          52 (bytes into file)
  Start of section headers:          6484060 (bytes into file)
  Flags:                             0x5000200, Version5 EABI, soft-float ABI
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         7
  Size of section headers:           40 (bytes)
  Number of section headers:         25
  Section header string table index: 23

[andrewdavidmackenzie]

Don't have readelf on macos, objdump is suggested as a replacement.

The failing one:

objdump -p target/thumbv6m-none-eabi/release/porky 

target/thumbv6m-none-eabi/release/porky:        file format elf32-littlearm

Program Header:
    LOAD off    0x00000134 vaddr 0x10000100 paddr 0x10000100 align 2**2
         filesz 0x000000c0 memsz 0x000000c0 flags r--
    LOAD off    0x000001f4 vaddr 0x100001c0 paddr 0x100001c0 align 2**2
         filesz 0x00033c58 memsz 0x00033c58 flags r-x
    LOAD off    0x00033e50 vaddr 0x10033e18 paddr 0x10033e18 align 2**3
         filesz 0x00040cb4 memsz 0x00040cb4 flags r--
    LOAD off    0x00074b04 vaddr 0x20000000 paddr 0x10074acc align 2**2
         filesz 0x00000180 memsz 0x00000180 flags rwx
    LOAD off    0x00074ca0 vaddr 0x20000180 paddr 0x20000180 align 2**3
         filesz 0x00000000 memsz 0x000193bc flags rw-
    LOAD off    0x00074ca0 vaddr 0x10000000 paddr 0x10000000 align 2**0
         filesz 0x00000100 memsz 0x00000100 flags r--
   STACK off    0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**64
         filesz 0x00000000 memsz 0x00000000 flags rw-

Dynamic Section:

The one that works (other mac):

objdump -p target/thumbv8m.main-none-eabihf/release/porky    

target/thumbv8m.main-none-eabihf/release/porky: file format elf32-littlearm

Program Header:
    LOAD off    0x00000134 vaddr 0x10000000 paddr 0x10000000 align 2**2
         filesz 0x00000128 memsz 0x00000128 flags r--
    LOAD off    0x0000025c vaddr 0x10000128 paddr 0x10000128 align 2**2
         filesz 0x0001153c memsz 0x0001153c flags r-x
    LOAD off    0x00011798 vaddr 0x10011664 paddr 0x10011664 align 2**2
         filesz 0x00002ed0 memsz 0x00002ed0 flags r--
    LOAD off    0x00014668 vaddr 0x20000000 paddr 0x10014534 align 2**2
         filesz 0x000000ec memsz 0x000000ec flags rwx
    LOAD off    0x00014760 vaddr 0x200000f0 paddr 0x200000f0 align 2**3
         filesz 0x00000000 memsz 0x0001502c flags rw-
   STACK off    0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**64
         filesz 0x00000000 memsz 0x00000000 flags rw-

Dynamic Section:

Not very useful, maybe need a different elf inspection command or options to reveal the differences, on macos?

[robjwells]

I built porky (make build) and ran readelf -h against it (I couldn't find a program with similar output; I'm also on macOS so it's handy to have a Raspberry Pi for this!). Here's the truncated output. Note the "OS/ABI" has changed from "UNIX - System V" to "UNIX - GNU".

ELF Header:
  Magic:   7f 45 4c 46 01 01 01 03 00 00 00 00 00 00 00 00
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - GNU

I wondered if it was due to the difference (as shown in your comment) of the thumbv6m target vs the thumbv8m target, but I got the same error after building the latter (make build2).

I noticed that you were using the nightly compiler, and saw the comment in your rust-toolchain.toml file about waiting for 1.85. Switching the toolchain to 1.85 produces binaries that work with elf2uf2-rs.

TL;DR it appears something has changed in a nightly release that emits ELF output in a format that elf2uf2-rs does not expect (and so it bails).

I imagine if you run rustc --version on your two machines, they'll have different nightly versions, and you'll be able to find the change in between those two releases.

[andrewdavidmackenzie]

I decided to debug elf2uf2 to see, this is what the failing head shows:

eh.common.abi is 3, so it barfs

[andrewdavidmackenzie]

I think the need for nightly came from embassy-rs.
Removing that and going with stable (1.87) seems to fix it!
That's a much nicer fix!

Thanks

WDYT, should I report something to rust-lang?

[robjwells]

Great, glad you could get your builds working again!

I don't know enough (anything) about the ELF format itself, so I'm not sure it is actually a problem in the emitted binary, or just that elf2uf2-rs is being overly strict in its check (understandable if that field was always 0 before!).

Notably, the uf2 conversion in the official picotool works fine with the ELF files that the nightly compiler emitted.