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.
The functionality is fine (we don't run the breakpoint command twice), but this test forgot to call `FileCheck` and isn't checking the same value isn't there twice..
This documentation patch adds information to allow remote users to also use the plugin as it will be invisible to them using the current instructions. It solves issue #58252.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D135577
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
lldb-vscode is hard-coded to source .lldbinit file which causes some tests to
fail on my machine.
This patch adds a new option to control this:
1. vscode.py and lldb-vscode tests will not source .lldbinit by default
2. lldb-vscode will source .lldbinit in production if not specified otherwise
Differential Revision: https://reviews.llvm.org/D135620
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
Previously we had a bit of a mix of "signed char" "unsigned char" and
"char".
This adds seperate min and max checks for all three types.
Depends on D135170
Reviewed By: Michael137
Differential Revision: https://reviews.llvm.org/D135352
This is useful for answering the question "where am I?" and is surprisingly
difficult to figure out without just doing another step command.
Reviewed By: awarzynski
Differential Revision: https://reviews.llvm.org/D134873
As with static bool for whatever reason printing them on their own
worked fine but wasn't handled when you printed the whole type.
I don't see a good way to test this from clang's side so our existing
tests will have to do.
We can now print all of the struct "A", so there's no need for a separate
one for static bool testing. I've not checked the output, just that it
succeeds. This saves us having to handle different min/max between systems.
Depends on D135169
Reviewed By: aeubanks, shafik
Differential Revision: https://reviews.llvm.org/D135170
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
This patch had to be reverted because on gcc 7.5.0 we see an error converting from std::unique_ptr<MCRegisterInfo> to Expected<std::unique_ptr<MCRegisterInfo>> as the return type for the function createRegInfo. This has now been fixed.
When adding a new synthetic child provider, we check for an existing
conflicting filter in the same category (and vice versa). This is done
by trying to match the new type name against registered formatters.
However, the new type name we're registered can also be a regex
(`type synth add -x`), and in this case the conflict check is just
wrong: it will try to match the new regex as if it was a type name,
against previously registered regexes.
See https://github.com/llvm/llvm-project/issues/57947 for a longer
explanation with concrete examples of incorrect behavior.
Differential Revision: https://reviews.llvm.org/D134570
The callback system to iterate over every formatter of a given kind in
a TypeCategoryImpl is only used in one place (the implementation of
`type {formatter_kind} list`), and it's too convoluted for the sake of
unused flexibility.
This change changes it so that only one callback is passed to `ForEach`
(instead of a callback for exact matches and another one for regex
matches), and moves the iteration logic to `TieredFormatterContainer`
to avoid duplication.
If in the future we need different logic in the callback depending on
exact/regex match, the callback can get the type of formatter matching
used from the TypeMatcher argument anyway.
Differential Revision: https://reviews.llvm.org/D134771
The call to `set_target_properties` should use the target passed to
`add_lldb_library` instead of a hard-coded value. Upstream `liblldb` is
the only target for which this matters, but downstream we have
LLDBRPC.framework which needs this as well.
This ensures it is run regardless of the method we use to initiate the
session (previous version did not handle connects), and it is the same
place that is used for resetting watchpoints.
Differential Revision: https://reviews.llvm.org/D134882
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
These tests have begun failing starting with commit
`69a6417406a1b0316a1fa6aeb63339d0e1d2abbd`, which
added a new `import` to `ASTNodeImporter::VisitTypedefType`.
This trips an assertion in following way:
1. When creating a persistent variable for the result we call `CopyType`
(in `DeportType`) under a `CompleteTagDeclsScope` (which is supposed to complete all
decls newly imported in the `CopyType` call).
2. During `CopyType` we call `ASTNodeImporter::VisitTypedefType`
3. This now has a second import call on the desugared type
4. In `ASTImporterDelegate::ImportImpl` we will now try to import a decl
that we originally got from the `std` module (which means it has no valid origin).
But since we’re doing this under a CompleteTagDeclsScope, the
`NewDeclListener::NewDeclImported` adds the decl to the list of decls to
complete after the `CopyType` call. But this list shouldn’t contain decls
with invalid origins because we assert this in `~CompleteTagDeclsScope`, which
is where the tests crash.
We suspect that we previously didn’t see this assert trigger because by the time
we create the result variable we are using an AST whose decls all have
a valid debug-info origin (constructed with the help of the std module).
So we never expected decls from modules to be imported under
`CompleteTagDeclsScope` without a m_sema available (which is the case by
the time we get to `DeportType`). Since there is no `m_sema` available,
`CxxModuleHandler::Import` trivially returns and the decls don’t get added
to the `m_decls_to_ignore` list and count as "newly imported decls".
Skip this test for now until we have a fix or the origin tracking gets
refactored (see https://reviews.llvm.org/D101950).
Differential Revision: https://reviews.llvm.org/D135178
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
After recent diffs that enable variable errors that stop variables from being correctly displayed when debugging, allow users to see these errors in the LOCALS variables in the VS Code UI. We do this by detecting when no variables are available and when there is an error to be displayed, and we add a single variable named "<error>" whose value is a string error that the user can read. This allows the user to be aware of the reason variables are not available and fix the issue. Previously if someone enabled "-gline-tables-only" or was debugging with DWARF in .o files or with .dwo files and those separate object files were missing or they were out of date, the user would see nothing in the variables view. Communicating these errors to the user is essential to a good debugging experience.
Differential Revision: https://reviews.llvm.org/D134333
Pavel Labath