Fix return value of 'PluginManager::RegisterPlugin()'. (#114120)

[lldb] Make conversions from llvm::Error explicit with Status::FromEr… (#107163)

…ror() [NFC]

[lldb] Turn lldb_private::Status into a value type. (#106163)

This patch removes all of the Set.* methods from Status.

This cleanup is part of a series of patches that make it harder use the
ant

[lldb] Turn lldb_private::Status into a value type. (#106163)

This patch removes all of the Set.* methods from Status.

This cleanup is part of a series of patches that make it harder use the
anti-pattern of keeping a long-lives Status object around and updating
it while dropping any errors it contains on the floor.

This patch is largely NFC, the more interesting next steps this enables
is to:
1. remove Status.Clear()
2. assert that Status::operator=() never overwrites an error
3. remove Status::operator=()

Note that step (2) will bring 90% of the benefits for users, and step
(3) will dramatically clean up the error handling code in various
places. In the end my goal is to convert all APIs that are of the form

` ResultTy DoFoo(Status& error)
`
to

` llvm::Expected<ResultTy> DoFoo()
`
How to read this patch?

The interesting changes are in Status.h and Status.cpp, all other
changes are mostly

` perl -pi -e 's/\.SetErrorString/ = Status::FromErrorString/g' $(git
grep -l SetErrorString lldb/source)
`
plus the occasional manual cleanup.

show more ...

[LLDB] Reapply #100443 SBSaveCore Thread list (#104497)

Reapply #100443 and #101770. These were originally reverted due to a
test failure and an MSAN failure. I changed the test attribute to
restr

[LLDB] Reapply #100443 SBSaveCore Thread list (#104497)

Reapply #100443 and #101770. These were originally reverted due to a
test failure and an MSAN failure. I changed the test attribute to
restrict to x86 (following the other existing tests). I could not
reproduce the test or the MSAN failure and no repo steps were provided.

show more ...

Revert "[LLDB][SBSaveCore] Implement a selectable threadlist for Core… (#102018)

… Options. (#100443)"

This reverts commit 3e4af616334eae532f308605b89ff158dd195180.

@adrian-prantl FYI

Reve

Revert "[LLDB][SBSaveCore] Implement a selectable threadlist for Core… (#102018)

… Options. (#100443)"

This reverts commit 3e4af616334eae532f308605b89ff158dd195180.

@adrian-prantl FYI

Reverts #100443

show more ...

Revert "[LLDB][SBSaveCore] Fix bug where default values are not propagated. (#101770)"

This reverts commit 34766d0d488ba2fbefa80dcd0cc8720a0e753448 which
caused a msan failure, see comment https://g

Revert "[LLDB][SBSaveCore] Fix bug where default values are not propagated. (#101770)"

This reverts commit 34766d0d488ba2fbefa80dcd0cc8720a0e753448 which
caused a msan failure, see comment https://github.com/llvm/llvm-project/pull/101770#issuecomment-2268373325 for details.

show more ...

[LLDB][SBSaveCore] Fix bug where default values are not propagated. (#101770)

In #100443, Mach-o and Minidump now only call process API's that take a
`SaveCoreOption` as the container for the style

[LLDB][SBSaveCore] Fix bug where default values are not propagated. (#101770)

In #100443, Mach-o and Minidump now only call process API's that take a
`SaveCoreOption` as the container for the style and information if a
thread should be included in the core or not. This introduced a bug
where in subsequent method calls we were not honoring the defaults of
both implementations.

~~To solve this I have made a copy of each SaveCoreOptions that is
mutable by the respective plugin. Originally I wanted to leave the
SaveCoreOptions as non const so these default value mutations could be
shown back to the user. Changing that behavior is outside of the scope
of this bugfix, but is context for why we are making a copy.~~

Removed const on the savecoreoptions so defaults can be inspected by the
user

CC: @Michael137

show more ...

[LLDB][SBSaveCore] Implement a selectable threadlist for Core Options. (#100443)

In #98403 I enabled the SBSaveCoreOptions object, which allows users via
the scripting API to define what they want

[LLDB][SBSaveCore] Implement a selectable threadlist for Core Options. (#100443)

In #98403 I enabled the SBSaveCoreOptions object, which allows users via
the scripting API to define what they want saved into their core file.
As the first option I've added a threadlist, so users can scan and
identify which threads and corresponding stacks they want to save.

In order to support this, I had to add a new method to `Process.h` on
how we identify which threads are to be saved, and I had to change the
book keeping in minidump to ensure we don't double save the stacks.

Important to @jasonmolenda I also changed the MachO coredump to accept
these new APIs.

show more ...

[lldb/Commands] Add `scripting template list` command with auto discovery

This patch introduces a new `template` multiword sub-command to the
`scripting` top-level command. As the name suggests, thi

[lldb/Commands] Add `scripting template list` command with auto discovery

This patch introduces a new `template` multiword sub-command to the
`scripting` top-level command. As the name suggests, this sub-command
operates on scripting templates, and currently has the ability to
automatically discover the various scripting extensions that lldb
supports.

This was previously reviewed in #97273.

Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>

show more ...

[lldb] Revert scripting template list patches (#100673)

Reverts https://github.com/llvm/llvm-project/pull/97273 since it broke
the windows bot:

https://lab.llvm.org/buildbot/#/builders/141/build

[lldb] Revert scripting template list patches (#100673)

Reverts https://github.com/llvm/llvm-project/pull/97273 since it broke
the windows bot:

https://lab.llvm.org/buildbot/#/builders/141/builds/1025/steps/4/logs/stdio

show more ...

[lldb/Commands] Add `scripting template list` command with auto discovery

This patch introduces a new `template` multiword sub-command to the
`scripting` top-level command. As the name suggests, thi

[lldb/Commands] Add `scripting template list` command with auto discovery

This patch introduces a new `template` multiword sub-command to the
`scripting` top-level command. As the name suggests, this sub-command
operates on scripting templates, and currently has the ability to
automatically discover the various scripting extensions that lldb
supports.

This was previously reviewed in #97273.

Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>

show more ...

Revert "[lldb/Commands] Add `scripting template list` command with auto discovery" (#100273)

Reverts llvm/llvm-project#97273 since it broke the windows bot:

https://lab.llvm.org/buildbot/#/builde

Revert "[lldb/Commands] Add `scripting template list` command with auto discovery" (#100273)

Reverts llvm/llvm-project#97273 since it broke the windows bot:

https://lab.llvm.org/buildbot/#/builders/141/builds/1025/steps/4/logs/stdio

show more ...

[lldb/Commands] Add `scripting template list` command with auto discovery (#97273)

This patch introduces a new `template` multiword sub-command to the
`scripting` top-level command. As the name sug

[lldb/Commands] Add `scripting template list` command with auto discovery (#97273)

This patch introduces a new `template` multiword sub-command to the
`scripting` top-level command. As the name suggests, this sub-command
operates on scripting templates, and currently has the ability to
automatically discover the various scripting extensions that lldb
supports.

Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>

show more ...

[LLDB][SaveCore] Add SBSaveCoreOptions Object, and SBProcess::SaveCore() overload (#98403)

This PR adds `SBSaveCoreOptions`, which is a container class for options
when LLDB is taking coredumps. Fo

[LLDB][SaveCore] Add SBSaveCoreOptions Object, and SBProcess::SaveCore() overload (#98403)

This PR adds `SBSaveCoreOptions`, which is a container class for options
when LLDB is taking coredumps. For this first iteration this container
just keeps parity with the extant API of `file, style, plugin`. In the
future this options object can be extended to allow users to take a
subset of their core dumps.

show more ...

[lldb] Use StringRef::{starts,ends}_with (NFC)

This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,end

[lldb] Use StringRef::{starts,ends}_with (NFC)

This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,ends}_with in C++20.

I'm planning to deprecate and eventually remove
StringRef::{starts,ends}with.

show more ...

DEBUGINFOD based DWP acquisition for LLDB (#70996)

I've plumbed the LLVM DebugInfoD client into LLDB, and added automatic
downloading of DWP files to the SymbolFileDWARF.cpp plugin. If you have
DE

DEBUGINFOD based DWP acquisition for LLDB (#70996)

I've plumbed the LLVM DebugInfoD client into LLDB, and added automatic
downloading of DWP files to the SymbolFileDWARF.cpp plugin. If you have
DEBUGINFOD_URLS set to a space delimited set of web servers, LLDB will
try to use them as a last resort when searching for DWP files. If you do
*not* have that environment variable set, nothing should be changed.
There's also a setting, per @clayborg 's suggestion, that will override
the environment variable, or can be used instead of the environment
variable. The setting is why I also needed to add an API to the
llvm-debuginfod library

### Test Plan:

Suggestions are welcome here. I should probably have some positive and
negative tests, but I wanted to get the diff up for people who have a
clue what they're doing to rip it to pieces before spending too much
time validating the initial implementation.

---------

Co-authored-by: Kevin Frei <freik@meta.com>
Co-authored-by: Alex Langford <nirvashtzero@gmail.com>

show more ...

[lldb] Move DownloadObjectAndSymbolFile to SymbolLocator plugin (#71267)

This builds on top of the work started in c3a302d to convert
LocateSymbolFile to a SymbolLocator plugin. This commit moves

[lldb] Move DownloadObjectAndSymbolFile to SymbolLocator plugin (#71267)

This builds on top of the work started in c3a302d to convert
LocateSymbolFile to a SymbolLocator plugin. This commit moves
DownloadObjectAndSymbolFile.

show more ...

[lldb] Move LocateExecutableSymbolFile to SymbolLocator plugin (#71266)

This builds on top of the work started in c3a302d to convert
LocateSymbolFile to a SymbolLocator plugin. This commit moves
L

[lldb] Move LocateExecutableSymbolFile to SymbolLocator plugin (#71266)

This builds on top of the work started in c3a302d to convert
LocateSymbolFile to a SymbolLocator plugin. This commit moves
LocateExecutableSymbolFile.

show more ...

[lldb] Move FindSymbolFileInBundle to SymbolLocator plugin (#71247)

This builds on top of the work started in c3a302d to convert
LocateSymbolFile to a SymbolLocator plugin. This commit moves
FindS

[lldb] Move FindSymbolFileInBundle to SymbolLocator plugin (#71247)

This builds on top of the work started in c3a302d to convert
LocateSymbolFile to a SymbolLocator plugin. This commit moves
FindSymbolFileInBundle.

show more ...

[lldb] Convert LocateSymbolFile into a plugin (#71151)

This commit contains the initial scaffolding to convert the
functionality currently implemented in LocateSymbolFile to a plugin
a

[lldb] Convert LocateSymbolFile into a plugin (#71151)

This commit contains the initial scaffolding to convert the
functionality currently implemented in LocateSymbolFile to a plugin
architecture. The plugin approach allows us to easily add new ways to
find symbols and fixes some issues with the current implementation.

For instance, currently we (ab)use the host OS to include support for
querying the DebugSymbols framework on macOS. The plugin approach
retains all the benefits (including the ability to compile this out on
other platforms) while maintaining a higher level of separation with the
platform independent code.

To limit the scope of this patch, I've only converted a single function:
LocateExecutableObjectFile. Future commits will convert the remaining
LocateSymbolFile functions and eventually remove LocateSymbolFile. To
make reviewing easier, that will done as follow-ups.

show more ...

[lldb][NFCI] Remove use of ConstString from PluginManager

The underlying structures no longer use ConstString so we can remove it
wholesale from PluginManager now.

Differential Revision: https://re

[lldb][NFCI] Remove use of ConstString from PluginManager

The underlying structures no longer use ConstString so we can remove it
wholesale from PluginManager now.

Differential Revision: https://reviews.llvm.org/D153818

show more ...

[lldb][NFCI] Remove unneeded ConstString constructions for OptionValueProperties::AppendProperty

I removed ConstString from OptionValueProperties in 643ba926c1f6, but
there are a few call sites that

[lldb][NFCI] Remove unneeded ConstString constructions for OptionValueProperties::AppendProperty

I removed ConstString from OptionValueProperties in 643ba926c1f6, but
there are a few call sites that still create a ConstString as an
argument. I did not catch these initially because ConstString has an
implicit conversion method to StringRef.

Differential Revision: https://reviews.llvm.org/D153673

show more ...

[lldb] Change setting descriptions to use StringRef instead of ConstString

These probably do not need to be in the ConstString StringPool as they
don't really need any of the advantages that ConstSt

[lldb] Change setting descriptions to use StringRef instead of ConstString

These probably do not need to be in the ConstString StringPool as they
don't really need any of the advantages that ConstStrings offer.
Lifetime for these things is always static and we never need to perform
comparisons for setting descriptions.

Differential Revision: https://reviews.llvm.org/D148679

show more ...

[lldb] Show register fields using bitfield struct types

This change uses the information from target.xml sent by
the GDB stub to produce C types that we can use to print
register fields.

lldb-serve

[lldb] Show register fields using bitfield struct types

This change uses the information from target.xml sent by
the GDB stub to produce C types that we can use to print
register fields.

lldb-server *does not* produce this information yet. This will
only work with GDB stubs that do. gdbserver or qemu
are 2 I know of. Testing is added that uses a mocked lldb-server.
```
(lldb) register read cpsr x0 fpcr fpsr x1
cpsr = 0x60001000
= (N = 0, Z = 1, C = 1, V = 0, TCO = 0, DIT = 0, UAO = 0, PAN = 0, SS = 0, IL = 0, SSBS = 1, BTYPE = 0, D = 0, A = 0, I = 0, F = 0, nRW = 0, EL = 0, SP = 0)
```

Only "register read" will display fields, and only when
we are not printing a register block.

For example, cpsr is a 32 bit register. Using the target's scratch type
system we construct a type:
```
struct __attribute__((__packed__)) cpsr {
uint32_t N : 1;
uint32_t Z : 1;
...
uint32_t EL : 2;
uint32_t SP : 1;
};
```

If this register had unallocated bits in it, those would
have been filled in by RegisterFlags as anonymous fields.
A new option "SetChildPrintingDecider" is added so we
can disable printing those.

Important things about this type:
* It is packed so that sizeof(struct cpsr) == sizeof(the real register).
(this will hold for all flags types we create)
* Each field has the same storage type, which is the same as the type
of the raw register value. This prevents fields being spilt over
into more storage units, as is allowed by most ABIs.
* Each bitfield size matches that of its register field.
* The most significant field is first.

The last point is required because the most significant bit (MSB)
being on the left/top of a print out matches what you'd expect to
see in an architecture manual. In addition, having lldb print a
different field order on big/little endian hosts is not acceptable.

As a consequence, if the target is little endian we have to
reverse the order of the fields in the value. The value of each field
remains the same. For example 0b01 doesn't become 0b10, it just shifts
up or down.

This is needed because clang's type system assumes that for a struct
like the one above, the least significant bit (LSB) will be first
for a little endian target. We need the MSB to be first.

Finally, if lldb's host is a different endian to the target we have
to byte swap the host endian value to match the endian of the target's
typesystem.

| Host Endian | Target Endian | Field Order Swap | Byte Order Swap |
|-------------|---------------|------------------|-----------------|
| Little | Little | Yes | No |
| Big | Little | Yes | Yes |
| Little | Big | No | Yes |
| Big | Big | No | No |

Testing was done as follows:
* Little -> Little
* LE AArch64 native debug.
* Big -> Little
* s390x lldb running under QEMU, connected to LE AArch64 target.
* Little -> Big
* LE AArch64 lldb connected to QEMU's GDB stub, which is running
an s390x program.
* Big -> Big
* s390x lldb running under QEMU, connected to another QEMU's GDB
stub, which is running an s390x program.

As we are not allowed to link core code to plugins directly,
I have added a new plugin RegisterTypeBuilder. There is one implementation
of this, RegisterTypeBuilderClang, which uses TypeSystemClang to build
the CompilerType from the register fields.

Reviewed By: jasonmolenda

Differential Revision: https://reviews.llvm.org/D145580

show more ...

[trace][intel pt] Simple detection of infinite decoding loops

The low-level decoder might fall into an infinite decoding loop for
various reasons, the simplest being an infinite direct loop reached

[trace][intel pt] Simple detection of infinite decoding loops

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

show more ...