Offset non-leaf-frame addresses?

[jld]

I don't know if this belongs in fix-stacks or in the code in Gecko that's printing the stacks, but getting the correct line info for non-leaf frames requires offsetting the return address to somewhere inside the preceding call instruction. Otherwise, the resolved line is for the code after the call, which might also be before it in the source due to optimizations; I'm currently having this problem with fix-stacks and a crashed Firefox debug build. Usually subtracting 1 is enough, but for ARM in Thumb mode it's necessary to subtract 2 (to clear the Thumb bit and then subtract 1).

See also bug 1642516.

[froydnj]

IIUC, this issue would be fixed in Gecko code; fix-stacks should just be performing address -> function name/file/line translation.

[mstange]

Both representations are valid IMO. In this case, the easiest solution for fix-stacks is probably to say "the input stack is pc + return addresses, fix-stacks needs to do the subtraction during symbol lookup".

[Gankra]

nb, rust-minidump exposes this distinction as "instruction" (the instruction that is currently logically executing, what you want for backtrace) vs "resume address" (where the function would resume executing, basically return address but not, because of the top frame).

https://docs.rs/minidump-processor/latest/minidump_processor/struct.StackFrame.html#structfield.instruction

https://docs.rs/minidump-processor/latest/minidump_processor/struct.StackFrame.html#structfield.resume_address

[Gankra]

you can find the code we use for this at the bottom of every platform's stackwalker file, as it's the final step of computing a frame (and then we use that result to symbolicate and unwind it): https://github.com/rust-minidump/rust-minidump/blob/9639d293172461aea19885d963c4015770fe294d/minidump-processor/src/stackwalker/arm64.rs#L514-L516