Occasionally the assertion that enforces increasing TSC values in `DecodedThread::NotifyTsc`
would get tripped during large multi CPU trace decoding.
The root cause of this issue was an assumption that all the data of a
PSB will fit within the start,end TSC of the "owning"
`ThreadContinuousExecution`. After investigating, this is not the case
because PSBs can have multiple TSCs.
This diff works around this issue by introducing a TSC upper bound for
each `PSBBlockDecoder`. This fixes the assertion failure by simply
"dropping" the remaining data of PSB whenever the TSC upper bound is
exceeded during decoding.
Future work will do a larger refactor of the multi CPU decoding to
remove the dependencies on this incorrect assumption so that PSB blocks
that span multiple `ThreadContinuousExecutions` are correctly handled.
correctly
Test Plan:
Differential Revision: https://reviews.llvm.org/D136610
The local ports for `platform connect` and `attach` were always random, this allows the user to configure them.
This is useful for debugging a truly remote android (when the android in question is connected to a remote server).
There is a lengthier discussion on github - https://github.com/llvm/llvm-project/issues/58114
Reviewed By: clayborg
Differential Revision: https://reviews.llvm.org/D136465
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
Add as little code as possible to allow compiling lldb on LoongArch.
Actual functionality will be implemented later.
Reviewed By: SixWeining, DavidSpickett
Differential Revision: https://reviews.llvm.org/D136578
1. When we evaluating an expression multiple times and the searching scope is translation unit, ParseDeclsForContext iterates the type info and symbol info multiple times, though only the debug info is parsed once. Using llvm::call_once to make it only iterating and parsing once.
2. When evaluating an expression with identifier whose parent scope is a namespace, ParseDeclsForContext needs to search the entire type info to complete those records whose name is prefixed with the namespace's name and the entire symbol info to to parse functions and non-local variables. Caching parsed namespaces to avoid unnecessary searching.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D136006
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 size of the m_hwp_regs array should match the default value of
m_max_hwp_supported. This ensures that no out-of-bounds accesses
occur, even if the array is accessed prior to a call to
ReadHardwareDebugInfo().
Fixes https://github.com/llvm/llvm-project/issues/54520, see also
there for additional background.
Differential Revision: https://reviews.llvm.org/D136144
This is a change to how we represent type subsitution in the AST.
Instead of only storing the replaced type, we track the templated
entity we are substituting, plus an index.
We modify MLTAL to track the templated entity at each level.
Otherwise, it's much more expensive to go from the template parameter back
to the templated entity, and not possible to do in some cases, as when
we instantiate outer templates, parameters might still reference the
original entity.
This also allows us to very cheaply lookup the templated entity we saw in
the naming context and find the corresponding argument it was replaced
from, such as for implementing template specialization resugaring.
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Differential Revision: https://reviews.llvm.org/D131858
This patch fixes a regression with setting breakpoints on template
functions by name. E.g.,:
```
$ cat main.cpp
template<typename T>
struct Foo {
template<typename U>
void func() {}
};
int main() {
Foo<int> f;
f.func<double>();
}
(lldb) br se -n func
```
This has regressed since `3339000e0bda696c2e29173d15958c0a4978a143`
where we started using the `CPlusPlusNameParser` for getting the
basename of the function symbol and match it exactly against
the name in the breakpoint command. The parser will include template
parameters in the basename, so the exact match will always fail
**Testing**
* Added API tests
* Added unit-tests
Differential Revision: https://reviews.llvm.org/D135921
In D134378, we'll need the clang AST to be able to construct the qualified in some cases.
This makes logging in one place slightly less informative.
Reviewed By: dblaikie, Michael137
Differential Revision: https://reviews.llvm.org/D135979
Prior to this fix, no shared libraries would be loaded for a core file, even if they exist on the current machine. The issue was the DYLDRendezvous would read a DYLDRendezvous::Rendezvous from memory of the process in DYLDRendezvous::Resolve() which would read some ld.so structures as they existed in the middle of a process' lifetime. In core files we see, the DYLDRendezvous::Rendezvous::state would be set to eAdd for running processes. When ProcessELFCore.cpp would load the core file, it would call DynamicLoaderPOSIXDYLD::DidAttach(), which would call the above Rendezvous functions. The issue came when during the DidAttach function it call DYLDRendezvous::GetAction() which would return eNoAction if the DYLDRendezvous::m_current.state was read from memory as eAdd. This caused no shared libraries to be loaded for any ELF core files. We now detect if we have a core file and after reading the DYLDRendezvous::m_current.state from memory we set it to eConsistent, which causes DYLDRendezvous::GetAction() to return the correct action of eTakeSnapshot and shared libraries get loaded.
We also improve the DynamicLoaderPOSIXDYLD class to not try and set any breakpoints to catch shared library loads/unloads when we have a core file, which saves a bit of time.
Differential Revision: https://reviews.llvm.org/D134842
Fix a small thinko in https://reviews.llvm.org/D133534 . Normally
DynamicLoaderDarwinKernels are created via the CreateInstance plugin
method, and that plugin method sets the Process CanJIT to false.
In the above patch, I added a new code path that can call the
DynamicLoaderDarwinKernel ctor directly, without going through
CreateInstance, and CanJIT was not being correctly set for the
process.
rdar://101148552
Previously, lldb mistook fields in anonymous union in a struct as the direct
field of the struct, which causes lldb crashes due to multiple fields sharing
the same offset in a struct. This patch fixes it.
MSVC generated pdb doesn't have the debug info entity representing a anonymous
union in a struct. It looks like the following:
```
struct S {
union {
char c;
int i;
};
};
0x1004 | LF_FIELDLIST [size = 40]
- LF_MEMBER [name = `c`, Type = 0x0070 (char), offset = 0, attrs = public]
- LF_MEMBER [name = `i`, Type = 0x0074 (int), offset = 0, attrs = public]
0x1005 | LF_STRUCTURE [size = 32] `S`
unique name: `.?AUS@@`
vtable: <no type>, base list: <no type>, field list: 0x1004
```
Clang generated pdb is similar, though due to the [[ https://github.com/llvm/llvm-project/issues/57999 | bug ]],
it's not more useful than the debug info above. But that's not very relavent,
lldb should still be able to understand MSVC geneerated pdb.
```
0x1003 | LF_UNION [size = 60] `S::<unnamed-tag>`
unique name: `.?AT<unnamed-type-$S1>@S@@`
field list: <no type>
options: forward ref (= 0x1003) | has unique name | is nested, sizeof 0
0x1004 | LF_FIELDLIST [size = 40]
- LF_MEMBER [name = `c`, Type = 0x0070 (char), offset = 0, attrs = public]
- LF_MEMBER [name = `i`, Type = 0x0074 (int), offset = 0, attrs = public]
- LF_NESTTYPE [name = ``, parent = 0x1003]
0x1005 | LF_STRUCTURE [size = 32] `S`
unique name: `.?AUS@@`
vtable: <no type>, base list: <no type>, field list: 0x1004
options: contains nested class | has unique name, sizeof 4
0x1006 | LF_FIELDLIST [size = 28]
- LF_MEMBER [name = `c`, Type = 0x0070 (char), offset = 0, attrs = public]
- LF_MEMBER [name = `i`, Type = 0x0074 (int), offset = 0, attrs = public]
0x1007 | LF_UNION [size = 60] `S::<unnamed-tag>`
unique name: `.?AT<unnamed-type-$S1>@S@@`
field list: 0x1006
options: has unique name | is nested | sealed, sizeof
```
This patch delays the FieldDecl creation when travesing LF_FIELDLIST so we know
if there are multiple fields are in the same offsets and are able to group them
into different anonymous unions based on offsets. Nested anonymous union will
be flatten into one anonymous union, because we simply don't have that info, but
they are equivalent in terms of union layout.
Differential Revision: https://reviews.llvm.org/D134849
It's fine right now, but will break as soon as someone else declares a
PluginProperties class in the same way.
Also tighten up the scope of the anonymous namespaces surrounding the
other PluginProperties classes.
This change fixes two issues in ValueObject::GetExpressionPath method:
1. Accessing members of struct references used to produce expression
paths such as "str.&str.member" (instead of the expected
"str.member"). This is fixed by assigning the flag tha the child
value is a dereference when calling Dereference() on references
and adjusting logic in expression path creation.
2. If the parent of member access is dereference, the produced
expression path was "*(ptr).member". This is incorrect, since it
dereferences the member instead of the pointer. This is fixed by
wrapping dereference expression into parenthesis, resulting with
"(*ptr).member".
Reviewed By: werat, clayborg
Differential Revision: https://reviews.llvm.org/D132734
Making it easier to understand and harder to misuse.
This only applies to the ReadRegister(const RegisterInfo ®_info) variant.
Depends on D135671
Reviewed By: clayborg
Differential Revision: https://reviews.llvm.org/D135672
Familiar story, callers are either checking upfront that the pointer
wasn't null or not checking at all. SetValueFromData itself didn't
check either.
So make the parameter a ref and fixup the few places where a nullptr
check seems needed.
Depends on D135668
Reviewed By: clayborg
Differential Revision: https://reviews.llvm.org/D135670
All callers were either assuming their pointer was not null before calling
this, or checking beforehand.
Reviewed By: clayborg
Differential Revision: https://reviews.llvm.org/D135668
Most of the paths to this never passed nullptr intentionally. Those
that possibly could have were assuming it was not null elsehwere,
so would have crashed.
I've added asserts in those cases.
At least one case was relying on GetAsMemoryData to return an error
when it was given nullptr. So I've hoisted that error setting code
out into the caller.
Depends on D134963
Reviewed By: clayborg
Differential Revision: https://reviews.llvm.org/D134965
WriteRegister and WriteRegisterUnsigned were never pased nullptr,
and only one of them appeared to handle it. Switch to ref to make
the intent clear.
Depends on D134962
Reviewed By: clayborg
Differential Revision: https://reviews.llvm.org/D134963
ReadRegister and ReadRegisterAsUnsigned are always passed valid pointers,
so the parameter should be a ref to make the intent clear.
Reviewed By: clayborg
Differential Revision: https://reviews.llvm.org/D134962
The main aim of this patch is to delete the remaining instances of code
reaching into the internals of `TypeCategoryImpl`. I made the following
changes:
- Add some more methods to `TieredFormatterContainer` and
`TypeCategoryImpl` to expose functionality that is implemented in
`FormattersContainer`.
- Add new overloads of `TypeCategoryImpl::AddTypeXXX` to make it easier
to add formatters to categories without reaching into the internal
`FormattersContainer` objects.
- Remove the `GetTypeXXXContainer` and `GetRegexTypeXXXContainer`
accessors from `TypeCategoryImpl` and update all call sites to use the
new methods instead.
Differential Revision: https://reviews.llvm.org/D135399
In https://reviews.llvm.org/D133534 I made a little cleanup
to DynamicLoaderDarwinKernel::CreateInstance and unintentionally
changed the logic. Previously it would not create an instance
if there was a binary given to lldb and it was not a kernel.
With my change, the absence of any binary would also cause it
to not create. So connecting to a kernel without any binaries
would fail.
rdar://100985097
**Summary**
The primary motivation for this patch is to make sure we handle
the step-in behaviour for functions in the `std` namespace which
have an `auto` return type. Currently the default `step-avoid-regex`
setting is `^std::` but LLDB will still step into template functions
with `auto` return types in the `std` namespace.
**Details**
When we hit a breakpoint and check whether we should stop, we call
into `ThreadPlanStepInRange::FrameMatchesAvoidCriteria`. We then ask
for the frame function name via `SymbolContext::GetFunctionName(Mangled::ePreferDemangledWithoutArguments)`.
This ends up trying to parse the function name using `CPlusPlusLanguage::MethodName::GetBasename` which
parses the raw demangled name string.
`CPlusPlusNameParser::ParseFunctionImpl` calls `ConsumeTypename` to skip
the (in our case auto) return type of the demangled name (according to the
Itanium ABI this is a valid thing to encode into the mangled name). However,
`ConsumeTypename` doesn't strip out a plain `auto` identifier
(it will strip a `decltype(auto) return type though). So we are now left with
a basename that still has the return type in it, thus failing to match the `^std::`
regex.
Example frame where the return type is still part of the function name:
```
Process 1234 stopped
* thread #1, stop reason = step in
frame #0: 0x12345678 repro`auto std::test_return_auto<int>() at main.cpp:12:5
9
10 template <class>
11 auto test_return_auto() {
-> 12 return 42;
13 }
```
This is another case where the `CPlusPlusNameParser` breaks us in subtle ways
due to evolving C++ syntax. There are longer-term plans of replacing the hand-rolled
C++ parser with an alternative that uses the mangle tree API to do the parsing for us.
**Testing**
* Added API and unit-tests
* Adding support for ABI tags into the parser is a larger undertaking
which we would rather solve properly by using libcxxabi's mangle tree
parser
Differential Revision: https://reviews.llvm.org/D135413
Fixes#58135
Somehow lldb was able to print the member on its own but when we try
to print the whole type found by "image lookup -t" lldb would crash.
This is because we'd encoded the initial value of the member as an integer.
Which isn't the end of the world because bool is integral for C++.
However, clang has a special AST node to handle literal bool and it
expected us to use that instead.
This adds a new codepath to handle static bool which uses cxxBoolLiteralExpr
and we get the member printed as you'd expect.
For testing I added a struct with just the bool because trying to print
all of "A" crashes as well. Presumably because one of the other member's
types isn't handled properly either.
So for now I just added the bool case, we can merge it with A later.
Reviewed By: aeubanks
Differential Revision: https://reviews.llvm.org/D135169
Use our "rich error" facility to propagate error reported by the stub to
the user. lldb-server reports rich launch errors as of D133352.
To make this easier to implement, and reduce code duplication, I have
moved the vRun/A/qLaunchSuccess handling into a single
GDBRemoteCommunicationClient function.
Differential Revision: https://reviews.llvm.org/D134754
The old approach (dedicated ExecXXX for each instruction) is not flexible and results in duplicated code when RVC kicks in.
According to the spec, every compressed instruction can be decoded to a non-compressed one. So we can lower compressed instructions to instructions we already had, which requires a decoupling between the decoder and executor.
This patch:
- use llvm::Optional and its combinators AMAP.
- use template constraints on common instruction.
- make instructions strongly-typed (no uint32_t everywhere bc it is error-prone and burdens the developer when lowering the RVC) with the help of algebraic datatype (std::variant).
Note:
(NFC) because this is more of a refactoring in preparation for RVC.
Reviewed By: DavidSpickett
Differential Revision: https://reviews.llvm.org/D135015
The synchronous callbacks are not intended to start the target running
during the callback, and doing so is flakey. This patch converts them
to being regular async callbacks, and adds some testing for sequential
reports that have caused problems in the field.
Differential Revision: https://reviews.llvm.org/D134927
Move ReadPacketWithOutputSupport() from GDBRemoteCommunication
to GDBRemoteClientBase. This function is client-specific and moving
it there simplifies followup patches that split communication into
separate thread.
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.llvm.org/D135028
Profiles show that `DWARFUnit::ExtractUnitDIENoDwoIfNeeded` is both high firing (tens of thousands of calls) and fast running (15 µs mean).
Timers like this are noise and load for profiling systems, and can be removed.
rdar://100326595
Differential Revision: https://reviews.llvm.org/D134920
Profiles show that `SymbolFileDWARF::FindFunctions` is both high firing (many thousands of calls) and fast running (35 µs mean).
Timers like this are noise and load for profiling systems, and can be removed.
rdar://100326595
Differential Revision: https://reviews.llvm.org/D134922
This change fixes two issues in ValueObject::GetExpressionPath method:
1. Accessing members of struct references used to produce expression
paths such as "str.&str.member" (instead of the expected
"str.member"). This is fixed by assigning the flag tha the child
value is a dereference when calling Dereference() on references
and adjusting logic in expression path creation.
2. If the parent of member access is dereference, the produced
expression path was "*(ptr).member". This is incorrect, since it
dereferences the member instead of the pointer. This is fixed by
wrapping dereference expression into parenthesis, resulting with
"(*(ptr)).member".
Reviewed By: werat, clayborg
Differential Revision: https://reviews.llvm.org/D132734
In `ProcessWindows::OnDebuggerConnected` (triggered from
`CREATE_PROCESS_DEBUG_EVENT`), we should always call
`Target::SetExecutableModule` regardless of whether LLDB has already
preloaded the executable modules. `SetExecutableModule` has the side
effect of clearing the module list of the Target, which help make sure
that module #0 is the executable module and the rest of the modules are
listed according to the DLL load order in the process (technically this
has no real consequences but it seems to make more sense anyway.) It
also fixes an issue where the modules preloaded by LLDB will be
duplicated when the debuggee process actually loads the DLL.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D134636
Now that we display an error when users try to get variables, but something in the debug info is preventing variables from showing up, track this with a new bool in each module's statistic information named "debugInfoHadVariableErrors".
This patch modifies the code to track when we have variable errors in a module and adds accessors to get/set this value. This value is used in the module statistics and we added a test to verify this value gets set correctly.
Differential Revision: https://reviews.llvm.org/D134508
All callers have been converted to the optional version.
Depends on D134540
Reviewed By: clayborg
Differential Revision: https://reviews.llvm.org/D134541
