[lldb][NFC] Make the target's SectionLoadList private. (#113278)

Lots of code around LLDB was directly accessing the target's section
load list. This NFC patch makes the section load list private s

[lldb][NFC] Make the target's SectionLoadList private. (#113278)

Lots of code around LLDB was directly accessing the target's section
load list. This NFC patch makes the section load list private so the
Target class can access it, but everyone else now uses accessor
functions. This allows us to control the resolving of addresses and will
allow for functionality in LLDB which can lazily resolve addresses in
JIT plug-ins with a future patch.

show more ...

Start to clean up the process of defining command arguments. (#83097)

Partly, there's just a lot of unnecessary boiler plate. It's also
possible to define combinations of arguments that make no sen

Start to clean up the process of defining command arguments. (#83097)

Partly, there's just a lot of unnecessary boiler plate. It's also
possible to define combinations of arguments that make no sense (e.g.
eArgRepeatPlus followed by eArgRepeatPlain...) but these are never
checked since we just push_back directly into the argument definitions.

This commit is step 1 of this cleanup - do the obvious stuff. In it, all
the simple homogenous argument lists and the breakpoint/watchpoint
ID/Range types, are set with common functions. This is an NFC change, it
just centralizes boiler plate. There's no checking yet because you can't
get a single argument wrong.

The end goal is that all argument definition goes through functions and
m_arguments is hidden so that you can't define inconsistent argument
sets.

show more ...

Add the RegisterCompleter to eArgTypeRegisterName in g_argument_table (#82428)

This is a follow-on to:

https://github.com/llvm/llvm-project/pull/82085

The completer for register names was miss

Add the RegisterCompleter to eArgTypeRegisterName in g_argument_table (#82428)

This is a follow-on to:

https://github.com/llvm/llvm-project/pull/82085

The completer for register names was missing from the argument table. I
somehow missed that the only register completer test was x86_64, so that
test broke.

I added the completer in to the right slot in the argument table, and
added a small completions test that just uses the alias register names.
If we end up having a platform that doesn't define register names, we'll
have to skip this test there, but it should add a sniff test for
register completion that will run most everywhere.

show more ...

Revert "Centralize the handling of completion for simple argument lists. (#82085)"

This reverts commit 21631494b068d9364b8dc8f18e59adee9131a0a5.

Reverted because of greendragon failure:

**********

Revert "Centralize the handling of completion for simple argument lists. (#82085)"

This reverts commit 21631494b068d9364b8dc8f18e59adee9131a0a5.

Reverted because of greendragon failure:

******************** TEST 'lldb-api :: functionalities/completion/TestCompletion.py' FAILED ********************
Script:

show more ...

Centralize the handling of completion for simple argument lists. (#82085)

Most commands were adding argument completion handling by themselves,
resulting in a lot of unnecessary boilerplate. In man

Centralize the handling of completion for simple argument lists. (#82085)

Most commands were adding argument completion handling by themselves,
resulting in a lot of unnecessary boilerplate. In many cases, this could
be done generically given the argument definition and the entries in the
g_argument_table.

I'm going to address this in a couple passes. In this first pass, I
added handling of commands that have only one argument list, with one
argument type, either single or repeated, and changed all the commands
that are of this sort (and don't have other bits of business in their
completers.)

I also added some missing connections between arg types and completions
to the table, and added a RemoteFilename and RemotePath to use in places
where we were using the Remote completers. Those arguments used to say
they were "files" but they were in fact remote files.

I also added a module arg type to use where we were using the module
completer. In that case, we should call the argument module.

show more ...

[lldb] Part 2 of 2 - Refactor `CommandObject::DoExecute(...)` return `void` (not `bool`) (#69991)

[lldb] Part 2 of 2 - Refactor `CommandObject::DoExecute(...)` to return
`void` instead of ~~`bool`~

[lldb] Part 2 of 2 - Refactor `CommandObject::DoExecute(...)` return `void` (not `bool`) (#69991)

[lldb] Part 2 of 2 - Refactor `CommandObject::DoExecute(...)` to return
`void` instead of ~~`bool`~~

Justifications:
- The code doesn't ultimately apply the `true`/`false` return values.
- The methods already pass around a `CommandReturnObject`, typically
with a `result` parameter.
- Each command return object already contains:
- A more precise status
- The error code(s) that apply to that status

Part 1 refactors the `CommandObject::Execute(...)` method.
- See
[https://github.com/llvm/llvm-project/pull/69989](https://github.com/llvm/llvm-project/pull/69989)

rdar://117378957

show more ...

[lldb] Require paused process and frame for "register info" command (#67124)

Prior to this the command would simply crash when run on a running
process.

Of the three register commands, "info" wa

[lldb] Require paused process and frame for "register info" command (#67124)

Prior to this the command would simply crash when run on a running
process.

Of the three register commands, "info" was the only one missing these
requirements. On some level it makes sense because you're not going to
read a value or modify anything, but practically I think lldb assumes
any time you're going to access register related stuff, the process
should be paused.

I noticed this debugging with a remote gdb stub, so I've recreated that
scenario using attach in a new test case.

show more ...

[lldb] Add register field tables to the "register info" command

This teaches DumpRegisterInfo to generate a table from the register
flags type. It just calls a method on RegisterFlags.

As such, the

[lldb] Add register field tables to the "register info" command

This teaches DumpRegisterInfo to generate a table from the register
flags type. It just calls a method on RegisterFlags.

As such, the extra tests are minimal and only show that the intergration
works. Exhaustive formatting tests are done with RegisterFlags itself.

Example:
```
(lldb) register info cpsr
Name: cpsr
Size: 4 bytes (32 bits)
In sets: general (index 0)

| 31 | 30 | 29 | 28 | 27-26 | 25 | 24 | 23 | 22 | 21 | 20 | 19-13 | 12 | 11-10 | 9 | 8 | 7 | 6 | 5 | 4 | 3-2 | 1 | 0 |
|----|----|----|----|-------|-----|-----|-----|-----|----|----|-------|------|-------|---|---|---|---|---|-----|-----|---|----|
| N | Z | C | V | | TCO | DIT | UAO | PAN | SS | IL | | SSBS | | D | A | I | F | | nRW | EL | | SP |
```

LLDB limits the max terminal width to 80 chars by default.
So to get that full width output you will need to change the "term-width"
setting to something higher.

Reviewed By: jasonmolenda

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

show more ...

[lldb] Add "register info" command

This adds a new command that will show all the information lldb
knows about a register.
```
(lldb) register info s0
Name: s0
Size: 4 bytes (32 bits)

[lldb] Add "register info" command

This adds a new command that will show all the information lldb
knows about a register.
```
(lldb) register info s0
Name: s0
Size: 4 bytes (32 bits)
Invalidates: v0, d0
Read from: v0
In sets: Floating Point Registers (index 1)
```

Currently it only allows a single register, and we get the
information from the RegisterInfo structure.

For those of us who know the architecture well, this information
is all pretty obvious. For those who don't, it's nice to have it
at a glance without leaving the debugger.

I hope to have more in depth information to show here in the future,
which will be of wider use.

Reviewed By: jasonmolenda

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

show more ...

[lldb/Commands] Add support to auto-completion for user commands

This patch should allow the user to set specific auto-completion type
for their custom commands.

To do so, we had to hoist the `Comp

[lldb/Commands] Add support to auto-completion for user commands

This patch should allow the user to set specific auto-completion type
for their custom commands.

To do so, we had to hoist the `CompletionType` enum so the user can
access it and add a new completion type flag to the CommandScriptAdd
Command Object.

So now, the user can specify which completion type will be used with
their custom command, when they register it.

This also makes the `crashlog` custom commands use disk-file completion
type, to browse through the user file system and load the report.

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

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

show more ...

[lldb] Complete OptionValue cleanup (NFC)

Make the `Get.*Value` and `Set.*Value` function private and migrate the
last remaining call sites to the new overloaded/templated functions.

[lldb] Refactor OptionValue to return a std::optional (NFC)

Refactor OptionValue to return a std::optional instead of taking a fail
value. This allows the caller to handle situations where there's n

[lldb] Refactor OptionValue to return a std::optional (NFC)

Refactor OptionValue to return a std::optional instead of taking a fail
value. This allows the caller to handle situations where there's no
value, instead of being unable to distinguish between the absence of a
value and the value happening the match the fail value. When a fail
value is required, std::optional::value_or() provides the same
functionality.

show more ...

[LLDB] Don't print register fields when asked for a specific format

Previously if a register had fields we would always print them after the
value if the register was asked for by name.
```
(lldb) r

[LLDB] Don't print register fields when asked for a specific format

Previously if a register had fields we would always print them after the
value if the register was asked for by name.
```
(lldb) register read MDCR_EL3
MDCR_EL3 = 0x00000000
= {
ETBAD = 0
<...>
RLTE = 0
}
```
This can be quite annoying if there are a whole lot of fields but you
want to see the register in a specific format.
```
(lldb) register read MDCR_EL3 -f i
MDCR_EL3 = 0x00000000 unknown udf #0x0
= {
ETBAD = 0
<...lots of fields...>
```
Since it pushes the interesting bit far up the terminal. To solve this,
don't print fields if the user passes --format. If they're doing that
then I think it's reasonable to assume they know what they want and only
want to see that output.

This also gives users a way to silence fields, but not change the format.
By doing `register read foo -f x`. In case they are not useful or perhaps
they are trying to work around a crash.

I have customised the help text for --format for register read to explain this:
```
-f <format> ( --format <format> )
Specify a format to be used for display. If this is set, register fields will not be dispayed.
```

Reviewed By: jasonmolenda

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

show more ...

[lldb] Change some pointers to refs in register printing code

No one was passing nullptr for these.

Reviewed By: JDevlieghere

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

[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 ...

Move from llvm::makeArrayRef to ArrayRef deduction guides - last part

This is a follow-up to https://reviews.llvm.org/D140896, split into
several parts as it touches a lot of files.

Differential Re

Move from llvm::makeArrayRef to ArrayRef deduction guides - last part

This is a follow-up to https://reviews.llvm.org/D140896, split into
several parts as it touches a lot of files.

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

show more ...

[lldb] Always use APFloat for FP dumping

The DumpDataExtractor function had two branches for printing floating
point values. One branch (APFloat) was used if we had a Target object
around and could

[lldb] Always use APFloat for FP dumping

The DumpDataExtractor function had two branches for printing floating
point values. One branch (APFloat) was used if we had a Target object
around and could query it for the appropriate semantics. If we didn't
have a Target, we used host operations to read and format the value.

This patch changes second path to use APFloat as well. To make it work,
I pick reasonable defaults for different byte size. Notably, I did not
include x87 long double in that list (as it is ambibuous and
architecture-specific). This exposed a bug where we were printing
register values using the target-less branch, even though the registers
definitely belong to a target, and we had it available. Fixing this
prompted the update of several tests for register values due to slightly
different floating point outputs.

The most dubious aspect of this patch is the change in
TypeSystemClang::GetFloatTypeSemantics to recognize `10` as a valid size
for x87 long double. This was necessary because because sizeof(long
double) on x86_64 is 16 even though it only holds 10 bytes of useful
data. This generalizes the hackaround present in the target-free branch
of the dumping function.

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

show more ...

[lldb] Refactor command option enum values (NFC)

Refactor the command option enum values and the command argument table
to connect the two. This has two benefits:

- We guarantee that two options t

[lldb] Refactor command option enum values (NFC)

Refactor the command option enum values and the command argument table
to connect the two. This has two benefits:

- We guarantee that two options that use the same argument type have
the same accepted values.
- We can print the enum values and their description in the help
output. (D129707)

Differential revision: https://reviews.llvm.org/D129703

show more ...

[Commands] Remove redundant member initialization (NFC)

Identified with readability-redundant-member-init.

[lldb] Remove redundant calls to set eReturnStatusFailed

This is part 2, covering the commands source.

Some uses remain where it's tricky to see what the
logic is or they are not used with AppendEr

[lldb] Remove redundant calls to set eReturnStatusFailed

This is part 2, covering the commands source.

Some uses remain where it's tricky to see what the
logic is or they are not used with AppendError.

Reviewed By: teemperor

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

show more ...

tab completion for register read/write

Summary:
1. Created a new common completion for the registers of the current context;
2. Apply this new common completion to the commands register read/write;

tab completion for register read/write

Summary:
1. Created a new common completion for the registers of the current context;
2. Apply this new common completion to the commands register read/write;
3. Unit test.

Reviewers: teemperor, JDevlieghere

Reviewed By: teemperor

Tags: #lldb

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

show more ...

[lldb][NFC] Fix all formatting errors in .cpp file headers

Summary:
A *.cpp file header in LLDB (and in LLDB) should like this:
```
//===-- TestUtilities.cpp ----------------------------------------

[lldb][NFC] Fix all formatting errors in .cpp file headers

Summary:
A *.cpp file header in LLDB (and in LLDB) should like this:
```
//===-- TestUtilities.cpp -------------------------------------------------===//
```
However in LLDB most of our source files have arbitrary changes to this format and
these changes are spreading through LLDB as folks usually just use the existing
source files as templates for their new files (most notably the unnecessary
editor language indicator `-*- C++ -*-` is spreading and in every review
someone is pointing out that this is wrong, resulting in people pointing out that this
is done in the same way in other files).

This patch removes most of these inconsistencies including the editor language indicators,
all the different missing/additional '-' characters, files that center the file name, missing
trailing `===//` (mostly caused by clang-format breaking the line).

Reviewers: aprantl, espindola, jfb, shafik, JDevlieghere

Reviewed By: JDevlieghere

Subscribers: dexonsmith, wuzish, emaste, sdardis, nemanjai, kbarton, MaskRay, atanasyan, arphaman, jfb, abidh, jsji, JDevlieghere, usaxena95, lldb-commits

Tags: #lldb

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

show more ...

[lldb][NFC] Remove unnecessary includes in source/Commands

Summary: This removes most of unnecessary includes in the `source/Commands` directory. This was generated by IWYU and a script that fixed a

[lldb][NFC] Remove unnecessary includes in source/Commands

Summary: This removes most of unnecessary includes in the `source/Commands` directory. This was generated by IWYU and a script that fixed all the bogus reports from IWYU. Patch is tested on Linux and macOS.

Reviewers: JDevlieghere

Reviewed By: JDevlieghere

Subscribers: krytarowski, lldb-commits

Tags: #lldb

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

show more ...

[lldb][NFC] Remove ArgEntry::ref member

The StringRef should always be identical to the C string, so we
might as well just create the StringRef from the C-string. This
might be slightly slower until

[lldb][NFC] Remove ArgEntry::ref member

The StringRef should always be identical to the C string, so we
might as well just create the StringRef from the C-string. This
might be slightly slower until we implement the storage of ArgEntry
with a string instead of a std::unique_ptr<char[]>. Until then we
have to do the additional strlen on the C string to construct the
StringRef.

llvm-svn: 371842

show more ...

[lldb][NFC] Remove dead code that is supposed to handle invalid command options

Summary:
We currently have a bunch of code that is supposed to handle invalid command options, but
all this code is un

[lldb][NFC] Remove dead code that is supposed to handle invalid command options

Summary:
We currently have a bunch of code that is supposed to handle invalid command options, but
all this code is unreachable because invalid options are already handled in `Options::Parse`.
The only way we can reach this code is when we declare but then not implement an option
(which will be made impossible with D65386, which is also when we can completely remove
the `default` cases).

This patch replaces all this code with `llvm_unreachable` to make clear this is dead code
that can't be reached.

Reviewers: JDevlieghere

Reviewed By: JDevlieghere

Subscribers: lldb-commits

Tags: #lldb

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

llvm-svn: 369625

show more ...