Closed Bug 736733 Opened 12 years ago Closed 10 years ago

Implement Debugger.Frame.prototype.pop

Categories

(Core :: JavaScript Engine, defect)

defect
Not set
normal

Tracking

()

RESOLVED WONTFIX
mozilla32

People

(Reporter: past, Assigned: jimb)

References

Details

Attachments

(1 file)

I didn't find a bug on file for this and I wanted one to refer to in protocol code. Spec:

https://wiki.mozilla.org/Debugger#Function_Properties_of_the_Debugger.Frame_Prototype_Object
This bug blocks the implementation of issue 6857 (Give the ability to modify the returned value) in Firebug : 
http://code.google.com/p/fbug/issues/detail?id=6857

Florent
Blocks: 717749
I have two ideas on how to implement this. Both are pretty gnarly.

First, a spec proposal: any non-observed frames between the to-be-popped frame and the newest frame (different compartments, say), causes this method to throw.

Strategy 1: Meshuga frame surgery again.

That is, we *actually* pop the frames and patch the return address. This will be gnarly and a second kind of OSR in addition to the existing JIT debug mode OSR, which is obviously a lot more added maintenance burden.

General algorithm below:
 - Let frame be the caller of the frame to be popped.
 - If frame is a Baseline frame, patching the return address is easy.
 - If frame is an Ion frame, we have to:
   1. Unwind the stack so that the Ion frame is on top.
   2. Bailout to Baseline now that it's on top.
   3. Resume in baseline.
 - If frame is an Interpreter frame, we have to futz with the interpreter register file in the activation. I don't know enough about the interpreter to say if this will be hard.

Strategy 2: Record the completion value and force unwind to the to-be-popped frame's caller.

This is not any easier to implement.

1. The invariant that Debugger.Frames are synched on frame push/pop no longer holds. If we called |frame.pop()|, |frame| now has to be considered no longer observable according to the Debugger.

2. In order to unwind all the way to the to-be-popped frame's caller, Baseline and Interpreter have to somehow check for forced return now *even when debug mode is off*. This is a perf hit I don't want to have to take.

Feel free to chime in if anyone has any bright ideas.
I don't think Debugger.Frame.prototype.pop should be implemented as specified. It's kind of insane to be removing stack frames *below* the currently executing frame, which is what D.F.p.pop calls for: live-editing your own continuation.

Code using the Debugger API can get almost the same effect, at the cost of more co-ordination, by setting an onPop handler H on the frame that they want to pop to, and then returning 'null' as the resumption value from the currently running handler. H can then catch the termination and the Debugger-using code can continue with whatever it was doing.
Assignee: general → jimb
Status: NEW → ASSIGNED
Attachment #8421122 - Flags: review?(shu)
Comment on attachment 8421122 [details] [diff] [review]
Remove documentation for unneeded Debugger.Frame.prototype.pop and .replaceCall.

Review of attachment 8421122 [details] [diff] [review]:
-----------------------------------------------------------------

Alas, live editing your own continuation seemed real neato.
Attachment #8421122 - Flags: review?(shu) → review+
(In reply to Shu-yu Guo [:shu] from comment #5)
> Alas, live editing your own continuation seemed real neato.

Okay, that's completely true.
https://hg.mozilla.org/integration/mozilla-inbound/rev/a7666d470ffb
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Flags: in-testsuite-
Resolution: --- → WONTFIX
Target Milestone: --- → mozilla32
You need to log in before you can comment on or make changes to this bug.