Follow up to D129386 where libc++ naming conventions were made consistent.
This changes the pattern to not rely on the internal name (`__cc` or `__cc_`),
and instead uses a pattern to check that the child has the form:
```
[0] = {
first = ...
```
Thanks to @rupprecht for pointing out this issue: https://reviews.llvm.org/D133259#3773120
Reviewed By: rupprecht
Differential Revision: https://reviews.llvm.org/D133395
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
**Summary**
The public lldb matrix bot is failing for tests compiled with clang-9, clang-11, clang-13.
This patch addresses these failures by evaluating the enum case that
doesn't cause malformed DWARF in older version of clang.
There was no particular reason we had to use `true` enum case
to reproduce the bug in #58383, so simply switch to use `false`
to get all bots passing again.
**Details**
In older versions of clang, the following snippet:
```
enum EnumBool : bool {
enum_bool_case1 = false,
enum_bool_case2 = true,
};
struct A {
const static EnumBool enum_bool_val = enum_bool_case2;
};
```
…results in following DWARF:
```
0x00000052: DW_TAG_structure_type
DW_AT_calling_convention (DW_CC_pass_by_value)
DW_AT_name ("A")
DW_AT_byte_size (0x01)
DW_AT_decl_file ("/Users/michaelbuch/Git/llvm-project/lldb/test/API/lang/cpp/const_static_integral_member/repro.cpp")
DW_AT_decl_line (6)
0x0000005b: DW_TAG_member
DW_AT_name ("enum_bool_val")
DW_AT_type (0x0000000000000068 "const EnumBool")
DW_AT_decl_file ("/Users/michaelbuch/Git/llvm-project/lldb/test/API/lang/cpp/const_static_integral_member/repro.cpp")
DW_AT_decl_line (7)
DW_AT_external (true)
DW_AT_declaration (true)
DW_AT_const_value (-1)
```
Note the `DW_AT_const_value == -1`
When evaluating `A::enum_bool_val` in the lldb we get:
```
(lldb) p A::enum_bool_val
error: expression failed to parse:
error: Couldn't lookup symbols:
__ZN1A13enum_bool_valE
```
Enabling the DWARF logs we see:
```
(arm64) clang-13.out: DWARFASTParserClang::ParseTypeFromDWARF (die = 0x00000068, decl_ctx = 0x136ac1e30 (die 0x0000000b)) DW_TAG_const_type name = '(null)')
Failed to add const value to variable A::enum_bool_val: Can't store unsigned value 18446744073709551615 in integer with 1 bits.
```
This occurs because a boolean enum is considered an unsigned integer
type, but we try to initialize it with a `-1`.
**Testing**
- Confirmed locally that top-of-tree lldb correctly
evaluates the previously failing expression when
the test program is compiled with clang-13
Differential Revision: https://reviews.llvm.org/D137793
This change adds a `--recognizer-function` (`-R`) to `type summary add`
and `type synth add` that allows users to specify that the names in
the command are not type names but python function names.
It also adds an example to lldb/examples, and a section in the data
formatters documentation on how to use recognizer functions.
Differential Revision: https://reviews.llvm.org/D137000
This didn't work previously because we had to check whether the incoming
command was an alias command, but if it wasn't we still used the result
of that lookup - which was by the command's node name. That fails for
non-top-level commands. In this case, the resolution is pretty simple since
we already have the node's CommandObject, so all we needed to do was turn
it into a shared pointer, for which I added enable_shared_from_this to the
CommandObject.
Differential Revision: https://reviews.llvm.org/D137662
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/D137003
This makes setting breakpoints work with -gsimple-template-names.
Assume that callers handle false positives. For example, `Module::LookupInfo::Prune` removes wrong template instantiations when setting a breakpoint.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D137098
For an exception crashlog, the thread backtraces aren't usually very helpful
and instead, developpers look at the "Application Specific Backtrace" that
was generated by `objc_exception_throw`.
LLDB could already parse and symbolicate these Application Specific Backtraces
for regular textual-based crashlog, so this patch adds support to parse them
in JSON crashlogs, and materialize them a HistoryThread extending the
crashed ScriptedThread.
This patch also includes the Application Specific Information messages
as part of the process extended crash information log. To do so, the
ScriptedProcess Python interface has a new GetMetadata method that
returns an arbitrary dictionary with data related to the process.
rdar://93207586
Differential Revision: https://reviews.llvm.org/D126260
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch improves the StructuredData classes to provide a
GetDescription(lldb_private::Stream&) affordance.
This is very convenient compared to the Dump method because this try to
pretty print the structure instead of just serializing it into a JSON.
This patch also updates some parts of lldb (i.e. extended crash info) to
use this new affordance instead of StructuredData::Dump.
Differential Revision: https://reviews.llvm.org/D135547
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Undoes a lot of the code added in D135169 to piggyback off of the enum logic in `TypeSystemClang::SetIntegerInitializerForVariable()`.
Fixes#58383.
Reviewed By: DavidSpickett
Differential Revision: https://reviews.llvm.org/D137045
https://reviews.llvm.org/D127702 adds the initial logpoints support in
lldb-vscode. This patch further improves it by:
1. Adding a newline at the end of each log message
2. Support most of the format specifiers like \t, \n, \x etc..
The implementation is borrowed from FormatEntity::ParseInternal(). Future
patch should merge these two implementations.
Differential Revision: https://reviews.llvm.org/D136697
This makes use of the changes introduced in D134604, in order to
instantiate alias templates witn a final sugared substitution.
This comes at no additional relevant cost.
Since we don't track / unique them in specializations, we wouldn't be
able to resugar them later anyway.
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Differential Revision: https://reviews.llvm.org/D136565
See https://discourse.llvm.org/t/dwarf-using-simplified-template-names/58417 for background on simplified template names.
lldb doesn't work with simplified template names because it uses DW_AT_name which doesn't contain template parameters under simplified template names.
Two major changes are required to make lldb work with simplified template names.
1) When building clang ASTs for struct-like dies, we use the name as a cache key. To distinguish between different instantiations of a template class, we need to add in the template parameters.
2) When looking up types, if the requested type name contains '<' and we didn't initially find any types from the index searching the name, strip the template parameters and search the index, then filter out results with non-matching template parameters. This takes advantage of the clang AST's ability to print full names rather than doing it by ourself.
An alternative is to fix up the names in the index to contain the fully qualified name, but that doesn't respect .debug_names.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D134378
This patch reverts
- commit d4b1964f0554046b1e64908e5c1cd701b25f4c9e
- commit 59f0827e2cf3755834620e7e0b6d946832440f80([clang] Instantiate alias templates with sugar)
As it makes clang fail to pass some code it used to compile.
See comments: https://reviews.llvm.org/D136564#3891065
These functions return the information about the host process (so they
show the executable as "qemu" and have the "wrong" architecture), which
isn't useful and can confuse lldb.
We could theoretically try to identify which host processes are running
an emulator, and translate the process information, but that would be
tricky to implement, and the usefulness of it would be fairly limited as
qemu does not support attaching to a running process.
Update the Python tests (ie tests run via `lldb-dotest -p TestTrace`) to
handle new error introduced in D136610.
Test Plan:
`lldb-dotest -p TestTrace`
Differential Revision: https://reviews.llvm.org/D136801
This makes use of the changes introduced in D134604, in order to
instantiate alias templates witn a final sugared substitution.
This comes at no additional relevant cost.
Since we don't track / unique them in specializations, we wouldn't be
able to resugar them later anyway.
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Differential Revision: https://reviews.llvm.org/D136565
This reverts commit c8a26f8c6de30dbd814546f02e4c89a4fcb2b4ef.
Returning full statistics result in "terminated" (DAP) event could result in delay in the UI when debugging from VSCode.
If the program run to exit and debug session terminates. The DAP event order will be: exited event --> terminateCommands --> terminated event --> disconnect request --> disconnect response.
The debugging UI in VSCode corresponds to "disconnect" request/response. If the terminated event is taking long to process, the IDE won't quit debugging UI until it's done.
For big binary (tested example has 29 GB of debug info), it can cause ~15s delay in terminated event itself. And the UI could take ~20s to reflect.
This may cause confusion in debug sessions. We should persuit a more lightweight return or other solution to return such info.
In certain configurations, libc++ headers all exist in the same directory, and libc++ binaries exist in the same directory as lldb libs. When `LLVM_ENABLE_PER_TARGET_RUNTIME_DIR` is enabled (*and* the host is not Apple, which is why I assume this wasn't caught by others?), this is not the case: most headers will exist in the usual `include/c++/v1` directory, but `__config_site` exists in `include/$TRIPLE/c++/v1`. Likewise, the libc++.so binary exists in `lib/$TRIPLE/`, not `lib/` (where LLDB libraries reside).
This also adds the just-built-libcxx functionality to the lldb-dotest tool.
The `LIBCXX_` cmake config is borrowed from `libcxx/CMakeLists.txt`. I could not figure out a way to share the cmake config; ideally we would reuse the same config instead of copy/paste.
Reviewed By: JDevlieghere, fdeazeve
Differential Revision: https://reviews.llvm.org/D133973
This patch will gather debug info & breakpoint info from the statistics dump and send to DAP in terminated event.
We will return full contents of statistics dump (`SBTarget.GetStatistics()`) as a JSON string. So that every time a new field being added, we will be able to capture them from DAP log without changing lldb-vscode.
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\":1851392,\"bytesUnused\":905933,\"bytesUsed\":945459}},\"modules\":[{\"debugInfoByteSize\":0,\"debugInfoEnabled\":false,\"debugInfoIndexLoadedFromCache\":false,\"debugInfoIndexSavedToCache\":false,\"debugInfoIndexTime\":0,\"debugInfoParseTime\":0,\"identifier\":93901655961472,\"path\":\"/data/users/wanyi/llvm-sand/build/Debug/fbcode-x86_64/toolchain/lldb-test-build.noindex/tools/lldb-vscode/terminated-event/TestVSCode_terminatedEvent.test_terminated_event/a.out.stripped\",\"symbolTableIndexTime\":0.00067299999999999999,\"symbolTableLoadedFromCache\":false,\"symbolTableParseTime\":0.00054799999999999998,\"symbolTableSavedToCache\":false,\"symbolTableStripped\":false,\"triple\":\"x86_64--linux\",\"uuid\":\"E317E50F\"},{\"debugInfoByteSize\":833593,\"debugInfoEnabled\":true,\"debugInfoIndexLoadedFromCache\":false,\"debugInfoIndexSavedToCache\":false,\"debugInfoIndexTime\":0.012657,\"debugInfoParseTime\":0.32714500000000002,\"identifier\":93901656106336,\"path\":\"/usr/lib64/ld-2.28.so\",\"symbolTableIndexTime\":0.0017719999999999999,\"symbolTableLoadedFromCache\":false,\"symbolTableParseTime\":0.025423000000000001,\"symbolTableSavedToCache\":false,\"symbolTableStripped\":false,\"triple\":\"x86_64--linux\",\"uuid\":\"57D782C6-AF24-135E-6970-7B9D3334B91B-6CD33392\"},{\"debugInfoByteSize\":0,\"debugInfoEnabled\":false,\"debugInfoIndexLoadedFromCache\":false,\"debugInfoIndexSavedToCache\":false,\"debugInfoIndexTime\":0,\"debugInfoParseTime\":0,\"identifier\":93901654578688,\"path\":\"[vdso](0x00007ffff7ffd000)\",\"symbolTableIndexTime\":3.1000000000000001e-05,\"symbolTableLoadedFromCache\":false,\"symbolTableParseTime\":0.00038900000000000002,\"symbolTableSavedToCache\":false,\"symbolTableStripped\":false,\"triple\":\"x86_64-unknown-linux-gnu\",\"uuid\":\"B5AF4022-69CE-E598-5703-F5C62C32322D-D9CF26D1\"},{\"debugInfoByteSize\":1020,\"debugInfoEnabled\":true,\"debugInfoIndexLoadedFromCache\":false,\"debugInfoIndexSavedToCache\":false,\"debugInfoIndexTime\":0.0021559999999999999,\"debugInfoParseTime\":0.00024699999999999999,\"identifier\":140008887806080,\"path\":\"/data/users/wanyi/llvm-sand/build/Debug/fbcode-x86_64/toolchain/lldb-test-build.noindex/tools/lldb-vscode/terminated-event/TestVSCode_terminatedEvent.test_terminated_event/libfoo.so\",\"symbolTableIndexTime\":6.2000000000000003e-05,\"symbolTableLoadedFromCache\":false,\"symbolTableParseTime\":0.00080800000000000002,\"symbolTableSavedToCache\":false,\"symbolTableStripped\":false,\"triple\":\"x86_64--\",\"uuid\":\"109BFB15\"},{\"debugInfoByteSize\":0,\"debugInfoEnabled\":false,\"debugInfoIndexLoadedFromCache\":false,\"debugInfoIndexSavedToCache\":false,\"debugInfoIndexTime\":0,\"debugInfoParseTime\":0,\"identifier\":140008887859888,\"path\":\"/lib64/libdl.so.2\",\"symbolTableIndexTime\":0.000105,\"symbolTableLoadedFromCache\":false,\"symbolTableParseTime\":0.0013470000000000001,\"symbolTableSavedToCache\":false,\"symbolTableStripped\":false,\"triple\":\"x86_64--linux\",\"uuid\":\"776BF255-7FD5-1D1A-CAB0-D1D2D7568263-EC5999B5\"},{\"debugInfoByteSize\":0,\"debugInfoEnabled\":false,\"debugInfoIndexLoadedFromCache\":false,\"debugInfoIndexSavedToCache\":false,\"debugInfoIndexTime\":0,\"debugInfoParseTime\":0,\"identifier\":140008887883408,\"path\":\"/lib64/libstdc++.so.6\",\"symbolTableIndexTime\":0.038710000000000001,\"symbolTableLoadedFromCache\":false,\"symbolTableParseTime\":0.075740000000000002,\"symbolTableSavedToCache\":false,\"symbolTableStripped\":false,\"triple\":\"x86_64--linux\",\"uuid\":\"104D4081-3FC7-4F42-7CD4-AC714B249C02-DA5E62C3\"},{\"debugInfoByteSize\":0,\"debugInfoEnabled\":false,\"debugInfoIndexLoadedFromCache\":false,\"debugInfoIndexSavedToCache\":false,\"debugInfoIndexTime\":0,\"debugInfoParseTime\":0,\"identifier\":140008887951248,\"path\":\"/lib64/libm.so.6\",\"symbolTableIndexTime\":0.003212,\"symbolTableLoadedFromCache\":false,\"symbolTableParseTime\":0.027257,\"symbolTableSavedToCache\":false,\"symbolTableStripped\":false,\"triple\":\"x86_64--linux\",\"uuid\":\"089E6D24-BF02-DE2B-C57E-456118BFDC1D-691B14BB\"},{\"debugInfoByteSize\":0,\"debugInfoEnabled\":false,\"debugInfoIndexLoadedFromCache\":false,\"debugInfoIndexSavedToCache\":false,\"debugInfoIndexTime\":0,\"debugInfoParseTime\":0,\"identifier\":140008888170224,\"path\":\"/lib64/libgcc_s.so.1\",\"symbolTableIndexTime\":0.000357,\"symbolTableLoadedFromCache\":false,\"symbolTableParseTime\":0.0040460000000000001,\"symbolTableSavedToCache\":false,\"symbolTableStripped\":false,\"triple\":\"x86_64--\",\"uuid\":\"CD2F6200-D8CA-7045-ADDB-17C6C4240AAC-5DE305B1\"},{\"debugInfoByteSize\":0,\"debugInfoEnabled\":false,\"debugInfoIndexLoadedFromCache\":false,\"debugInfoIndexSavedToCache\":false,\"debugInfoIndexTime\":0,\"debugInfoParseTime\":0,\"identifier\":140008887911072,\"path\":\"/lib64/libc.so.6\",\"symbolTableIndexTime\":0.0070210000000000003,\"symbolTableLoadedFromCache\":false,\"symbolTableParseTime\":0.072236999999999996,\"symbolTableSavedToCache\":false,\"symbolTableStripped\":false,\"triple\":\"x86_64--linux\",\"uuid\":\"F65C85BF-DB90-4B62-3D4F-E2139B4D7C25-CF8C0B58\"},{\"debugInfoByteSize\":833593,\"debugInfoEnabled\":true,\"debugInfoIndexLoadedFromCache\":false,\"debugInfoIndexSavedToCache\":false,\"debugInfoIndexTime\":0.012407,\"debugInfoParseTime\":0.012078999999999999,\"identifier\":140008887927648,\"path\":\"/lib64/ld-linux-x86-64.so.2\",\"symbolTableIndexTime\":0.001758,\"symbolTableLoadedFromCache\":false,\"symbolTableParseTime\":0.022352,\"symbolTableSavedToCache\":false,\"symbolTableStripped\":false,\"triple\":\"x86_64--linux\",\"uuid\":\"57D782C6-AF24-135E-6970-7B9D3334B91B-6CD33392\"}],\"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.0020110000000000002},{\"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.22744400000000001},{\"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.00034600000000000001}],\"expressionEvaluation\":{\"failures\":0,\"successes\":0},\"firstStopTime\":0.157499681,\"frameVariable\":{\"failures\":0,\"successes\":0},\"launchOrAttachTime\":0.117741226,\"moduleIdentifiers\":[93901655961472,93901656106336,93901654578688,140008887806080,140008887859888,140008887883408,140008887951248,140008888170224,140008887911072],\"signals\":[{\"SIGSTOP\":1}],\"sourceMapDeduceCount\":0,\"stopCount\":8,\"targetCreateTime\":0.00064000000000000005,\"totalBreakpointResolveTime\":0.22980100000000003}],\"totalDebugInfoByteSize\":1668206,\"totalDebugInfoEnabled\":3,\"totalDebugInfoIndexLoadedFromCache\":0,\"totalDebugInfoIndexSavedToCache\":0,\"totalDebugInfoIndexTime\":0.027220000000000001,\"totalDebugInfoParseTime\":0.33947100000000002,\"totalModuleCount\":10,\"totalModuleCountHasDebugInfo\":3,\"totalSymbolTableIndexTime\":0.053701000000000006,\"totalSymbolTableParseTime\":0.23014699999999999,\"totalSymbolTableStripped\":0,\"totalSymbolTablesLoadedFromCache\":0,\"totalSymbolTablesSavedToCache\":0}","type":"event"}
```
Differential Revision: https://reviews.llvm.org/D136177
This makes use of the changes introduced in D134604, in order to
instantiate alias templates witn a final sugared substitution.
This comes at no additional relevant cost.
Since we don't track / unique them in specializations, we wouldn't be
able to resugar them later anyway.
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Differential Revision: https://reviews.llvm.org/D136565
These tests were being tested against a version of libipt from last
year. We just updated libipt to top of tree and many errors broke
because the new version of libipt emits more events than the older one,
which is fine.
`./bin/lldb-dotest -p TestTrace` passes
There is a bug in lldb-vscode that only shows stop reason ("exception") in
stopped event without showing the stop description of thrown exception. This
causes VSCode UI to only show "Paused on Exception" general message in
callstack window UI.
This patch fixes the bug so that VSCode callstack will show the detailed
exceptioni description, like "signal SIGABRT" or "EXC_BAD_ACCESS..." which
aligns with command line lldb experience.
I use C++ exception in testcase because the hardware exception description is
platform dependent and hard to verify.
Differential Revision: https://reviews.llvm.org/D136295
The low-level decoder might fall into an infinite decoding loop for
various reasons, the simplest being an infinite direct loop reached due
to wrong handling of self-modified code in the kernel, e.g. it might
reach
```
0x0A: pause
0x0C: jump to 0x0A
```
In this case, all the code is sequential and requires no packets to be
decoded. The low-level decoder would produce an output like the
following
```
0x0A: pause
0x0C: jump to 0x0A
0x0A: pause
0x0C: jump to 0x0A
0x0A: pause
0x0C: jump to 0x0A
... infinite amount of times
```
These cases require stopping the decoder to avoid infinite work and signal this
at least as a trace error.
- Add a check that breaks decoding of a single PSB once 500k instructions have been decoded since the last packet was processed.
- Add a check that looks for infinite loops after certain amount of instructions have been decoded since the last packet was processed.
- Add some `settings` properties for tweaking the thresholds of the checks above. This is also nice because it does the basic work needed for future settings.
- Add an AnomalyDetector class that inspects the DecodedThread and the libipt decoder in search for anomalies. These anomalies are then signaled as fatal errors in the trace.
- Add an ErrorStats class that keeps track of all the errors in a DecodedThread, with a special counter for fatal errors.
- Add an entry for decoded thread errors in the `dump info` command.
Some notes are added in the code and in the documention of the settings,
so please read them.
Besides that, I haven't been unable to create a test case in LLVM style, but
I've found an anomaly in the thread #12 of the trace
72533820-3eb8-4465-b8e4-4e6bf0ccca99 at Meta. We have to figure out how to
artificially create traces with this kind of anomalies in LLVM style.
With this change, that anomalous thread now shows:
```
(lldb)thread trace dump instructions 12 -e -i 23101
thread #12: tid = 8
...missing instructions
23101: (error) anomalous trace: possible infinite loop detected of size 2
vmlinux-5.12.0-0_fbk8_clang_6656_gc85768aa64da`panic_smp_self_stop + 5 [inlined] rep_nop at processor.h:13:2
23100: 0xffffffff81342785 pause
vmlinux-5.12.0-0_fbk8_clang_6656_gc85768aa64da`panic_smp_self_stop + 7 at panic.c:87:2
23099: 0xffffffff81342787 jmp 0xffffffff81342785 ; <+5> [inlined] rep_nop at processor.h:13:2
vmlinux-5.12.0-0_fbk8_clang_6656_gc85768aa64da`panic_smp_self_stop + 5 [inlined] rep_nop at processor.h:13:2
23098: 0xffffffff81342785 pause
vmlinux-5.12.0-0_fbk8_clang_6656_gc85768aa64da`panic_smp_self_stop + 7 at panic.c:87:2
23097: 0xffffffff81342787 jmp 0xffffffff81342785 ; <+5> [inlined] rep_nop at processor.h:13:2
vmlinux-5.12.0-0_fbk8_clang_6656_gc85768aa64da`panic_smp_self_stop + 5 [inlined] rep_nop at processor.h:13:2
23096: 0xffffffff81342785 pause
vmlinux-5.12.0-0_fbk8_clang_6656_gc85768aa64da`panic_smp_self_stop + 7 at panic.c:87:2
23095: 0xffffffff81342787 jmp 0xffffffff81342785 ; <+5> [inlined] rep_nop at processor.h:13:2
```
It used to be in an infinite loop where the decoder never stopped.
Besides that, the dump info command shows
```
(lldb) thread trace dump info 12
Errors:
Number of individual errors: 32
Number of fatal errors: 1
Number of other errors: 31
```
and in json format
```
(lldb) thread trace dump info 12 -j
"errors": {
"totalCount": 32,
"libiptErrors": {},
"fatalErrors": 1,
"otherErrors": 31
}
```
Differential Revision: https://reviews.llvm.org/D136557
Prior to this fix, if the compile unit function:
void CompileUnit::ResolveSymbolContext(const SourceLocationSpec &src_location_spec, SymbolContextItem resolve_scope, SymbolContextList &sc_list);
was called with a resolve scope that wasn't just eSymbolContextLineEntry, we would end up calling:
line_entry.range.GetBaseAddress().CalculateSymbolContext(&sc, resolve_scope);
This is ok as long as the line entry's base address is able to be resolved back to the same information, but there were problems when it didn't. The example I found was we have a file with a bad .debug_aranges section where the address to compile unit mapping was incomplete. When this happens, the above function call to calculate the symbol context would end up matching the module and it would NULL out the compile unit and line entry, which means we would fail to set this breakpoint. We have many other clients that ask for eSymbolContextEverything as the resolve_scope, so all other locations could end up failing as well.
The solutions is to make sure the compile unit matches the current compile unit after calling the calculate symbol context. If the compile unit is NULL, then we report an error via the module/debugger as this indicates an entry in the line table fails to resolve back to any compile unit. If the compile unit is not NULL and it differs from the current compile unit, we restore the current compile unit and line entry to ensure the call to .CalculateSymbolContext doesn't match something completely different, as can easily happen if LTO or other link time optimizations are enabled that could end up outlining or merging functions.
This patch allows breakpoint succeeding to work as expected and not get short circuited by our address lookup logic failing.
Differential Revision: https://reviews.llvm.org/D136207
The test TestObjCDirectMethods loads the Objective C runtime, which
doesn't work well with custom a libcxx, resulting in two copies of the
standard library being loaded at runtime.
Like what was done for `TestObjCExceptions`, this commit forces the
usage of the system's library instead. The minimum required Clang
version is set to the oldest Clang that can compile the libraries
available in the lldb-matrix bots.
Differential Revision: https://reviews.llvm.org/D136600
This requirement dates back to ten years ago and the test seems to work
nowadays with either libc++ or libstdc++.
Differential Revision: https://reviews.llvm.org/D136608
This patch teaches the `CPlusPlusNameParser` to parse the
demangled/prettified [[gnu::abi_tag(...)]] attribute. The demangled format
isn't standardized and the additions to the parser were mainly driven
using Clang (and the limited information on this from the official
Clang docs).
This change is motivated by multiple failures around step-in
behaviour for libcxx APIs (many of which have ABI tags as of recently).
LLDB determines whether the `step-avoid-regexp` matches the current
frame by parsing the scope-qualified name out of the demangled
function symbol. On failure, the `CPlusPlusNameParser` will simply
return the fully demangled name (which can include the return type)
to the caller, which in `FrameMatchesAvoidCriteria` means we will
not correctly decide whether we should stop at a frame or not if
the function has an abi_tag.
Ideally we wouldn't want to rely on the non-standard format
of demangled attributes. Alternatives would be:
1. Use the mangle tree API to do the parsing for us
2. Reconstruct the scope-qualified name from DWARF instead of parsing
the demangled name
(1) isn't feasible without a significant refactor of `lldb_private::Mangled`,
if we want to do this efficiently.
(2) could be feasible in cases where debug-info for a frame is
available. But it does mean we certain operations (such as step-in regexp,
and frame function names) won't work with/won't show ABI tags.
**Testing**
* Un-XFAILed step-in API test
* Added parser unit-tests
Differential Revision: https://reviews.llvm.org/D136306
This reverts commit 0205aa4a02570dfeda5807f66756ebdbb102744b because it
breaks TestArray.py:
a->c = <parent failed to evaluate: parent is NULL>
I decided to revert instead of disable the test because it looks like a
legitimate issue with the patch.
With -f(un)signed-char, the die corresponding to "char" may be the opposite DW_ATE_(un)signed_char from the default platform signedness.
Ultimately we should determine whether a type is the unspecified signedness char by looking if its name is "char" (as opposed to "signed char"/"unsigned char") and not care about DW_ATE_(un)signed_char matching the platform default.
Fixes#23443
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D136011
Currently, SymbolFileDWARFDebugMap works on the assumption that there is
only one compile unit per object file. This patch documents this
limitation (when using the general SymbolFile API), and allows users of
the concrete SymbolFileDWARFDebugMap class to find out about these extra
compile units.
Differential Revision: https://reviews.llvm.org/D136114
This patch adds a new matching method for data formatters, in addition
to the existing exact typename and regex-based matching. The new method
allows users to specify the name of a Python callback function that
takes a `SBType` object and decides whether the type is a match or not.
Here is an overview of the changes performed:
- Add a new `eFormatterMatchCallback` matching type, and logic to handle
it in `TypeMatcher` and `SBTypeNameSpecifier`.
- Extend `FormattersMatchCandidate` instances with a pointer to the
current `ScriptInterpreter` and the `TypeImpl` corresponding to the
candidate type, so we can run registered callbacks and pass the type
to them. All matcher search functions now receive a
`FormattersMatchCandidate` instead of a type name.
- Add some glue code to ScriptInterpreterPython and the SWIG bindings to
allow calling a formatter matching callback. Most of this code is
modeled after the equivalent code for watchpoint callback functions.
- Add an API test for the new callback-based matching feature.
For more context, please check the RFC thread where this feature was
originally discussed:
https://discourse.llvm.org/t/rfc-python-callback-for-data-formatters-type-matching/64204/11
Differential Revision: https://reviews.llvm.org/D135648
The JSON dumper is very minimalistic. It pretty much only shows the
delimiting instruction IDs of every segment, so that further queries to
the SBCursor can be used to make sense of the data. It's main purpose is
to be serialized somewhat cheaply.
I also renamed untracedSegment to untracedPrefixSegment, in case in the
future we add an untracedSuffixSegment. In any case, this new name is
more explicit, which I like.
Differential Revision: https://reviews.llvm.org/D136034
This diff implements the reconstruction algorithm for the call tree and
add tests.
See TraceDumper.h for documentation and explanations.
One important detail is that the tree objects are in TraceDumper, even
though Trace.h is a better home. I'm leaving that as future work.
Another detail is that this code is as slow as dumping the entire
symolicated trace, which is not that bad tbh. The reason is that we use
symbols throughout the algorithm and we are not being careful about
memory and speed. This is also another area for future improvement.
Lastly, I made sure that incomplete traces work, i.e. you start tracing
very deep in the stack or failures randomly appear in the trace.
Differential Revision: https://reviews.llvm.org/D135917
The command is thread trace dump function-calls and as minimum will
require printing to a file in json and non-json format
I added a test
Differential Revision: https://reviews.llvm.org/D135521
The test currently sets `USE_LIBSTDCPP = 0`, which is curious given the
behavior of `and` and `or` in Makefiles (the contents of the variables
are not important). In particular, this causes the tests to not use the
standard libraries appropriately.
To capture the actual intent of the test, we're changing this to
`USE_LIBCXX=1`.
Differential Revision: https://reviews.llvm.org/D136171
