[jsdbg2] Let execution engines interact with Debugger through a well-defined interface
Categories
(Core :: JavaScript Engine, task, P3)
Tracking
()
People
(Reporter: jimb, Assigned: bhackett1024)
References
(Blocks 1 open bug)
Details
SpiderMonkey's execution engines (interpreter, JITs) are responsible for reporting events of interest to the debugger (function entry and exit, steps, breakpoints, etc.), and then putting into effect whatever changes the debugger requests: forced returns, throws, termination, and so on.
Even if implementing them can take some subtlety, these are not complex requirements to understand, but this straightforward story is obscured by the present Debugger
implementation. A JIT engineer who wants to understand the requirements and effects of a given event-reporting function, say Debugger::onEnterFrame
, today finds themselves confronted with details of Debugger
s JavaScript API that are not relevant to their work: support for multiple Debugger
s targeting a single realm, each of which may or may not have an onEnterFrame
hook set at all, and each of which may be enabled or disabled anyway, and so on.
Debugger should instead have a single engine-facing header file that defines abstract base classes for observing JavaScript execution that are sufficient for Debugger
's needs. A JIT engineer should be able to read the comments in this header to get a general understanding of the Debugger's expectations, and should only need to pursue specific implementations of those classes to settle minor details.
Updated•5 years ago
|
Updated•5 years ago
|
Assignee | ||
Updated•5 years ago
|
Updated•5 years ago
|
Comment 1•5 years ago
|
||
Is this done now that we have DebugAPI.h?
Reporter | ||
Comment 2•5 years ago
|
||
I originally had grander plans for this, but in the end I think they were just more indirection, and not helpful. So I think this can be closed.
Description
•