6f83a5ff9b
For proper crashpad integration, we need to generate a build ID, as the build ID generated by crashpad if there is not one will be a simple XOR of the first text page, which rarely changes for Dart snapshots. Assembly snapshots already have a build ID included by the assembler, so we currently only do this for ELF snapshots. Currently the build ID is a 128-bit hash value that is four separate 32-bit hash values concatenated together. Those hash values come from the contents of the VM and isolate .text and .rodata sections. This change also contains work to separate out the concepts of sections and segments in the ELF builder. Now, consecutive allocated sections with the same write and execute flags are combined into a single PT_LOAD segment when possible, which reduces the padding needed to ensure that segments start on page boundaries in ELF snapshots. Bug: https://github.com/dart-lang/sdk/issues/42020 Change-Id: I42a837dae665a3902d881b8d151b49ede87d6c67 Cq-Include-Trybots: luci.dart.try:vm-kernel-precomp-linux-release-x64-try,vm-kernel-precomp-linux-product-x64-try,vm-kernel-precomp-linux-debug-x64-try,vm-kernel-precomp-linux-release-simarm_x64-try Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/150625 Commit-Queue: Tess Strickland <sstrickl@google.com> Reviewed-by: Martin Kustermann <kustermann@google.com> |
||
|---|---|---|
| .. | ||
| bin | ||
| lib | ||
| .gitignore | ||
| analysis_options.yaml | ||
| AUTHORS | ||
| CHANGELOG.md | ||
| LICENSE | ||
| pubspec.yaml | ||
| README.md | ||
native_stack_traces
This package provides libraries and a utility for decoding non-symbolic stack traces generated by an AOT-compiled Dart application.
Converting stack traces
In some modes of AOT compilation, information on mapping execution points to source locations is no longer stored in the Dart image. Instead, this information is translated to separately stored debugging information. This debugging information can then be stripped from the application before shipping.
However, there is a drawback. Stack traces generated by such an application no longer includes file, function, and line number information (i.e., symbolic stack traces). Instead, stack trace frames simply include program counter information. Thus, to find the source information for these frames, we must use the debugging information. This means either keeping the original unstripped application, or saving the debugging information into a separate file.
Given this debugging information, the libraries in this package can turn
non-symbolic stack traces back into symbolic stack traces. In addition, this
package includes a command line tool decode whose output is the same as its
input except that non-symbolic stack traces are translated.
Using decode
Take the following Dart code, which we put in throws.dart. The inlining
pragmas are here just to ensure that bar is inlined into foo and that foo
is not inlined into bar, to illustrate how inlined code is handled in the
translated output.
@pragma('vm:prefer-inline')
bar() => throw null;
@pragma('vm:never-inline')
foo() => bar();
main() => foo();
Now we run the following commands:
# Make sure that we have the native_stack_traces package.
$ pub get native_stack_traces
$ pub global activate native_stack_traces
# We compile the example program, removing the source location information
# from the snapshot and saving the debugging information into throws.debug.
$ dart2native -k aot -S throws.debug -o throws.aotsnapshot throws.dart
# Run the program, saving the error output to throws.err.
$ dartaotruntime throws.aotsnapshot 2>throws.err
# Using the saved debugging information, we can translate the stack trace
# contained in throws.err to its symbolic form.
$ pub global run native_stack_traces:decode translate -d throws.debug -i throws.err
# We can also just pipe the output of running the program directly into
# the utility.
$ dartaotruntime throws.aotsnapshot |& \
pub global run native_stack_traces:decode translate -d throws.debug
Features and bugs
Please file feature requests and bugs at the issue tracker.