Line number information missing for new naked-asm implementation
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 119k
- Forks
- 16.1k
- PR merge metrics
- PR metrics pending
Description
When we upgraded the default toolchain for Hubris to the 2025-07-20 nightly, we had to go through and update our syscall stubs for the new (stable!) naked function syntax, which we did enthusiastically.
However, it looks like since that commit, stack traces that begin in naked assembly routines have been broken (https://github.com/oxidecomputer/hubris/issues/2236 if you're curious).
I dug into this today, and it appears that on recent compilers, some forms of line number information are not being generated for naked_asm!. In the attached example output binary (which was produced on nightly-2025-09-17 after bisecting didn't turn up any improvements), none of objdump, addr2line, Humility, or my DWARF analysis tools (debugdb/tysh) are able to recover a line number for any position in the _start routine:
[cbiffle@gwydion hubris5]$ arm-none-eabi-objdump -dCl /tmp/idle | head
/tmp/idle: file format elf32-littlearm
Disassembly of section .text:
080086c0 <_start>:
_start():
80086c0: f242 1000 movw r0, #8448 @ 0x2100
80086c4: f2c2 4000 movt r0, #9216 @ 0x2400
[cbiffle@gwydion hubris5]$ arm-none-eabi-addr2line -e /tmp/idle 0x080086c0
task_idle.63c1e54c3c0b5cbe-cgu.0:?
The "filename" given by addr2line looks an awful lot like some sort of tmpnam to me, leading me to wonder if the compiler might accidentally be attributing naked asm blocks to a temporary file. (Though this doesn't explain why the simpler ELF info used by objdump appears to be missing.)
On other Oxide projects we've also confirmed that this happens on the x86-none ELF target, so it isn't ARM specific.
For what it's worth, I suspect that https://github.com/rust-lang/rust/issues/144610 is not the same issue:
- when it says "unwinding" it means the program unwinding itself, whereas I'm talking about debuggers;
- the line number information is not part of the CFI annotations, and I've confirmed that CFI-annotating the assembly stubs does not cause this behavior to change.
Meta
Tested as recently as:
[cbiffle@gwydion hubris5]$ rustc --version --verbose
rustc 1.92.0-nightly (a9d0a6f15 2025-09-16)
binary: rustc
commit-hash: a9d0a6f15533a364816c4d81e2192009ef601d33
commit-date: 2025-09-16
host: x86_64-unknown-linux-gnu
release: 1.92.0-nightly
LLVM version: 21.1.1
Appears to start around nightly-2025-07-20 but it's a bit hard to bisect, since it requires changing the syntax of the input code to the new naked-asm feature.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reproducing the missing line information with the attached example output binary and the reported nightly-2025-09-17 toolchain. Compare naked_asm! output using arm-none-eabi-objdump, addr2line, and DWARF analysis tools, then check whether the behavior also occurs on x86-none. Done means debuggers can recover line numbers for positions in naked assembly routines.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- compilers
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100