Preserve frame pointers when entering Wasm code
Categories
(Core :: JavaScript: WebAssembly, task, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox104 | --- | fixed |
People
(Reporter: jandem, Assigned: jandem)
References
Details
Attachments
(7 files)
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review |
Wasm code mostly maintains frame pointers, but the main exceptions are:
- The interpreter entry stub sets FP to
nullptr
. - Direct calls from JIT code use a tagged frame pointer.
I have some patches to fix these to preserve the caller's frame pointer. This will let native stack unwinders (profilers, crash dump analysis, etc) properly unwind through Wasm frames too.
Assignee | ||
Comment 1•2 years ago
|
||
This will let us preserve the caller's frame pointer in later patches. It's also more
consistent with what we do for the JitEntry stub.
Assignee | ||
Comment 2•2 years ago
|
||
This will let native stack unwinders (such as 'perf' or crash-stats tooling) unwind
from Wasm to C++ frames.
Depends on D151246
Assignee | ||
Comment 3•2 years ago
|
||
Treat the InterpEntry
stub more like the JitEntry
stub in ProfilingFrameIterator
.
This lets us remove the FakeInterpEntry
ExitReason
, which was a bit of a hack because
this is not an exit.
Depends on D151247
Assignee | ||
Comment 4•2 years ago
|
||
Depends on D151248
Assignee | ||
Comment 5•2 years ago
|
||
The unwoundJitCallerFP_
is only used when the iterator is done()
(to transition
to the JS JIT frame iterator after either the JitEntry
stub or a direct call).
With this patch, we only set unwoundJitCallerFP_
right before we're done iterating.
Depends on D151249
Assignee | ||
Comment 6•2 years ago
|
||
If there's no CodeRange
for a frame's return address, this must be a direct call
from JIT code.
Use AssertDirectJitCall
in a few more places to help catch issues with this.
Depends on D151250
Assignee | ||
Comment 7•2 years ago
|
||
The tag bit is now only used for the activation's exitFP
field.
Similar to part 2, this makes it easier for stack unwinders to unwind through Wasm frames.
Depends on D151251
Comment 8•2 years ago
|
||
Thanks for this, this really improves the readability of ProfilingFrameIterator.
Pushed by jdemooij@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/6bbcd6e57809 part 1 - Use CodeRange kind to check for InterpEntry stub instead of null frame pointer. r=rhunt https://hg.mozilla.org/integration/autoland/rev/63e1dd659c57 part 2 - Don't clobber FP with nullptr in GenerateInterpEntry. r=rhunt https://hg.mozilla.org/integration/autoland/rev/94b62c2e8637 part 3 - Tidy up InterpEntry handling in ProfilingFrameIterator, remove fake ExitReason. r=rhunt https://hg.mozilla.org/integration/autoland/rev/78c4287d2c3c part 4 - Simplify ProfilingFrameIterator::done. r=rhunt https://hg.mozilla.org/integration/autoland/rev/073da829bd32 part 5 - Clean up unwoundJitCallerFP_ code in ProfilingFrameIterator. r=rhunt https://hg.mozilla.org/integration/autoland/rev/7bba2760a2ea part 6 - Stop relying on tagged frame pointer for direct JIT => Wasm calls. r=rhunt https://hg.mozilla.org/integration/autoland/rev/cd86be9642b7 part 7 - Don't use a tagged frame pointer for direct JIT => Wasm calls. r=rhunt
Comment 10•2 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/6bbcd6e57809
https://hg.mozilla.org/mozilla-central/rev/63e1dd659c57
https://hg.mozilla.org/mozilla-central/rev/94b62c2e8637
https://hg.mozilla.org/mozilla-central/rev/78c4287d2c3c
https://hg.mozilla.org/mozilla-central/rev/073da829bd32
https://hg.mozilla.org/mozilla-central/rev/7bba2760a2ea
https://hg.mozilla.org/mozilla-central/rev/cd86be9642b7
Description
•