On Windows rebuilding the binary isn't enough to unload it
on progrem restart. But the assumption of the test is that on
program re-run LLDB destroys and replaces the old module with
the newly built version. One will have to try hard to evict the
module from the ModuleList (possibly including a call to
`SBDebugger::MemoryPressureDetected`.
See D138724
The tests in this patch expose failures of LLDBs expression evaluator
when a standard library is compiled with debug symbols. This is the case
for RelWithDebugInfo builds of llvm-project (with libcxx).
Until these bugs are fixed, we force these tests to use the system's
standard library.
Differential Revision: https://reviews.llvm.org/D139361
Previously we didn't properly trigger the destructor of
the `lldb_private::Module` backing `libfoo.so`. So the newly
rebuilt version wouldn't actually be loaded on a program re-run.
The test expects the fresh module to be loaded.
This relands commit `71f3cac7895ad516ec25438f803ed3c9916c215a`
Fixes LLDB Linux bots and improves TypeSystem flushing for shared libraries.
Differential Revision: https://reviews.llvm.org/D138724
D127284 introduced a new language option which is not benign from modules
perspective. Before this patch lldb would set up the compiler invocation and
later enable incremental processing. Post-D127284 this does not work because
the option causes a module hash mismatch for implicit modules.
In addition, D127284 enables parsing statements on the global scope if
incremental processing is on and thus `syntax_error_for_lldb_to_find` was
rightfully not recognized as a declaration and is considered a statement
which produces a slightly different diagnostic.
Thanks to Michael Buch for the help in understanding this issue. This patch
should appease the lldb bots.
More discussion available at: https://reviews.llvm.org/D127284
DWARFExpression::Evaluate will convert DW_OP_addr addresses in
a DWARF expression into load addresses on the expression stack
when there is a StackFrame in the ExecutionContext, this from
a change in 2018 in https://reviews.llvm.org/D46362. At the
time this was handling a case that came up in swift programs,
and is no longer necessary. I generalized this conversion to
a load address when a Target is available in
https://reviews.llvm.org/D137682 to make a test case possible;
this change broke a use case that Ted reported.
This change removes my test case, and removes this conversion
of a DW_OP_addr into a load address in some instances.
Differential Revision: https://reviews.llvm.org/D139226
**Summary**
This patch addresses #59128, where LLDB would crash when evaluating
importing a type that has been imported before into the same target.
The proposed solution is to clear the scratch AST (and associated
persistent variables, `ClangASTImporter`, etc.) whenever a module that
could've owned one of the stale `TypeSystem`s gets unloaded/destroyed.
Details:
1. The first time we evaluate the expression we import the decl for Foo into the Targets scratch AST
context (lives in m_scratch_type_system_map). During this process we also create a ClangASTImporter
that lives in the ClangPersistentVariables::m_ast_importer_sp. This importer has decl tracking
structures which reference the source AST that the decl got imported from. This importer also gets
re-used for all calls to DeportType (which we use to copy the final decl into the Targets scratch AST).
2. Rebuilding the executable triggers a tear-down of the Module that was backing the ASTContext that
we originally got the Foo decl from (which lived in the Module::m_type_system_map). However, the Target’s scratch AST lives on.
3. Re-running the same expression will now create a new ASTImporterDelegate where the destination TranslationUnitDecl is
the same as the one from step (1).
4. When importing the new Foo decl we first try to find it in the destination DeclContext, which happens to be
the scratch destination TranslationUnitDecl. The `Foo` decl exists in this context since we copied it into
the scratch AST in the first run. The ASTImporter then queries LLDB for the origin of that decl. Using the
same persistent variable ClangASTImporter we claim the decl has an origin in the AST context that got torn
down with the Module. This faulty origin leads to a use-after-free.
**Testing**
- Added API test
Differential Revision: https://reviews.llvm.org/D138724
Allow `dwim-print` to evaluate expressions using the dummy target if no real
target exists.
This adds some parity to `expression`. With this, both of the following work:
```
lldb -o 'expr 1+2'
lldb -o 'dwim-print 1+2'
```
Differential Revision: https://reviews.llvm.org/D138960
A previous patch added the ability for us to tell if types were forcefully completed. This patch adds the ability to see which modules have forcefully completed types and aggregates the number of modules with forcefully completed types at the root level.
We add a module specific setting named "debugInfoHadIncompleteTypes" that is a boolean value. We also aggregate the number of modules at the root level that had incomplete debug info with a key named "totalModuleCountWithIncompleteTypes" that is a count of number of modules that had incomplete types.
Differential Revision: https://reviews.llvm.org/D138638
This data formatter should print "No Value" if a variant is unset. It does so by checking if `__index` has a value of `-1`, however it does so by interpreting it as a signed int.
By default, `__index` has type `unsigned int`. When `_LIBCPP_ABI_VARIANT_INDEX_TYPE_OPTIMIZATION` is enabled, the type of `__index` is either `unsigned char`, `unsigned short`, or `unsigned int`, depending on how many fields there are -- as small as possible. For example, when `std::variant` has only a few types, the index type is `unsigned char`, and the npos value will be interpreted by LLDB as `255` when it should be `-1`.
This change does not special case the variant optimization; it just reads the type instead of assuming it's `unsigned int`.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D138892
This patch adds a formatter for `std::ranges::ref_view<T>`.
It simply holds a `T*`, so all this formatter does is dereference
this pointer and format it as `T` would be.
**Testing**
* Added API tests
Differential Revision: https://reviews.llvm.org/D138558
Implements `dwim-print`, a printing command that chooses the most direct,
efficient, and resilient means of printing a given expression.
DWIM is an acronym for Do What I Mean. From Wikipedia, DWIM is described as:
> attempt to anticipate what users intend to do, correcting trivial errors
> automatically rather than blindly executing users' explicit but
> potentially incorrect input
The `dwim-print` command serves as a single print command for users who don't
yet know, or prefer not to know, the various lldb commands that can be used to
print, and when to use them.
This initial implementation is the base foundation for `dwim-print`. It accepts
no flags, only an expression. If the expression is the name of a variable in
the frame, then effectively `frame variable` is used to get, and print, its
value. Otherwise, printing falls back to using `expression` evaluation. In this
initial version, frame variable paths will be handled with `expression`.
Following this, there are a number of improvements that can be made. Some
improvements include supporting `frame variable` expressions or registers.
To provide transparency, especially as the `dwim-print` command evolves, a new
setting is also introduced: `dwim-print-verbosity`. This setting instructs
`dwim-print` to optionally print a message showing the effective command being
run. For example `dwim-print var.meth()` can print a message such as: "note:
ran `expression var.meth()`".
See https://discourse.llvm.org/t/dwim-print-command/66078 for the proposal and
discussion.
Differential Revision: https://reviews.llvm.org/D138315
The libc++ data formatter for `std::shared_ptr` allows any namespace, but the test asserts that it must be the default `__1` namespace. Relax the regex to allow anything that looks like `__.*` (although we use `__[^:]*` so we don't match arbitrarily long text).
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D129898
The layout is essentially just reversed from the stable std::string layout.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D138850
This reverts commit 4346318f5c.
This test case is failing on macOS, reverting until it can be
looked at more closely to unblock the macOS CI bots.
```
File "/Volumes/work/llvm/llvm-project/lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/coroutine_handle/TestCoroutineHandle.py", line 121, in test_libcpp
self.do_test(USE_LIBCPP)
File "/Volumes/work/llvm/llvm-project/lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/coroutine_handle/TestCoroutineHandle.py", line 45, in do_test
self.expect_expr("noop_hdl",
File "/Volumes/work/llvm/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 2441, in expect_expr
value_check.check_value(self, eval_result, str(eval_result))
File "/Volumes/work/llvm/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 306, in check_value
test_base.assertEqual(self.expect_summary, val.GetSummary(),
AssertionError: 'noop_coroutine' != 'coro frame = 0x100004058'
- noop_coroutine+ coro frame = 0x100004058 : (std::coroutine_handle<void>) $1 = coro frame = 0x100004058 {
resume = 0x0000000100003344 (a.out`___lldb_unnamed_symbol223)
destroy = 0x0000000100003344 (a.out`___lldb_unnamed_symbol223)
}
Checking SBValue: (std::coroutine_handle<void>) $1 = coro frame = 0x100004058 {
resume = 0x0000000100003344 (a.out`___lldb_unnamed_symbol223)
destroy = 0x0000000100003344 (a.out`___lldb_unnamed_symbol223)
}
```
Those lldb_unnamed_symbols are synthetic names that ObjectFileMachO
adds to the symbol table, most often seen with stripped binaries,
based off of the function start addresses for all the functions -
if a function has no symbol name, lldb adds one of these names.
This change was originally landed via https://reviews.llvm.org/D132624
This reverts commit cd3091a88f.
This change crashes on macOS systems in
formatters::StdlibCoroutineHandleSyntheticFrontEnd when
it fails to create the `ValueObjectSP promise` and calls
a method on it. The failure causes a segfault while running
TestCoroutineHandle.py on the "LLDB Incremental" CI bot,
https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/
This change originally landed via https://reviews.llvm.org/D132815
A malformed qMemoryRegionInfo response can easily trigger an infinite
loop if regions end (base + size) wraps the address space. A
particularly interesting is the case where base+size=0, which a stub
could use to say that the rest of the memory space is unmapped, even
though lldb expects 0xff... in this case.
One could argue which behavior is more correct (technically, the
current behavior does not say anything about the last byte), but unless
we stop using 0xff... to mean "invalid address", that discussion is very
academic. This patch truncates address ranges which wraps the address
space, which handles the zero case as well as other kinds of malformed
packets.
-flimit-debug-info and other compiler options might end up removing debug info that is needed for debugging. LLDB marks these types as being forcefully completed in the metadata in the TypeSystem. These types should have been complete in the debug info but were not because the compiler omitted them to save space. When we can't find a suitable replacement for the type, we should let the user know that these types are incomplete to indicate there was an issue instead of just showing nothing for a type.
The solution is to display presented in this patch is to display "<incomplete type>" as the summary for any incomplete types. If there is a summary string or function that is provided for a type, but the type is currently forcefully completed, the installed summary will be ignored and we will display "<incomplete type>". This patch also exposes the ability to ask a SBType if it was forcefully completed with:
bool SBType::IsTypeForcefullyCompleted();
This will allow the user interface for a debugger to also detect this issue and possibly mark the variable display up on some way to indicate to the user the type is incomplete.
To show how this is diplayed, we can look at the existing output first for the example source file from the file: lldb/test/API/functionalities/limit-debug-info/main.cpp
(lldb) frame variable inherits_from_one inherits_from_two one_as_member two_as_member array_of_one array_of_two shadowed_one
(InheritsFromOne) ::inherits_from_one = (member = 47)
(InheritsFromTwo) ::inherits_from_two = (member = 47)
(OneAsMember) ::one_as_member = (one = member::One @ 0x0000000100008028, member = 47)
(TwoAsMember) ::two_as_member = (two = member::Two @ 0x0000000100008040, member = 47)
(array::One [3]) ::array_of_one = ([0] = array::One @ 0x0000000100008068, [1] = array::One @ 0x0000000100008069, [2] = array::One @ 0x000000010000806a)
(array::Two [3]) ::array_of_two = ([0] = array::Two @ 0x0000000100008098, [1] = array::Two @ 0x0000000100008099, [2] = array::Two @ 0x000000010000809a)
(ShadowedOne) ::shadowed_one = (member = 47)
(lldb) frame variable --show-types inherits_from_one inherits_from_two one_as_member two_as_member array_of_one array_of_two shadowed_one
(InheritsFromOne) ::inherits_from_one = {
(int) member = 47
}
(InheritsFromTwo) ::inherits_from_two = {
(int) member = 47
}
(OneAsMember) ::one_as_member = {
(member::One) one = {}
(int) member = 47
}
(TwoAsMember) ::two_as_member = {
(member::Two) two = {}
(int) member = 47
}
(array::One [3]) ::array_of_one = {
(array::One) [0] = {}
(array::One) [1] = {}
(array::One) [2] = {}
}
(array::Two [3]) ::array_of_two = {
(array::Two) [0] = {}
(array::Two) [1] = {}
(array::Two) [2] = {}
}
(ShadowedOne) ::shadowed_one = {
(int) member = 47
}
With this patch in place we can now see any classes that were forcefully completed to let us know that we are missing information:
(lldb) frame variable inherits_from_one inherits_from_two one_as_member two_as_member array_of_one array_of_two shadowed_one
(InheritsFromOne) ::inherits_from_one = (One = <incomplete type>, member = 47)
(InheritsFromTwo) ::inherits_from_two = (Two = <incomplete type>, member = 47)
(OneAsMember) ::one_as_member = (one = <incomplete type>, member = 47)
(TwoAsMember) ::two_as_member = (two = <incomplete type>, member = 47)
(array::One[3]) ::array_of_one = ([0] = <incomplete type>, [1] = <incomplete type>, [2] = <incomplete type>)
(array::Two[3]) ::array_of_two = ([0] = <incomplete type>, [1] = <incomplete type>, [2] = <incomplete type>)
(ShadowedOne) ::shadowed_one = (func_shadow::One = <incomplete type>, member = 47)
(lldb) frame variable --show-types inherits_from_one inherits_from_two one_as_member two_as_member array_of_one array_of_two shadowed_one
(InheritsFromOne) ::inherits_from_one = {
(One) One = <incomplete type> {}
(int) member = 47
}
(InheritsFromTwo) ::inherits_from_two = {
(Two) Two = <incomplete type> {}
(int) member = 47
}
(OneAsMember) ::one_as_member = {
(member::One) one = <incomplete type> {}
(int) member = 47
}
(TwoAsMember) ::two_as_member = {
(member::Two) two = <incomplete type> {}
(int) member = 47
}
(array::One[3]) ::array_of_one = {
(array::One) [0] = <incomplete type> {}
(array::One) [1] = <incomplete type> {}
(array::One) [2] = <incomplete type> {}
}
(array::Two[3]) ::array_of_two = {
(array::Two) [0] = <incomplete type> {}
(array::Two) [1] = <incomplete type> {}
(array::Two) [2] = <incomplete type> {}
}
(ShadowedOne) ::shadowed_one = {
(func_shadow::One) func_shadow::One = <incomplete type> {}
(int) member = 47
}
Differential Revision: https://reviews.llvm.org/D138259
This patch adds a new runToBinaryEntry option which sets a one-shot breakpoint
at program entry. This option is useful for synchronizing module loading with
dynamic loader to measure debugger startup performance: when program entry
one-short breakpoint hits most of the dependency modules should have been
loaded so this provides a good sample point for debugger startup time.
More explicitly for lldb-vscode, when this option is enabled, "Initialized" DAP
event is synchronously sent after most dependency modules are loaded.
Differential Revision: https://reviews.llvm.org/D135798
This test copies main.c to main-copy.c and modifies main-copy.c while debugging, but main.c may have come from a readonly location, which means writing to main-copy.c will fail because permissions are preserved. Run the equivalent of "chmod u+w" before attempting to modify it.
This effect can be seen by attempting to run this test after running `chmod u-w lldb/test/API/source-manager/main.c`
After D134378, we started seeing crashes with incomplete types (in the
context of shared libraries).
When trying to print a `std::vector<int> &` with only debug info for a
declaration, we now try to use the formatter after D134378. With an
incomplete type, this somehow goes into infinite recursion with the
frames
```
lldb_private::ValueObject::Dereference
lldb_private::ValueObjectSynthetic::CreateSynthFilter
lldb_private::ValueObjectSynthetic::ValueObjectSynthetic
lldb_private::ValueObject::CalculateSyntheticValue
lldb_private::ValueObject::HasSyntheticValue
```
This has to do with `FrontEndWantsDereference` that some STL formatters
set, causing recursion between the formatter (which tries to dereference),
and dereferencing (which wants to know if there's a formatter to avoid dereferencing).
The reason this only started appearing after D134378 was because
previously with incomplete types, for names with `<`, lldb would attempt
to parse template parameter DIEs, which were empty, then create an empty
`ClassTemplateSpecializationDecl` which overrode the name used to lookup
a formatter in `FormattersMatchData()` to not include template
parameters (e.g. `std::vector<> &`). After D134378 we don't create a
`ClassTemplateSpecializationDecl` when there are no template parameters
and the name to lookup a formatter is the original name (e.g.
`std::vector<int> &`).
The code to try harder with incomplete child compiler types was added in
D79554 for ObjC purposes.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D137983
TestVSCode_coreFile looks for an exe/core file in the same directory as the test. It first calls `realpath`, but I don't think it's necessary. Using `realpath` prevents this test from working when run as part of a build system that uses content-addressed-storage, i.e. all the files might all be symlinks in the same directory pointing to files in different directories elsewhere. If some amount of normalization is needed, maybe `os.path.normpath()` would be useful, although I wouldn't see why that's needed either.
(This is a fairly trivial patch, but I'm mailing it to see if there is a reason we need to keep `realpath`, and if so, if there's some other workaround we can do).
Differential Revision: https://reviews.llvm.org/D138345
So far, the pretty printer for `std::coroutine_handle` internally
dereferenced the contained frame pointer displayed the `promise`
as a sub-value. As noticed in https://reviews.llvm.org/D132624
by @labath, this can lead to an endless loop in lldb during printing
if the coroutine frame pointers form a cycle.
This commit breaks the cycle by exposing the `promise` as a pointer
type instead of a value type. The depth to which the `frame variable`
and the `expression` commands dereference those pointers can be
controlled using the `--ptr-depth` argument.
Differential Revision: https://reviews.llvm.org/D132815
We have a statistic on each module named "debugInfoHadVariableErrors" which tracks when we have debug info, but an error prevented the variables from being displayed. This patch adds a new top level statistic named "totalModuleCountWithVariableErrors" which is a count of the modules that have "debugInfoHadVariableErrors" set to true.
Differential Revision: https://reviews.llvm.org/D138383
With this commit, the `std::coroutine_handle` pretty printer now
recognizes `std::noop_coroutine()` handles. For noop coroutine handles,
we identify use the summary string `noop_coroutine` and we don't print
children
Instead of
```
(std::coroutine_handle<void>) $3 = coro frame = 0x555555559058 {
resume = 0x00005555555564f0 (a.out`std::__1::coroutine_handle<std::__1::noop_coroutine_promise>::__noop_coroutine_frame_ty_::__dummy_resume_destroy_func() at noop_coroutine_handle.h:79)
destroy = 0x00005555555564f0 (a.out`std::__1::coroutine_handle<std::__1::noop_coroutine_promise>::__noop_coroutine_frame_ty_::__dummy_resume_destroy_func() at noop_coroutine_handle.h:79)
}
```
we now print
```
(std::coroutine_handle<void>) $3 = noop_coroutine
```
Differential Revision: https://reviews.llvm.org/D132735
The original commit was missing a `ClangASTImporter::CopyType` call.
Original commit message:
This commit teaches the `std::coroutine_handle` pretty-printer to
devirtualize type-erased promise types. This is particularly useful to
resonstruct call stacks, either of asynchronous control flow or of
recursive invocations of `std::generator`. For the example recently
introduced by https://reviews.llvm.org/D132451, printing the `__promise`
variable now shows
```
(std::__coroutine_traits_sfinae<task, void>::promise_type) __promise = {
continuation = coro frame = 0x555555562430 {
resume = 0x0000555555556310 (a.out`task detail::chain_fn<1>() at llvm-nested-example.cpp:66)
destroy = 0x0000555555556700 (a.out`task detail::chain_fn<1>() at llvm-nested-example.cpp:66)
promise = {
continuation = coro frame = 0x5555555623e0 {
resume = 0x0000555555557070 (a.out`task detail::chain_fn<2>() at llvm-nested-example.cpp:66)
destroy = 0x0000555555557460 (a.out`task detail::chain_fn<2>() at llvm-nested-example.cpp:66)
promise = {
...
}
}
result = 0
}
}
result = 0
}
```
(shortened to keep the commit message readable) instead of
```
(std::__coroutine_traits_sfinae<task, void>::promise_type) __promise = {
continuation = coro frame = 0x555555562430 {
resume = 0x0000555555556310 (a.out`task detail::chain_fn<1>() at llvm-nested-example.cpp:66)
destroy = 0x0000555555556700 (a.out`task detail::chain_fn<1>() at llvm-nested-example.cpp:66)
}
result = 0
}
```
Note how the new debug output reveals the complete asynchronous call
stack: our own function resumes `chain_fn<1>` which in turn will resume
`chain_fn<2>` and so on. Thereby this change allows users of lldb to
inspect the logical coroutine call stack without using any custom debug
scripts (although the display is still a bit clumsy. It would be nicer
to also integrate this into lldb's backtrace feature, but I don't know
how to do so)
The devirtualization currently works by introspecting the function
pointed to by the `destroy` pointer. (The `resume` pointer is not worth
much, given that for the final suspend point `resume` is set to a
nullptr. We have to use the `destroy` pointer instead.) We then look
for a `__promise` variable inside the `destroy` function. This
`__promise` variable is synthetically generated by LLVM, and looking at
its type reveals the type-erased promise_type.
This approach only works for clang-generated code, though. While gcc
also adds a `_Coro_promise` variable to the `resume` function, it does
not do so for the `destroy` function. However, we can't use the `resume`
function, as it will be reset to a nullptr at the final suspension
point. For the time being, I am happy with de-virtualization only working
for clang. A follow-up commit will further improve devirtualization and
also expose the variables spilled to the coroutine frame. As part of
this, I will also revisit gcc support.
Differential Revision: https://reviews.llvm.org/D132624
This patch improves the ScriptedPythonInterface::Dispatch method to
support passing lldb_private types to the python implementation.
This will allow, for instance, the Scripted Process python implementation
to report errors when reading memory back to lldb.
To do so, the Dispatch method will transform the private types in the
parameter pack into `PythonObject`s to be able to pass them down to the
python methods.
Then, if the call succeeded, the transformed arguments will be converted
back to their original type and re-assigned in the parameter pack, to
ensure pointers and references behaviours are preserved.
This patch also updates various scripted process python class and tests
to reflect this change.
rdar://100030995
Differential Revision: https://reviews.llvm.org/D134033
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
`GetPropertyAtIndexAsArgs` returns true on success and false on failure. Right
now it returns the converted `size_t` returned from `GetArgs` which describes
the number of arguments in the argument list. So for empty argument lists
(`(size_t)0` -> `(bool)false`) this function always fails.
The only observable effect of this seems to be that empty arguments are never
propagated to the internal LaunchInfo for a process. This causes that once any
argument has been added to `target.run-args`, clearing `target.run-args` doesn't
have any effect.
Fixes issue #55568
Reviewed By: JDevlieghere, jingham
Differential Revision: https://reviews.llvm.org/D126057
Some test cases are already marked @skipIfNoSBHeaders, but they make use of SBAPI headers in test setup. The setup will fail if the headers are missing, so it is too late to wait until the test case to apply the skip annotation.
In addition to allowing this to apply to entire classes, I also changed all the existing annotations from test cases to test classes where necessary/appropriate.
Reviewed By: DavidSpickett
Differential Revision: https://reviews.llvm.org/D138181
Followup to D134378.
With PrintingPolicy::SuppressScope, we'd also not print the scope in template params. The intention was only to skip the scope for the class because we expect template params to be fully qualified when comparing them for simple template names.
Instead, use `NamedDecl::getNameForDiagnostic` if we're dealing with a tag, which is what we actually use when emitting debug info in clang. That already has an option to suppress the scope on the base name.
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D137583
This patch will gather debug info & breakpoint info from the statistics dump (from `(SBTarget.GetStatistics())` func) and send to DAP in terminated event.
The statistics content can be huge (especially the `modules`) and dumping in full JSON can create delay in the IDE's debugging UI. (For more details, please read: 7bbd0fba98 ). Hence, we will filter out large contents before returning it in terminated event.
It will keep all the metadata fields (those starts with "total"). For large contents, it uses the opt-out strategy. Currently it only removes the "modules" field. This way every time a new top-level field being added, we will be able to capture them from DAP log without changing lldb-vscode.
The DAP terminated event should look like
```
{
"event":"terminated",
"seq":0,
"statistics": {
"memory": <JSON string>
"targets": <JSON string>, // it's a JSON array, breakpoints info included in each target
<metadata_key: value> // pairs
},
"type":"event"
}
```
All the info above will be append to statistics field in the terminated event
Test Plan
Debugged a simple hello world program from VSCode. Exit debug session in two ways: 1) run to program exit; 2) user initiated debug session end (quit debugging before program exit).
Check DAP log and see both debug sessions have statistics returned in terminated event.
Here's an example when debugging the test program:
```
{"event":"terminated","seq":0,"statistics":{"memory":"{\"strings\":{\"bytesTotal\":1843200,\"bytesUnused\":897741,\"bytesUsed\":945459}}","targets":"[{\"breakpoints\":[{\"details\":{\"Breakpoint\":{\"BKPTOptions\":{\"AutoContinue\":false,\"ConditionText\":\"\",\"EnabledState\":true,\"IgnoreCount\":0,\"OneShotState\":false},\"BKPTResolver\":{\"Options\":{\"NameMask\":[56],\"Offset\":0,\"SkipPrologue\":true,\"SymbolNames\":[\"foo\"]},\"Type\":\"SymbolName\"},\"Hardware\":false,\"Names\":[\"vscode\"],\"SearchFilter\":{\"Options\":{},\"Type\":\"Unconstrained\"}}},\"id\":1,\"internal\":false,\"numLocations\":1,\"numResolvedLocations\":1,\"resolveTime\":0.002232},{\"details\":{\"Breakpoint\":{\"BKPTOptions\":{\"AutoContinue\":false,\"ConditionText\":\"\",\"EnabledState\":true,\"IgnoreCount\":0,\"OneShotState\":false},\"BKPTResolver\":{\"Options\":{\"Column\":0,\"Exact\":false,\"FileName\":\"/data/users/wanyi/llvm-sand/external/llvm-project/lldb/test/API/tools/lldb-vscode/terminated-event/main.cpp\",\"Inlines\":true,\"LineNumber\":5,\"Offset\":0,\"SkipPrologue\":true},\"Type\":\"FileAndLine\"},\"Hardware\":false,\"Names\":[\"vscode\"],\"SearchFilter\":{\"Options\":{},\"Type\":\"Unconstrained\"}}},\"id\":2,\"internal\":false,\"numLocations\":0,\"numResolvedLocations\":0,\"resolveTime\":0.23203799999999999},{\"details\":{\"Breakpoint\":{\"BKPTOptions\":{\"AutoContinue\":false,\"ConditionText\":\"\",\"EnabledState\":true,\"IgnoreCount\":0,\"OneShotState\":false},\"BKPTResolver\":{\"Options\":{\"Language\":\"c\",\"NameMask\":[4,4,4,4,4,4],\"Offset\":0,\"SkipPrologue\":false,\"SymbolNames\":[\"_dl_debug_state\",\"rtld_db_dlactivity\",\"__dl_rtld_db_dlactivity\",\"r_debug_state\",\"_r_debug_state\",\"_rtld_debug_state\"]},\"Type\":\"SymbolName\"},\"Hardware\":false,\"SearchFilter\":{\"Options\":{\"ModuleList\":[\"/usr/lib64/ld-2.28.so\"]},\"Type\":\"Modules\"}}},\"id\":-1,\"internal\":true,\"kindDescription\":\"shared-library-event\",\"numLocations\":1,\"numResolvedLocations\":1,\"resolveTime\":0.00026699999999999998}],\"expressionEvaluation\":{\"failures\":0,\"successes\":0},\"firstStopTime\":0.087458974999999994,\"frameVariable\":{\"failures\":0,\"successes\":0},\"launchOrAttachTime\":0.052953161999999998,\"moduleIdentifiers\":[94554748126576,94554747837792,94554747149216,139800112130176,139800112161056,139800112206064,139800112340224,139800112509552,139800112236528],\"signals\":[{\"SIGSTOP\":1}],\"sourceMapDeduceCount\":0,\"stopCount\":8,\"targetCreateTime\":0.00057700000000000004,\"totalBreakpointResolveTime\":0.234537}]","totalDebugInfoByteSize":1668056,"totalDebugInfoEnabled":3,"totalDebugInfoIndexLoadedFromCache":0,"totalDebugInfoIndexSavedToCache":0,"totalDebugInfoIndexTime":0.027963000000000002,"totalDebugInfoParseTime":0.34354800000000002,"totalModuleCount":10,"totalModuleCountHasDebugInfo":3,"totalSymbolTableIndexTime":0.056050000000000003,"totalSymbolTableParseTime":0.23930000000000001,"totalSymbolTableStripped":0,"totalSymbolTablesLoadedFromCache":0,"totalSymbolTablesSavedToCache":0},"type":"event"}
```
Differential Revision: https://reviews.llvm.org/D137665
Rosetta 2 is not installed by default in a fresh macOS installation
on Apple Silicon, so x86 binaries cannot be run. CI bots are often
in this state. Update this test to check for the rosetta debugserver,
which our debugserver also hardcodes the path of, before trying to
run an x86 process on AS systems.
A fresh install of macOS does not have Rosetta 2 installed by
default; the CI bots are often in this state, resulting in a
test failure. debugserver already hardcodes the filepath of
the Rosetta 2 debugserver; test if that file exists before
running the Rosetta test.
When we cannot allocate memory in the inferior process, the IR
interpreter's IRMemoryMap::FindSpace will create an lldb local
buffer and assign it an address range in the inferior address
space. When the interpreter sees an address in that range, it
will read/write from the local buffer instead of the target. If
this magic address overlaps with actual data in the target, the
target cannot be accessed through expressions.
Instead of using a high memory address that is validly addressable,
this patch uses an address that cannot be accessed on 64-bit systems
that don't actually use all 64 bits of the virtual address.
Differential Revision: https://reviews.llvm.org/D137682
rdar://96248287
Fix `fullpath` to not assume a `/` path separator. This was discovered when
D133130 failed on Windows. Use `os.path.join()` to fix the issue.
Reviewed By: mib
Differential Revision: https://reviews.llvm.org/D133366
