Stack traces are broken after compiler bump

[mkeeter]

After b35abba, Humility can no longer get stack traces:

$ humility -d hubris.core.0 tasks -sl hf
humility: attached to dump
system time = 119804
ID TASK                       GEN PRI STATE
24 hf                           0   5 recv, notif: timer
   stack unwind failed: Do not have unwind info for the given address.

This works fine on the previous commit (86d3a0a), and the relevant commit is a compiler bump, which is very suspicious!

Here's an example (zipped) dump that reproduces the issue: hubris.core.0.zip

Unclear if this is a Hubris or Humility issue, more to come!

[dancrossnyc]

Oops, I mentioned this a couple of weeks ago in chat, tangentially related to another issue, but forgot to file an issue for it. Mea culpa!

[cbiffle]

Mentioned this in chat, but -- the stack unwinding is failing for any task parked in the kernel, which means the issue is almost certainly with Humility's heuristics for starting a stack trace in a syscall stub.

Because our syscall stubs are in assembly, they don't have the DWARF info our normal functions have, and they rearrange the registers so the "r7 is frame pointer" assumption fails. Humility contains some heuristics for detangling this but they're inherently fragile... something may have changed that broke them.

In exhubris I worked out the (awful, noisy) pattern of explicit assembly annotations for adding the DWARF info to the stubs. We could try porting that over and seeing if it fixes the problem.

[dancrossnyc]

I'd like to double back with you regarding backporting some exhubris bits more generally, Cliff, if you're still game?

[cbiffle]

I'd like to double back with you regarding backporting some exhubris bits more generally, Cliff, if you're still game?

Yeah, we should set up some kind of a sync meeting on that. I'd love to make some progress there.

[cbiffle]

Alright, Humility's syscall disassembly heuristics -- while fragile! -- are not to blame here.

The issue is that our toolchain (currently nightly-2025-07-20) is not producing line number information for any naked_asm block, as far as I can tell. The syscall stubs are affected, but so is _start, and you can see this with addr2line:

[cbiffle@gwydion hubris5]$ arm-none-eabi-objdump -dC target/grapefruit-standalone/dist/default/jefe |head

target/grapefruit-standalone/dist/default/jefe:     file format elf32-littlearm


Disassembly of section .text:

08008000 <_start>:
 8008000:	f642 30b8 	movw	r0, #11192	@ 0x2bb8
 8008004:	f2c2 4000 	movt	r0, #9216	@ 0x2400
 8008008:	f24a 1188 	movw	r1, #41352	@ 0xa188
[cbiffle@gwydion hubris5]$ arm-none-eabi-addr2line -e target/grapefruit-standalone/dist/default/jefe 0x8008000
??:?

There's a bug open about in-process unwinding failing at a naked_asm block that is missing CFI directives, but I tried adding them and that doesn't cause line numbers to start being produced.

This behavior persists through at least last night's nightly. I think this may be an upstream bug.