This adds a new per-compartment implementation of breakpoints and
reimplements the jsdbgapi.h "trap" entry points on top of it. Most
jsdbgapi.h-using code will still work, but there is no longer a single
runtime-wide trapList protected by a lock. Embeddings must follow the
compartment rules for thread safety.
JS_ClearAllTraps was removed, replaced by the per-compartment API
JS_ClearAllTrapsForCompartment.
The new implementation asserts that the PC passed to JS_SetTrap is
actually an offset of an instruction, not just a random number. This
caused quite a few tests to fail; fixes are included.
Added Debug.Script.prototype.setBreakpoint, getBreakpoints,
clearBreakpoint, and clearAllBreakpoints; and
Debug.prototype.clearAllBreakpoints.
In addition to tests targeting the new functionality, this changeset
includes some tests for Debug.Script.prototype.getLineOffsets, which is
hard to test without breakpoints.
This allows most of the tests to run without the -d command-line flag.
Now a compartment is in debug mode if
* JSD1 wants debug mode on, thanks to a JS_SetDebugMode* call; OR
* JSD2 wants debug mode on, because a live Debug object has a debuggee
global in that compartment.
Since this patch only adds the second half of the rule, JSD1 should be
unaffected.
The new rule has three issues:
1. When removeDebuggee is called, it can cause debug mode to be turned
off for a compartment. If any scripts from that compartment are on
the stack, and the methodjit is enabled, returning to those stack
frames will crash.
2. When a Debug object is GC'd, it can cause debug mode to be turned off
for one or more compartments. This causes the same problem with
returning to deleted methodjit code, but the fix is different: such
Debug objects simply should not be GC'd.
3. Setting .enabled to false still does not turn off debug mode
anywhere, so it does not reduce overhead as much as it should.
A possible fix for issue #1 would be to make such removeDebuggee calls
throw; a different possibility is to turn off debug mode but leave all
the scripts alone, accepting the performance loss (as we do for JSD1 in
JSCompartment::setDebugModeFromC). The fix to issues #2 and #3 is to
tweak the rule--and to tweak the rule for Debug object GC-reachability.
--HG--
rename : js/src/jit-test/tests/debug/Debug-ctor.js => js/src/jit-test/tests/debug/Debug-ctor-01.js
This allows most of the tests to run without the -d command-line flag.
Now a compartment is in debug mode if
* JSD1 wants debug mode on, thanks to a JS_SetDebugMode* call; OR
* JSD2 wants debug mode on, because a live Debug object has a debuggee
global in that compartment.
Since this patch only adds the second half of the rule, JSD1 should be
unaffected.
The new rule has three issues:
1. When removeDebuggee is called, it can cause debug mode to be turned
off for a compartment. If any scripts from that compartment are on
the stack, and the methodjit is enabled, returning to those stack
frames will crash.
2. When a Debug object is GC'd, it can cause debug mode to be turned off
for one or more compartments. This causes the same problem with
returning to deleted methodjit code, but the fix is different: such
Debug objects simply should not be GC'd.
3. Setting .enabled to false still does not turn off debug mode
anywhere, so it does not reduce overhead as much as it should.
A possible fix for issue #1 would be to make such removeDebuggee calls
throw. The fix to issues #2 and #3 is to tweak the rule--and to tweak
the rule for Debug object GC-reachability.
--HG--
rename : js/src/jit-test/tests/debug/Debug-ctor.js => js/src/jit-test/tests/debug/Debug-ctor-01.js
