1254297 - add gdb frame filter for interpreter frames

Status: NEW

(Core :: JavaScript Engine, defect)

Description

[Tom Tromey :tromey]

In addition to the frame filter included in bug 1232712, it would be good
to supply a second frame filter that recognizes interpreter frames and
extracts the JS function and file name (and perhaps line number and other
interesting things).

Comment 1

[Tom Tromey :tromey]

I have an initial patch, but it's not clear to me it is worth landing until
the line numbers are also displayable.  The patch depends on the patch in
bug 1254295.

Comment 2

[Tom Tromey :tromey]

Attachment: Bug 1254297 - initial work on JS interpreter frame filter

Review commit: https://reviewboard.mozilla.org/r/89586/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/89586/

Comment 3

[Nicolas B. Pierron [:nbp]]

(In reply to Tom Tromey :tromey from comment #1)
> I have an initial patch, but it's not clear to me it is worth landing until
> the line numbers are also displayable.

I think having the name of the function, even without the line numbers is already a good hint.

Comment 4

[Nicolas B. Pierron [:nbp]]

Comment on attachment 8806009 [details]
Bug 1254297 - initial work on JS interpreter frame filter

https://reviewboard.mozilla.org/r/89586/#review89760

::: js/src/gdb/mozilla/unwind.py:253
(Diff revision 1)
> +    def function(self):
> +        return "<<<<" + FrameDecorator.function(self) + ">>>>"

nit: I guess we would have to check in practice, but I am not completely sure yet that surrounding all names between <<<<>>>> make sense.

::: js/src/gdb/mozilla/unwind.py:308
(Diff revision 1)
> -
> -    def filter(self, frame_iter):
> -        return imap(self.maybe_wrap_frame, frame_iter)
> +            if frame.function() == "Interpret(JSContext*, js::RunState&)":
> +                for iframe in get_interpreter_frames(frame, self.cache):
> +                    yield iframe

From what I understand, if we are able to read JS frames from the activation, then we would yield all the JS frame, but not the "Interpret()" function frame.

Should we yield the original frame before entering this for loop?  (instead of only yielding the original frame when we are unable to read from the activation)

Comment 5

[Tom Tromey :tromey]

(In reply to Nicolas B. Pierron [:nbp] from comment #4)

> > +        return "<<<<" + FrameDecorator.function(self) + ">>>>"
> 
> nit: I guess we would have to check in practice, but I am not completely
> sure yet that surrounding all names between <<<<>>>> make sense.

Yeah, that makes sense to me.

> From what I understand, if we are able to read JS frames from the
> activation, then we would yield all the JS frame, but not the "Interpret()"
> function frame.
> 
> Should we yield the original frame before entering this for loop?  (instead
> of only yielding the original frame when we are unable to read from the
> activation)

The way this works in gdb is that one of these synthetic interpreter frames
carries a reference to an underlying real frame.  gdb always prints the real
frame (there's a gdb bug about letting the user disable this).  So, we don't
have to explicitly print it, it will be done for us.