- Updated conditional compilation flags throughout the runtime codebase to transition from DART_DYNAMIC_MODULES to DART_BYTECODE_INTERPRETER.
- Adjusted logic in various files including object_graph_copy.cc, object_reload.cc, profiler.cc, and others to ensure compatibility with the new interpreter model.
- Ensured that all references to dynamic modules are replaced with bytecode interpreter checks, maintaining functionality for interpreted code execution.
- Modified stack frame handling and service-related code to align with the new interpreter architecture.
- Updated tests and service implementations to reflect the changes in the runtime environment.
Signed-off-by: Tony <tonylu@tony-cloud.com>
Previously, the debugger used a boolean "skip next step" field that was
set when a breakpoint was hit. In compiled code, not skipping the next
step would cause a redundant pause to be emitted after a breakpoint, and
so that field caused the next run of PauseStepping to reset it to false
and then continue single stepping without the redundant pause.
However, skipping only the next call to PauseStepping isn't enough
when debugging bytecode. For bytecode, single stepping is performed on
each bytecode instruction and so there may be multiple instructions after a breakpoint until a new token position is reached.
Instead, remove the field and generalize the case being avoided by
recording the token position that should be ignored and single
stepping until the token position changes. This is done by recording
a real last_stepping_pos_ with a last_stepping_fp_ of 0, which now
means to skip any possible pauses until the token position changes.
Doing this means that in each case where there are possible skips to
be performed (skipping the same fp/pos after a pause, skipping the
pos after a breakpoint, skipping the await fp/pos after a resumption),
all such skips are handled via a single unified mechanism.
This CL also reworks the kStepOut behavior so that it steps into
the awaiter closest to the highest debuggable frame on the stack if
there is one, not just the first awaiter even if there are no
debuggable frames between that awaiter and the next.
TEST=pkg/vm_service/test/vm_timeline_flags
Cq-Include-Trybots: luci.dart.try:vm-dyn-linux-debug-x64-try,vm-dyn-mac-debug-arm64-try
Change-Id: Ic897d7bea382589751777f4db39aa58bf9525604
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/474340
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Tess Strickland <sstrickl@google.com>
Improves the readability of the tracing output by adding beginning and
ending markers for debugger stacktrace collection and using specific
spacing instead of \t in output, so that output is more naturally nested
via indention:
* beginning/ending markers are not indented,
* frames are indented by two spaces, and
* additional output while collecting a frame is indented by four spaces.
Adds tracing for DebuggerStackTrace::CollectAsyncAwaiters(). A different
ending marker is used in the case when the collected trace is discarded
due to a lack of async awaiters.
ActivationFrame::GetSavedCurrentContext now takes an optional out
parameter for the current context variable index, which is only used by
CollectDartFrame and used to print the index there. This eliminates
extra output when this method is used outside collecting stack traces.
When the current context variable index is requested,
GetSavedCurrentContext ignores the cached context if any so that the
index is appropriately set if an appropriate variable is found.
By default, skips tracing of non-collected frames and repeated async
suspensions in async awaiter traces. Use the new
--trace-debugger-stacktrace-verbose flag to add tracing for these cases.
TEST=ci (tested manually, only affects debugging output)
Change-Id: I2978d540f41b444251a61b62a57b6785a3dd8df0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/467300
Auto-Submit: Tess Strickland <sstrickl@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
The end PC offset for the scope is inclusive, not exclusive.
Also rename PrintDescriptorsError -> PrintContextLevelError and
print the Bytecode local variable information since that is what
is searched for the context level for interpreted frames.
TEST=pkg/vm_service/test/step_through_closure
pkg/vm_service/test/step_through_function_expression
Cq-Include-Trybots: luci.dart.try:vm-dyn-linux-debug-x64-try,vm-aot-dyn-linux-debug-x64-try,vm-aot-dyn-linux-product-x64-try,vm-dyn-mac-debug-arm64-try
Change-Id: Ib53d0a7cff81de16c957b73ce9ec7dcb0e4aaa34
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/449740
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Tess Strickland <sstrickl@google.com>
Adds a set of new VMInternal_Breakpoint instructions, one for each
possible instruction size, and adds a bytecode_ and saved_opcode_
field to code breakpoints.
When enabling a breakpoint, the original opcode of the instruction is
replaced with the same-sized VmInternal_Breakpoint opcode and stored in
the saved_opcode_ field of the CodeBreakpoint. When disabling it, the
original opcode is replaced.
New labels are added to the dispatch loop for single stepping
purposes. Both the computed goto and switch dispatch versions
of the dispatch loop are appropriately altered to dispatch to
the single stepping labels instead of the original ones if single
stepping is currently enabled.
Fix up more parts of the debugger that assumed functions had Code
objects to handle functions with Bytecode objects as well. In
particular, instead of using the PcDescriptors to find safepoint
source locations in Bytecode objects, the source positions information
is used instead (since the PcDescriptors for Bytecode objects only
stores information about the start and end of try blocks at the moment).
Todo (from looking at the remaining failing tests):
* Handle async jumps.
* Handle coverage information.
TEST=now-passing tests from pkg/vm_service like
pkg/vm_service/test/break_on_function_test
Change-Id: Icbd4b818e00508d9a4e74c81520aad2363b26d41
Cq-Include-Trybots: luci.dart.try:vm-dyn-linux-debug-x64-try,vm-aot-dyn-linux-debug-x64-try,vm-aot-dyn-linux-product-x64-try,vm-dyn-mac-debug-arm64-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/444880
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Tess Strickland <sstrickl@google.com>
Also, support reading local variables information from bytecode.
TEST=pkg/vm_service
Change-Id: Iab482316891f0e474af0011e9b1765c4e8312bc9
Cq-Include-Trybots: luci.dart.try:vm-aot-dyn-linux-debug-x64-try,vm-aot-dyn-linux-product-x64-try,vm-dyn-linux-debug-x64-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/437281
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
In this CL, Debugger::FindCompiledFunctions always just returns
Error::null(), but when eager compilation of functions is implemented
(https://dart-review.googlesource.com/c/sdk/+/338740), it will introduce
the possibility of Debugger::FindCompiledFunctions truly returning
errors. So, this CL adds the error propagation logic in advance to
avoid making the eager function compilation CL too large.
TEST=this is effectively just a refactor, so CI
Change-Id: Ibedbebf19fed306c8b93c98ba71b7cc57b90e174
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/369161
Reviewed-by: Alexander Aprelev <aam@google.com>
It is dead code. Breakpoint requests that only have a line number are just handled by passing column_number=-1 to SetBreakpointAtLineCol.
TEST=CI
Change-Id: I44fb9f805c364edb074bf9cdbd3fcbe3888b3bff
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/369160
Reviewed-by: Alexander Aprelev <aam@google.com>
compiled prior to the latest reload
TEST=verified that
pkg/vm_service/test/breakpoint_resolution_after_reloading_test.dart
fails without the changes in this CL and passes with them, verified that
none of the existing debugger tests got broken by this CL
Change-Id: Ie816a3ad65a17ef9f497f209f2203d679728cb75
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/366860
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Derek Xu <derekx@google.com>
When uploading CLs, the presubmit checks verify that the lines in the
diff are formatted correctly according to `git cl format runtime`.
However, when `buildtools/<os>-<arch>/clang/bin/clang-format` is
updated, it does not force reformatting of files that would be
reformatted.
This leads to two issues:
* Inconsistent style within the code base and within a single file.
* Spurious reformatting in CLs when (1) clang-format is used on the
whole file, or (2) the diff lines overlap.
`clang-format` doesn't change that frequently, so in general this is
not a large issue, but I've seen a bit too many "spurious formatting,
please revert" comments on CLs recently.
This CL formats the runtime to be in line with the current pinned
`clang-format`:
```
$ find runtime/ -iname *.h -o -iname *.cc | xargs buildtools/mac-arm64/clang/bin/clang-format -i
```
`git cl format` (which only formats changed lines, and does so with
`clang-format`) seems to not agree with itself, or clang-format, or
cpplint in a handful of places. This CL adds `// clang-format off`
for these. (See previous patchsets for the specific instances.)
TEST=A variety of bots including GCC, MacOS and Windows.
Change-Id: I470892e898971899fda14bb3b8f2c8efefd67686
Cq-Include-Trybots: luci.dart.try:vm-gcc-linux-try,vm-ffi-qemu-linux-release-riscv64-try,vm-ffi-qemu-linux-release-arm-try,vm-aot-win-debug-x64-try,vm-win-debug-x64c-try,vm-mac-debug-x64-try,vm-mac-debug-arm64-try,vm-aot-linux-debug-x64-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/362780
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Daco Harkes <dacoharkes@google.com>
Our async unwinding code used to only respect `catchError`
which occured between async frames and ignored trailing
`catchError` like in the code below
Future(...).catchError((_) { /* handle error */ });
This CL also simplifies how we communicate the presence of the
exception handler to the debugger: the code in the debugger did
not actually care about which frame catches the error (for async
handlers), so we don't need to precisely mark async gaps with
`has_catch_error` flag. Instead we have a single boolean
produced by unwinding which signals whether there we encountered
an asynchronous error handler or not.
Fixes https://github.com/flutter/flutter/issues/141882
TEST=service/pause_on_unhandled_async_exceptions5
Change-Id: Id6f6a97ee5444c197b2c621f68d1e47082fc8997
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/350320
Commit-Queue: Slava Egorov <vegorov@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Acquire reload opreation scope when deoptimizing the world to ensure locks can be acquired for compilation.
Set up scope for operations that can be run while the world is deoptimized and stopped to avoid races.
Ensure code stays unoptizimed when single stepping, prevent other isolates to reoptimize it.
TEST=DeoptimizeFramesWhenSettingBreakpoint
BUG=https://github.com/flutter/flutter/issues/140878
Change-Id: Id4c891bd585d42365fd3a60cfb9a4869892c2b03
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/345743
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Alexander Aprelev <aam@google.com>
RwLock, rather that SafepointRwLock, is okay to use for these two breakpoint_locations and single_stepping_set locks because they are short-lived, should not spawn over the safepoint.
TEST=ci
Change-Id: Iba83291978ba7980d0c6fd0a0a2cf2174c801359
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/323202
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Alexander Aprelev <aam@google.com>
The main contribution of this CL is unification of disparate
handling of various functions like `Future.timeout`,
`Future.wait`, `_SuspendState.createAsyncCallbacks` and
`_SuspendState._createAsyncStarCallback` into a single
`@pragma('vm:awaiter-link')` which allows Dart developers
to specify where awaiter unwinder should look for the next
awaiter.
For example this allows unwinding to succeed for the code like this:
Future<int> outer(Future<int> inner) {
@pragma('vm:awaiter-link')
final completer = Completer<int>();
inner.then((v) => completer.complete(v));
return completer.future;
}
This refactoring also ensures that we preserve information
(including Function & Code objects) required for awaiter
unwinding across all modes (JIT, AOT and AOT with DWARF stack
traces). This guarantees users will get the same information
no matter which mode they are running in. Previously
we have been disabling awaiter_stacks tests in some AOT
modes - which led to regressions in the quality of produced
stacks.
This CL also cleans up relationship between debugger and awaiter
stack returned by StackTrace.current - which makes stack trace
displayed by debugger (used for stepping out and determinining
whether exception is caught or not) and `StackTrace.current`
consistent.
Finally we make one user visible change to the stack trace:
awaiter stack will no always include intermediate listeners
created through `Future.then`. Previously we would sometimes
include these listeners at the tail of the stack trace,
which was inconsistent.
Ultimately this means that code like this:
Future<int> inner() async {
await null; // asynchronous gap
print(StackTrace.current); // (*)
return 0;
}
Future<int> outer() async {
int process(int v) {
return v + 1;
}
return await inner().then(process);
}
void main() async {
await outer();
}
Produces stack trace like this:
inner
<asynchronous suspension>
outer.process
<asynchronous suspension>
outer
<asynchronous suspension>
main
<asynchronous suspension>
And when stepping out of `inner` execution will stop at `outer.process`
first and the next step out will bring execution to `outer` next.
Fixes https://github.com/dart-lang/sdk/issues/52797
Fixes https://github.com/dart-lang/sdk/issues/52203
Issue https://github.com/dart-lang/sdk/issues/47985
TEST=ci
Bug: b/279929839
CoreLibraryReviewExempt: CL just adds @pragma to facilitate unwinding
Cq-Include-Trybots: luci.dart.try:vm-aot-linux-product-x64-try,vm-aot-linux-debug-x64-try,vm-aot-linux-release-x64-try,vm-aot-obfuscate-linux-release-x64-try,vm-aot-dwarf-linux-product-x64-try
Change-Id: If377d5329d6a11c86effb9369dc603a7ae616fe7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/311680
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Slava Egorov <vegorov@google.com>
The name is more accurately reflects what this stack trace
contains: despite what causal implies it does *not* actually
reflect the stack which initiated the async operation. Instead
it contains the chain of listeners which will run when
the async operation completes - its awaiters.
TEST=ci
Change-Id: Ie7309c9b1c39246e0fd4c14f7b9c515bcdfbbe10
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/311384
Reviewed-by: Derek Xu <derekx@google.com>
We no longer rewrite suspendable function into closures nested
inside the original function, so the whole synthetic async breakpoint
machinery is not needed.
Refactor `Breakpoint` class to make one-shot and per-closure
separate properties of breakpoint, which allows creating
one-shot-per-closure breakpoints.
TEST=existing service tests
Change-Id: I208afe13f36efa40f5746e44867bd24684cf5f03
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/310601
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Reviewed-by: Derek Xu <derekx@google.com>
Commit-Queue: Slava Egorov <vegorov@google.com>
This field was supposed[1] to replace Stack.asyncCausalFrames but IDEs
and other service protocol users never adopted it.
The mechanism for collecting awaiterFrames and asyncCausalFrames
was originally considerably different, but we have since unified
both[2] after we switched to lazy async stack traces[3].
Today the only differences between the two are:
- asyncCausalFrames represens async gaps explicitly, while
awaiterFrames does not;
- when asynchronous function is running its synchronous part
before the first suspension awaiterFrames will still represent
the corresponding frame as an asynchronous activation, while
asyncCausalFrames will treat the same frame as regular frame.
Consequently having this field does not add any value.
This CL removes it from the response and updates all tests to
test against asyncCausalFrames.
[1]: https://codereview.chromium.org/2692803006/
[2]: https://dart-review.googlesource.com/c/sdk/+/167561
[3]: https://github.com/dart-lang/sdk/issues/37668
Tested: pkg/vm_service, service, service_2
Bug: https://github.com/dart-lang/sdk/issues/51763
Change-Id: If2b035a8840047423b8ed8ce3b5d81155e9f38d0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/301062
Commit-Queue: Slava Egorov <vegorov@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
Our compiler shouldn't depend on current isolate, since it can
run on any isolate within an IG.
Doing this change, reveals two existing dependencies on current
isolate from compiler
- resolving native symbols in unoptimized compilations
- issuing of debug events for breakpoints
For the former we'll re-enter the currently active isolate that
triggered unoptimized compilation.
=> We may want to change that embedder API to not be based on
handles and instead give embedder a simple `const char*`.
For the ladder we'll enter the isolate corresponding to the
breakpoint debug event to be issued. We are at place where
all mutators are stopped, so that does seem okish.
=> Future could remove this by making Object Id Ring per-IG
Issue https://github.com/dart-lang/sdk/issues/48523
TEST=service_2/break_on_function_many_child_isolates_test/dds
Change-Id: Id246db5972ae505e82f637ce04bb2302bed76257
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/278901
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
The new implementation is based on suspend/resume stubs and doesn't
use desugaring of async functions on kernel AST.
Previously, new implementation of async/async* was only supported in
AOT mode. This change adds all necessary bits for the JIT mode:
* Suspending variable-length frames (for unoptimized code).
* Handling of Code and pool pointers in Dart stack frames.
* OSR.
* Deoptimization.
* Hot reload.
* Debugger.
The new implementation is not enabled in JIT mode yet.
Design doc: go/compact-async-await.
TEST=ci
Issue: https://github.com/dart-lang/sdk/issues/48378
Change-Id: I477d6684bdce7cbc1edb179ae2271ff598b7dcc5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/246081
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
BreakpointLocation token_pos and end_token_pos are populated when
breakpoint is resolved and are read when vm needs to see if a
function has breakpoints.
Since the breakpoint is resolved once and token positions are
populated with real values only once using simple atomics is sufficient
to resolve data race.
Fixes https://github.com/dart-lang/sdk/issues/45877
TEST=service[_2]/break_on_function_many_child_isolates_test.dart on tsan
Change-Id: I92066d094ca3a86c80f0de648debea05ccde5e49
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/197561
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Alexander Aprelev <aam@google.com>
objects
It's possible for scripts to appear in multiple components provided by
the front end in certain situations (e.g., mixin applications in
different libraries). Previously when trying to set a breakpoint, if
multiple scripts were found matching the target URI the debugger would
give up and not set the breakpoint.
This change allows for multiple Scripts to be associated with a
BreakpointLocation.
Fixes https://github.com/flutter/flutter/issues/66832
TEST=runtime/observatory_2/tests/service_2/sdk_break_with_mixin_test.dart
Change-Id: I935721f4753675a9a2051a71cc1720e590f8d4f6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/195664
Commit-Queue: Ben Konyi <bkonyi@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
In the codebase, we have several different interfaces for instance
methods that return a hash:
- uword Hash() const;
- intptr_t Hash() const;
- uint32_t Hash() const;
- intptr_t Hashcode() const;
This CL standardizes on `uword Hash() const` and adjusts any related
functions to match.
TEST=Existing test suites, as this is an internal refactoring.
Cq-Include-Trybots: luci.dart.try:vm-kernel-precomp-linux-debug-x64-try
Change-Id: If2cbce57f3fae0f0d24031b6e324f0323c965f41
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/195067
Commit-Queue: Tess Strickland <sstrickl@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Attempts to acquire safepoint lock while in SafepointOperationScope could result
in deadlocks if somebody else was holding that lock when they were forced to a safepoint.
Clean up few places where locks were acquired in SafepointOperationScope.
Introduce StoppedMutatorsScope and GroupDebugger::RunUnderReadLockIfNeeded that acquires
a lock only if it runs outside of StoppedMutatorsScope - to prevent such deadlocks.
Also fix tsan warning about data race around message_notify_callback by making it atomic.
TEST=tsan runs of debugger CI tests
Fixes https://github.com/dart-lang/sdk/issues/45527
Fixes https://github.com/dart-lang/sdk/issues/45549
Issue https://github.com/dart-lang/sdk/issues/36097
Change-Id: Ibb53d9ce760d869e044e17075aeebf20fc0016a5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/193582
Commit-Queue: Alexander Aprelev <aam@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
Keep list of all per-isolate BreakpointLocations on isolate_group so all of them
can be traversed by isolate group when function is compiled and
GroupDebugger::NotifyCompilation() is invoked.
This also fixes data race around line_number lazy-initialization.
Issue https://github.com/dart-lang/sdk/issues/36097
TEST=existing ci test suite
Change-Id: I821b49a56cdc28da8d0c0c97e7d850995285c48a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/193380
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Alexander Aprelev <aam@google.com>
BreakpointLocation represents source code location, which can
correspond to multiple Functions(in case of some mixin method
mixed-in in several classes, for example).
BreakpointLocation is connected to a Function via CodeBreakpoint.
CodeBreakpoint represents some point in the generated Code in some
Function. BreakpointLocation connects to multiple
CodeBreakpoints - one per Function that source code location was
generated into.
This CL removes Function reference stored directly in BreakpointLocation
as it is misleading.
This CL also removes some source-code-related attributes(uri/token_pos)
stored in CodeBreakpoint. If CodeBreakpoint code needs that information
it can find it in BreakpointLocation it references.
This should help with further refactoring to support BreakpointLocation
that map to multiple scripts
TEST=ci
Change-Id: I41b82fddc5018ef7df61c9d3a3c4aee657cee528
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/192946
Commit-Queue: Alexander Aprelev <aam@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
CodeBreakpoint class tracks patching of the call targets for the purpose of routing the call to the debugger runtime.
With this CL CodeBreakpoint instance is managed by GroupDebugger, debugger class owned by IsolateGroup, and can be associated with multiple BreakpointLocation, one location per isolate that set a breakpoint at particular code location.
TEST=observatory/tests/service/break_on_function_child_isolate_test
Issue https://github.com/dart-lang/sdk/issues/36097
Change-Id: I3b3d0974a0fb9668742e5c1e2a2ce13b84b1d630
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/190732
Commit-Queue: Alexander Aprelev <aam@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Tony