-
yangguo authored
Previously, we would both instrument the code, and add/remove BreakPointInfo objects through BreakLocation. This is bad design and unsuitable for having two different code kinds. We would now add/remove BreakPointInfo objects, and use that as source of truth when instrumenting the code. If we have both bytecode and FCG code, we would simply apply these break points twice to either. Notable changes: - Removed many functionality from BreakLocation. - Instrumentation (patching code for breaks) happens by applying break point info onto code. - Instrumentation (code patching) is done by the BreakIterator. For bytecode, it's BytecodeArrayBreakIterator. For FCG code, it's CodeBreakIterator. - Changes to code instrumentation mostly involves clearing current instrumentation and then (re-)applying break points. - DebugInfo can now reference both bytecode and FCG code. R=jgruber@chromium.org, mstarzinger@chromium.org BUG=v8:5265 Review-Url: https://codereview.chromium.org/2238893002 Cr-Commit-Position: refs/heads/master@{#38596}
b8c05042
Name |
Last commit
|
Last update |
---|---|---|
.. | ||
OWNERS | ||
builtins-mips.cc |