Skip built-in and debugger functions when DebugBreak is forced

Debugger should not stop in its own code and in code of built-in functions since it may confuse user.Debug break handler checks whether current function is a built-in or a debugger one and just resumes execution if it is.

CallCheckStackGuardState is no longer called in loop in the RegExp code as it hangs if debug break flag is not reset after calling Execution::HandleStackGuardInterrupt.

Committed: http://code.google.com/p/v8/source/detail?r=2531

[Mads Ager (chromium), 2009-07-23 07:31:30]

LGTM

[yurys, 2009-07-23 13:34:48]

Christian, please look at regexp-macro-assembler-ia32.cc changes.

[Christian Plesner Hansen, 2009-07-23 18:09:56]

Lgtm!

[Søren Thygesen Gjesse, 2009-07-27 07:33:58]

I think we need to revise this. I agree that stopping inside builtin code might
be confusing, but when just forcing execution to stop you might expect something
like that - I can also get confused when forcing a break in my C++ code too.

I actually pulled out this check in this previous changelist
http://codereview.chromium.org/115262, for two reasons:

* Running "system" JavaScript with the debug break flag active leads to slow
running code while waiting for the break in non "system" JavaScript (one
exception to this it is to try to avoid breaks in the clear mirror cache
JavaScript code called when leaving the debugger).

* If this happens while processing RegExp running in native code an infinite
loop is created as the stack guard handler for RegExp does not move execution
forward

The removal of the stack guard check in the RegExp code avoids the infinite
loop, but as far as I can see it also removes preemption while running RegExp
code which is not desirable. RegExp can run for ever and not having preemption
there breaks the whole preemption idea.

The slow execution with the debug break flag active might not be a big deal, but
it might hit us at some point. An alternative might be to try to avoid a break
inside "system" JavaScript for some time (e.g. one second) and then breaking in
the system code anyway and maybe annotating the break event with information
that is is in system code so that the front end can display some additional
information on why we have stopped in non user code.

Regarding RegExp I think that a forced break during a long running RegExp is
useful (and of cause preemption is required) so the stack guard handling should
be re-inserted into the RegExp code. Maybe an extra check in
Execution::DebugBreakHelper can check for RegExp running and breaking
immediately even if the code is considered system code.

[Søren Thygesen Gjesse, 2009-07-27 08:08:14]

I just discussed this with Christian, and of cause the stack guard check is
still present in the RegExp code - sorry about that.

I still think that we should have the ability to stop while running a RegExp and
some countermeasure for trying for to long to leave "system" JavaScript.