Closed Bug 850068 Opened 12 years ago Closed 11 years ago

[jsdbg2] IonMonkey: Allow the Debugger to read bindings from Ion frames.

Categories

(Core :: JavaScript Engine, defect)

defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 716647

People

(Reporter: nbp, Unassigned)

References

Details

We want to be able to enable the debugger without having everything setup for the Debugger ahead of time. One of the issue is that IonMonkey does not support any introspection of the bindings of the JSScript. This bug address the first part for making this possible as non-efficient read-only solution which would be re-usable for making a writable solution later. The only thing in IonMonkey capable of converting IonMonkey stack representation to an Interpreter frame are the Snapshots, which are used for bailouts. All OSI (On Stack Invalidation) points are made in such a way that they can be patched with a bailout. Every fallible call generated by IonMonkey must flow into an OSI point. A call-site cannot directly use a Snapshot as a Snapshot only describes the state in-between instructions. We have to add a way to use the OSI point snapshot from the return address location. For that we have 2 potential solutions: 1/ Add a structure indexed by the safepoint offset, which records for each call the modification until the end of the CodeGenerator produced for one instruction. Doing so implies being able to append them to each others to handle branches / OOL / ICs. 2/ Add restricted arch-assembly interpreter to account for every move / pop / load (from the stack) until the OSI point is reached. With both solutions, we are looking at producing a MachineState object reading and recovering any data indexed by a Snapshot without wrong register interpretation. /!\ This will recover the state *after* the call, which means that the value returned by the call will have to be manipulated carefully. /!\ Not all variables can be recovered this way, one example is when a variable is not observed, and it is optimized-out by IonMonkey compilation phases where the value is replaced by an Undefined constant instead of a magic value for encoding optimized-out variables. (*) IonMonkey stores Safepoints which are linked to locations, but safepoints are not linked in any way to the interpreter frames. Safepoints are only typed-indexes of locations of GC Cells.
Closing as it's now folded as a part of bug 716647.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.