use a frame pointer walk in MozStackWalk for non-Windows
Categories
(Core :: JavaScript Engine: JIT, enhancement, P3)
Tracking
()
People
(Reporter: luke, Unassigned)
References
Details
Once we've done bug 1426134 and bug 1530552, the remaining uses of JS::ProfilingFrameIterator could potentially be replaced by a plain frame pointer stack walk (i.e., just following the linked list of (return-pc, caller-fp) pairs on the stack).
njn has a list of what stack-walking methods are used where in this post:
https://www.mail-archive.com/dev-platform@lists.mozilla.org/msg22925.html
We currently use DWARF and EHABI on Linux and Android but I think, like OSX, we could just --enable-frame-pointer in profiling builds and thus use FramePointerStackWalk everywhere.
We'd still need sufficient metadata to:
- map return-pc to some stack string
- start unwinding when the pc is in JIT code
but I expect this could all be simpler than it is now.
Reporter | ||
Comment 1•5 years ago
|
||
Oops, I didn't really finish that thought. Also, the goal isn't just to kill JS::ProfilingFrameIterator but, rather:
If we can do the above to make MozStackWalk() Just Work for non-Win64 (the way bug 1530552 would make RtlVirtualUnwind(), and thus MozStackWalk(), Just Work for Win64), then we'd get the same Breakpad/Profiler benefits listed in bug 1530552 comment 0 for non-Win64.
Unfortunately, gdb/lldb/perf don't ride along for free (as MSVC's debugger and Xperf do on Windows, via RtlVirtualUnwind()), but once we've done all the rest, these too could be supported by registering with runtime DWARF and libunwind.
Comment 2•5 years ago
|
||
Setting P3 as bug 1426134 is a P3 and a large piece of work.
Updated•2 years ago
|
Description
•