1255884 - gdb unwinder can't unwind when newest frame is in JIT code

Status: NEW

(Core :: JavaScript Engine, defect)

Description

[Tom Tromey :tromey]

The unwinder added in bug 1232712 can't unwind if the newest frame is
in JIT code.  This is because in this case there is no way to find the
frame layout object.

A few possibilities come to mind.

1. Add a frame pointer
2. Find the function's start and duplicate gdb's prologue analysis
   code (or write a simpler prologue analyzer that only works for
   the spidermonkey jits)
3. Use some heuristic to try to find the frame layout object
4. Like #3, but add some kind of distinguishing cookie to the
   frame object to make it simpler to find

Comment 1

[Nicolas B. Pierron [:nbp]]

Before I would have go with the heuristic approach, but now I think it would make sense to reuse the JitcodeMap work, which is used by the Gecko profiler too.

One thing we can do is find the location of the current JitCode:
  https://dxr.mozilla.org/mozilla-central/source/js/src/jit/JitFrames.cpp#2701,2714,2718

This is probably more complex than requesting the symbol of a function, but should give us enough information to find the beginning of a frame, and compute the stack depth, when we have no JIT frame.

Comment 2

[Tom Tromey :tromey]

Maybe the JitcodeMap approach would let us remove the /proc/../maps parsing hack as well.

Comment 3

[Tom Tromey :tromey]

:nbp pointed out https://searchfox.org/mozilla-central/rev/7adb490485eff0783071a3e132005bceeb337461/js/src/jit/ProcessExecutableMemory.cpp#617 on irc.

<nbp> tromey: a JIT code is in the range ::execMemory.base_ to
::execMemory.base_ + ProcessExecutableMemory::MaxCodePages

Comment 4

[Tom Tromey :tromey]

I suspect that using execMemory would let us remove ExecutableAllocator.py entirely.

Comment 5

[Nicolas B. Pierron [:nbp]]

(In reply to Tom Tromey :tromey from comment #4)

I suspect that using execMemory would let us remove ExecutableAllocator.py entirely.

Yes.

Comment 6

[Tom Tromey :tromey]

Attachment: initial patch

This patch implements the basic idea, but in order to finish this bug
I think we need a second patch that searches the stack for the frame
descriptor. This could be done by looking for the two words and applying
some sanity checks: whether the one word decodes sanely, and whether the
return address corresponds to something that makes sense (either a JIT
address or something known to gdb).