rust-lang / rust-lang/rust

Line number information missing for new naked-asm implementation

Open
#146,736 8 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

A-debuginfo A-inline-assembly A-naked C-bug E-needs-bisection F-naked_functions T-compiler
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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.