Open Bug 1920594 Opened 11 months ago Updated 4 months ago

Broken frame pointer unwinding in wasm "builtin thunks" on aarch64

Categories

(Core :: JavaScript: WebAssembly, defect, P2)

defect

Tracking

()

People

(Reporter: mstange, Unassigned)

References

Details

When profiling WebAssembly workloads in Spidermonkey with a native profiler such as samply, some stacks are broken.

For better stacks, the frame pointer register (x29 on aarch64) should always point to a valid frame record, i.e. a valid pair of "caller frame pointer" + "return address".

x29 is the frame pointer register, x30 is the return address register (lr).

Here's the generated code from a wasm builtin thunk on aarch64:

sub sp, sp, #0x10
str x30, [sp, #0x8]
str x29, [sp]
mov x29, sp
ldr x30, [x23, #0x20]
ldr x30, [x30, #0xf8]
mov w16, #0xa5
str w16, [x30, #0x78]
orr x29, x29, #0x1
str x29, [x30, #0x70]
and x29, x29, #0xfffffffffffffffe
mov x28, sp
mov x16, #0xf0b4
movk x16, #0x36b, lsl #16
movk x16, #0x1, lsl #32
blr x16
ldr x30, [x23, #0x20]
ldr x30, [x30, #0xf8]
mov x16, #0x0
str x16, [x30, #0x70]
mov w16, #0x0
str w16, [x30, #0x78]
ldr x30, [sp, #0x8]
ldr x29, [sp]
add sp, sp, #0x10
mov x28, sp
ret

The unwinding failures happen in the two instructions immediately following the orr x29, x29, #0x1 instruction:

str x29, [x30, #0x70]                ; 1602 broken samples out of ~200000
and x29, x29, #0xfffffffffffffffe    ; 62 broken samples out of ~200000

These instructions appear to be generated by wasm::SetExitFP.

Blocks: wasm
Severity: -- → S3
Priority: -- → P2
You need to log in before you can comment on or make changes to this bug.