Line number information missing for new naked-asm implementation

[cbiffle]

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 (oxidecomputer/hubris#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 #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.

[cbiffle]

...and I guess github's upload UI just silently ignores any request to attach an ELF file, so my attachment wasn't attached. Here's a ZIP file containing an ELF file. idle.zip

[workingjubilee]

I guess GitHub thinks an ELF might be a dangerous virus, dontcha know, unlike ZIP which is perfectly innocent and has never done anything wrong.

Thanks! Do you have a repro/non-repro with each syntactic form? You could use #[cfg(arbitrary)] so that a bisection can pass a cfg to switch what gets handled as it passes over that syntactic change. ( At least I think the same tokens are legal from a purely AST perspective in both versions and we decide to accept/reject after.. )

[bjorn3]

when it says "unwinding" it means the program unwinding itself, whereas I'm talking about debuggers;

The same unwind tables are used for exceptions and by debuggers. (although debuggers could also chose to use frame pointers if you compiled with them enabled) The "Do not have unwind info for the given address." error is emitted by gimli when unwind tables are missing for a file.

[folkertdev]

I wonder what you used before? For about a year (on nightly), #[naked] has desugared to effectively a foreign function declaration + a global asm block. Based on my experiments, rust does not emit line information for the desugared version either, and these have the same behavior:

#[unsafe(no_mangle)]
#[unsafe(naked)]
pub extern "C" fn add_naked(a: i32, b: i32) -> i32 {
    core::arch::naked_asm!("lea eax, [rdi + rsi]", "ret",)
}

core::arch::global_asm!(
    ".section .text.add_foreign,\"ax\",@progbits",
    "	.globl	add_foreign",
    "	.p2align	4",
    ".type	add_foreign,@function",
    "add_foreign:",
    ".Lfunc_begin0:",
    "	lea eax, [rdi + rsi]",
    "	ret",
    ".Lfunc_end0:",
    "	.size	add_foreign, . - add_foreign",
);

unsafe extern "C" {
    safe fn add_foreign(a: i32, b: i32) -> i32;
}

with

0000000000013e44 <add_naked>:
   13e44:	8d 04 37             	lea    (%rdi,%rsi,1),%eax
   13e47:	c3                   	ret

0000000000013e50 <add_foreign>:
   13e50:	8d 04 37             	lea    (%rdi,%rsi,1),%eax
   13e53:	c3                   	ret

0000000000013e60 <playground::main>:

> addr2line -e target/debug/playground 0000000000013e60
/home/folkertdev/rust/playground/src/main.rs:24
> addr2line -e target/debug/playground 0000000000013e44
bizaap437qehdk7ik8fyvrw8x:?
> addr2line -e target/debug/playground 0000000000013e50
bizaap437qehdk7ik8fyvrw8x:?

So this behavior is not unexpected, I think. Maybe we can do better, but I'm not really sure how that would work (yet).

[Amanieu]

I looked into LLVM internals and it might be possible for us to support line number information for global_asm! (and by extension naked_asm!). We essentially need to emit .file and .loc directives to tell the assembler to emit location metadata when debuginfo generation is enabled.