Status: Assigned
Owner: [email protected]
Labels: Type-Bug Priority-Medium
New issue 4269 by [email protected]: Debug break points should not be
implemented by patching ICs
https://code.google.com/p/v8/issues/detail?id=4269
In order to set a debug break point in a function, we have three ways:
- The code has been previously recompiled for debugging. This means that
the code contains debug break slots at expression and statement positions.
Debug break slots are a sequence of NOP instructions that can be
overwritten to call into the debugger.
- The code contains ICs that can be overwritten by debug versions of the
original ICs. The debug versions call into the debugger first, and then
return via trampoline code to the original IC that carries out the actual
work.
- Return statements (explicit and implicit ones) can be patched to jump
into the debugger first.
Up until now, we must rely on debug break ICs in situations where we cannot
recompile code for debugging, so debug break slots are simply not
available. Setting break points in such code is a bit unpredictable, since
some break locations don’t exist.
This situation has been fixed in a series of CLs. We now can guarantee that
code in which we want to set break points, have been recompiled to include
debug break slots.
Having both debug break slots and debug break ICs has several disadvantages.
- Statements may contain ICs. In order to avoid having both debug break
slots and IC for the same statement and source position, we have an
elaborate system to predict whether a debug break slot should be skipped in
favor of an IC (BreakableStatementChecker). However, this is often not
up-to-date and leads to bugs.
- Some statements are implemented as branches where one branch is
implemented by IC and the other is not (e.g. assignment to a variable that
could be context-allocated or on the global object). The algorithm looking
for break locations for a given position does not expect this and only
returns one. In this case, we may either hit no break point at all or
multiple break points with the same source position in succession (when
stepping). To work around the latter situation, the debugger ignores
multiple breaks on the same source position. That is also wrong, for
example in an empty infinite while loop (“while(true) {}”).
- We keep a copy of unpatched code around so that we can return to the
original IC after returning from the call to the debugger, and also to
restore the original IC.
- ICs need to be cleared to prepare for setting the break point.
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings
--
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
