Thanks for your explanations! :)
I still don't like the debugger ever seeing this temporary state. We should
be
able to generate some sort of one-shot breakpoint in the beginning of the
function and then restart the function. When we hit the one-shot breakpoint
in
the beginning of the function we have all the scope information and can
remove
the one-shot breakpoint. I think this will be a better experience for the
user
as well. The stack will be changed and the function restarted but he will be
able to see everything as expected.
I don't like changing the scope info to deal with this artificial state (not
worried about performance, but we really shouldn't have to look at scope
info in
this state at all). We should get out of that state immediately instead and
find
a way to have the debugger break immediately on entry to the restarted
function.
http://codereview.chromium.org/2943002/diff/8001/9014
File src/liveedit.cc (right):
http://codereview.chromium.org/2943002/diff/8001/9014#newcode1329
src/liveedit.cc:1329: // If function was in some nested scope (e.g.
'with'), reset it back to
On 2010/07/15 18:51:57, Peter Rybin wrote:
On 2010/07/15 13:09:04, Mads Ager wrote:
> Why would you want to do that? That makes no sense to me. The
function is
still
> in the same context.
As I understand that pointer to context (ebp - 1) gets temporary
updated when
function enters info 'with' statement. Now that we are restarting the
frame, we
need the original context both for running and (I think) for stack
analyzer.
Ah! Sorry about that, I misread this as messing with the context of a
function. Not with the context in the frame. I understand what you are
doing now, thanks.
http://codereview.chromium.org/2943002/show
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
