<feed xmlns='http://www.w3.org/2005/Atom'>
<title>llvm-project.git/lldb/source/Commands/CommandObjectRegister.cpp, branch main</title>
<subtitle>Unnamed repository; edit this file 'description' to name the repository.
</subtitle>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/'/>
<entry>
<title>[lldb][NFC] Make the target's SectionLoadList private. (#113278)</title>
<updated>2025-01-15T04:12:46+00:00</updated>
<author>
<name>Greg Clayton</name>
<email>gclayton@fb.com</email>
</author>
<published>2025-01-15T04:12:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=c4fb7180cbbe977f1ab1ce945a691550f8fdd1fb'/>
<id>c4fb7180cbbe977f1ab1ce945a691550f8fdd1fb</id>
<content type='text'>
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.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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.</pre>
</div>
</content>
</entry>
<entry>
<title>Start to clean up the process of defining command arguments. (#83097)</title>
<updated>2024-02-27T18:34:01+00:00</updated>
<author>
<name>jimingham</name>
<email>jingham@apple.com</email>
</author>
<published>2024-02-27T18:34:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=2d704f4bf2edb0f9343dac818ab4d29442be9968'/>
<id>2d704f4bf2edb0f9343dac818ab4d29442be9968</id>
<content type='text'>
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.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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.</pre>
</div>
</content>
</entry>
<entry>
<title>Add the RegisterCompleter to eArgTypeRegisterName in g_argument_table (#82428)</title>
<updated>2024-02-20T22:18:03+00:00</updated>
<author>
<name>jimingham</name>
<email>jingham@apple.com</email>
</author>
<published>2024-02-20T22:18:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=563ef306017a47d387f1c36dd562b172c1ad0626'/>
<id>563ef306017a47d387f1c36dd562b172c1ad0626</id>
<content type='text'>
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.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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.</pre>
</div>
</content>
</entry>
<entry>
<title>Revert "Centralize the handling of completion for simple argument lists. (#82085)"</title>
<updated>2024-02-20T02:19:59+00:00</updated>
<author>
<name>Shubham Sandeep Rastogi</name>
<email>srastogi22@apple.com</email>
</author>
<published>2024-02-20T02:19:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=9ed8b272c30a01c450616f0ed8b2373d5d618ebb'/>
<id>9ed8b272c30a01c450616f0ed8b2373d5d618ebb</id>
<content type='text'>
This reverts commit 21631494b068d9364b8dc8f18e59adee9131a0a5.

Reverted because of greendragon failure:

******************** TEST 'lldb-api :: functionalities/completion/TestCompletion.py' FAILED ********************
Script:
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This reverts commit 21631494b068d9364b8dc8f18e59adee9131a0a5.

Reverted because of greendragon failure:

******************** TEST 'lldb-api :: functionalities/completion/TestCompletion.py' FAILED ********************
Script:
</pre>
</div>
</content>
</entry>
<entry>
<title>Centralize the handling of completion for simple argument lists. (#82085)</title>
<updated>2024-02-20T00:43:08+00:00</updated>
<author>
<name>jimingham</name>
<email>jingham@apple.com</email>
</author>
<published>2024-02-20T00:43:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=21631494b068d9364b8dc8f18e59adee9131a0a5'/>
<id>21631494b068d9364b8dc8f18e59adee9131a0a5</id>
<content type='text'>
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.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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.</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb] Part 2 of 2 - Refactor `CommandObject::DoExecute(...)` return `void` (not `bool`) (#69991)</title>
<updated>2023-10-30T20:21:00+00:00</updated>
<author>
<name>Pete Lawrence</name>
<email>plawrence@apple.com</email>
</author>
<published>2023-10-30T20:21:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=92d8a28cc665d73d9d679b8c014dd04f95d1df18'/>
<id>92d8a28cc665d73d9d679b8c014dd04f95d1df18</id>
<content type='text'>
[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</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[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</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb] Require paused process and frame for "register info" command (#67124)</title>
<updated>2023-09-22T14:55:27+00:00</updated>
<author>
<name>David Spickett</name>
<email>david.spickett@linaro.org</email>
</author>
<published>2023-09-22T14:55:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=bb01fd57bcaec533cd08b4d107979511d893f5b3'/>
<id>bb01fd57bcaec533cd08b4d107979511d893f5b3</id>
<content type='text'>
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.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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.</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb] Add register field tables to the "register info" command</title>
<updated>2023-06-21T10:50:31+00:00</updated>
<author>
<name>David Spickett</name>
<email>david.spickett@linaro.org</email>
</author>
<published>2023-06-05T17:02:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=bcfe5a52a39dee6d50d5e2410863fc555d2f50a8'/>
<id>bcfe5a52a39dee6d50d5e2410863fc555d2f50a8</id>
<content type='text'>
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
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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
</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb] Add "register info" command</title>
<updated>2023-06-21T08:48:18+00:00</updated>
<author>
<name>David Spickett</name>
<email>david.spickett@linaro.org</email>
</author>
<published>2023-03-01T11:03:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=ba85f206fe6f2fec9dd5fee55bf2a1e966fc37aa'/>
<id>ba85f206fe6f2fec9dd5fee55bf2a1e966fc37aa</id>
<content type='text'>
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
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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
</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb/Commands] Add support to auto-completion for user commands</title>
<updated>2023-06-06T17:58:34+00:00</updated>
<author>
<name>Med Ismail Bennani</name>
<email>ismail@bennani.ma</email>
</author>
<published>2023-06-06T17:24:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=6a9c3e611505b7637b46fbaacaf50362c97a263d'/>
<id>6a9c3e611505b7637b46fbaacaf50362c97a263d</id>
<content type='text'>
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 &lt;ismail@bennani.ma&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;ismail@bennani.ma&gt;
</pre>
</div>
</content>
</entry>
</feed>
