<feed xmlns='http://www.w3.org/2005/Atom'>
<title>llvm-project.git/lldb/source/Interpreter/OptionArgParser.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] Use std::optional::value_or (NFC) (#151629)</title>
<updated>2025-08-01T14:02:06+00:00</updated>
<author>
<name>Kazu Hirata</name>
<email>kazu@google.com</email>
</author>
<published>2025-08-01T14:02:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=33625f7cb395a3664b81f1327868828d2e51fa46'/>
<id>33625f7cb395a3664b81f1327868828d2e51fa46</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb] Pass address expression command args through FixAnyAddress (#147011)</title>
<updated>2025-07-08T23:21:45+00:00</updated>
<author>
<name>Jason Molenda</name>
<email>jmolenda@apple.com</email>
</author>
<published>2025-07-08T23:21:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=8461c004358fd8b89ea1a947348e5440a914af52'/>
<id>8461c004358fd8b89ea1a947348e5440a914af52</id>
<content type='text'>
Commands that take an address expression/address through the
OptionArgParser::ToAddress method, which has filtered this
user-specified address through one of the Process Fix methods to clear
non-addressable bits (MTE, PAC, top byte ignore, etc). We don't know
what class of address this is, IMEM or DMEM, but this method is passing
the addresses through Process::FixCodeAddress, and on at least one
target, FixCodeAddress clears low bits which are invalid for
instructions.

Correct this to use FixAnyAddress, which doesn't make alignment
assumptions.

The actual issue found was by people debugging on a 32-bit ARM Cortex-M
part, who tried to do a memory read from an odd address, and lldb
returned results starting at the next lower even address.

rdar://154885727</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Commands that take an address expression/address through the
OptionArgParser::ToAddress method, which has filtered this
user-specified address through one of the Process Fix methods to clear
non-addressable bits (MTE, PAC, top byte ignore, etc). We don't know
what class of address this is, IMEM or DMEM, but this method is passing
the addresses through Process::FixCodeAddress, and on at least one
target, FixCodeAddress clears low bits which are invalid for
instructions.

Correct this to use FixAnyAddress, which doesn't make alignment
assumptions.

The actual issue found was by people debugging on a 32-bit ARM Cortex-M
part, who tried to do a memory read from an odd address, and lldb
returned results starting at the next lower even address.

rdar://154885727</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb][Breakpoint] Allow whitespace in breakpoint address expression (#126053)</title>
<updated>2025-02-07T09:27:04+00:00</updated>
<author>
<name>Michael Buch</name>
<email>michaelbuch12@gmail.com</email>
</author>
<published>2025-02-07T09:27:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=1608fe8d56015719d5bf7abca608adad8a866f43'/>
<id>1608fe8d56015719d5bf7abca608adad8a866f43</id>
<content type='text'>
Setting a breakpoint on `&lt;symbol&gt; + &lt;offset&gt;` used to work until
`2c76e88e9eb284d17cf409851fb01f1d583bb22a`, where this regex was
reworked. Now we only accept `&lt;symbol&gt;+ &lt;offset&gt;` or
`&lt;symbol&gt;+&lt;offset&gt;`.

This patch fixes the regression by adding yet another `[[:space:]]*`
component to the regex.

One could probably simplify the regex (or even replace the regex by just
calling the relevent `consumeXXX` APIs on `llvm::StringRef`). Though I
left that for the future.

rdar://130780342</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Setting a breakpoint on `&lt;symbol&gt; + &lt;offset&gt;` used to work until
`2c76e88e9eb284d17cf409851fb01f1d583bb22a`, where this regex was
reworked. Now we only accept `&lt;symbol&gt;+ &lt;offset&gt;` or
`&lt;symbol&gt;+&lt;offset&gt;`.

This patch fixes the regression by adding yet another `[[:space:]]*`
component to the regex.

One could probably simplify the regex (or even replace the regex by just
calling the relevent `consumeXXX` APIs on `llvm::StringRef`). Though I
left that for the future.

rdar://130780342</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb] Turn lldb_private::Status into a value type. (#106163)</title>
<updated>2024-08-27T17:59:31+00:00</updated>
<author>
<name>Adrian Prantl</name>
<email>aprantl@apple.com</email>
</author>
<published>2024-08-27T17:59:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=0642cd768b80665585c8500bed2933a3b99123dc'/>
<id>0642cd768b80665585c8500bed2933a3b99123dc</id>
<content type='text'>
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&amp; error)
`
to

`    llvm::Expected&lt;ResultTy&gt; 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.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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&amp; error)
`
to

`    llvm::Expected&lt;ResultTy&gt; 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.</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb] Add/change options in `statistics dump` to control what sections are dumped (#95075)</title>
<updated>2024-06-19T00:21:20+00:00</updated>
<author>
<name>royitaqi</name>
<email>royitaqi@users.noreply.github.com</email>
</author>
<published>2024-06-19T00:21:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=70f41a8c305478cb16bcda9f9967af96ab1e3a20'/>
<id>70f41a8c305478cb16bcda9f9967af96ab1e3a20</id>
<content type='text'>
# Added/changed options

The following options are **added** to the `statistics dump` command:
* `--targets=bool`: Boolean. Dumps the `targets` section.
* `--modules=bool`: Boolean. Dumps the `modules` section.
When both options are given, the field `moduleIdentifiers` will be
dumped for each target in the `targets` section.

The following options are **changed**:
* `--transcript=bool`: Changed to a boolean. Dumps the `transcript`
section.

# Behavior of `statistics dump` with various options

The behavior is **backward compatible**:
- When no options are provided, `statistics dump` dumps all sections.
- When `--summary` is provided, only dumps the summary info.

**New** behavior:
- `--targets=bool`, `--modules=bool`, `--transcript=bool` overrides the
above "default".

For **example**:
- `statistics dump --modules=false` dumps summary + targets +
transcript. No modules.
- `statistics dump --summary --targets=true --transcript=true` dumps
summary + targets (in summary mode) + transcript.


# Added options into public API

In `SBStatisticsOptions`, add:
* `Set/GetIncludeTargets`
* `Set/GetIncludeModules`
* `Set/GetIncludeTranscript`

**Alternative considered**: Thought about adding
`Set/GetIncludeSections(string sections_spec)`, which receives a
comma-separated list of section names to be included ("targets",
"modules", "transcript"). The **benefit** of this approach is that the
API is more future-proof when it comes to possible adding/changing of
section names. **However**, I feel the section names are likely to
remain unchanged for a while - it's not like we plan to make big changes
to the output of `statistics dump` any time soon. The **downsides** of
this approach are: 1\ the readability of the API is worse (requires
reading doc to understand what string can be accepted), 2\ string input
are more prone to human error (e.g. typo "target" instead of expected
"targets").


# Tests

```
bin/llvm-lit -sv ../external/llvm-project/lldb/test/API/commands/statistics/basic/TestStats.py
```

```
./tools/lldb/unittests/Interpreter/InterpreterTests
```

New test cases have been added to verify:
* Different sections are dumped/not dumped when different
`StatisticsOptions` are given through command line (CLI or
`HandleCommand`; see `test_sections_existence_through_command`) or API
(see `test_sections_existence_through_api`).
* The order in which the options are given in command line does not
matter (see `test_order_of_options_do_not_matter`).

---------

Co-authored-by: Roy Shi &lt;royshi@meta.com&gt;</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
# Added/changed options

The following options are **added** to the `statistics dump` command:
* `--targets=bool`: Boolean. Dumps the `targets` section.
* `--modules=bool`: Boolean. Dumps the `modules` section.
When both options are given, the field `moduleIdentifiers` will be
dumped for each target in the `targets` section.

The following options are **changed**:
* `--transcript=bool`: Changed to a boolean. Dumps the `transcript`
section.

# Behavior of `statistics dump` with various options

The behavior is **backward compatible**:
- When no options are provided, `statistics dump` dumps all sections.
- When `--summary` is provided, only dumps the summary info.

**New** behavior:
- `--targets=bool`, `--modules=bool`, `--transcript=bool` overrides the
above "default".

For **example**:
- `statistics dump --modules=false` dumps summary + targets +
transcript. No modules.
- `statistics dump --summary --targets=true --transcript=true` dumps
summary + targets (in summary mode) + transcript.


# Added options into public API

In `SBStatisticsOptions`, add:
* `Set/GetIncludeTargets`
* `Set/GetIncludeModules`
* `Set/GetIncludeTranscript`

**Alternative considered**: Thought about adding
`Set/GetIncludeSections(string sections_spec)`, which receives a
comma-separated list of section names to be included ("targets",
"modules", "transcript"). The **benefit** of this approach is that the
API is more future-proof when it comes to possible adding/changing of
section names. **However**, I feel the section names are likely to
remain unchanged for a while - it's not like we plan to make big changes
to the output of `statistics dump` any time soon. The **downsides** of
this approach are: 1\ the readability of the API is worse (requires
reading doc to understand what string can be accepted), 2\ string input
are more prone to human error (e.g. typo "target" instead of expected
"targets").


# Tests

```
bin/llvm-lit -sv ../external/llvm-project/lldb/test/API/commands/statistics/basic/TestStats.py
```

```
./tools/lldb/unittests/Interpreter/InterpreterTests
```

New test cases have been added to verify:
* Different sections are dumped/not dumped when different
`StatisticsOptions` are given through command line (CLI or
`HandleCommand`; see `test_sections_existence_through_command`) or API
(see `test_sections_existence_through_api`).
* The order in which the options are given in command line does not
matter (see `test_order_of_options_do_not_matter`).

---------

Co-authored-by: Roy Shi &lt;royshi@meta.com&gt;</pre>
</div>
</content>
</entry>
<entry>
<title>Add register lookup as another fallback computation for address-expressions (#85492)</title>
<updated>2024-03-25T22:17:23+00:00</updated>
<author>
<name>jimingham</name>
<email>jingham@apple.com</email>
</author>
<published>2024-03-25T22:17:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=2c76e88e9eb284d17cf409851fb01f1d583bb22a'/>
<id>2c76e88e9eb284d17cf409851fb01f1d583bb22a</id>
<content type='text'>
The idea behind the address-expression is that it handles all the common
expressions that produce addresses. It handles actual valid expressions
that return a scalar, and it handles useful cases that the various
source languages don't support. At present, the fallback handles:

&lt;symbol_name&gt;{+-}&lt;offset&gt;

which isn't valid C but is very handy.

This patch adds handling of:

$&lt;reg_name&gt;

and

$&lt;reg_name&gt;{+-}&lt;offset&gt;

That's kind of pointless in C because the C expression parser handles
that expression already. But some languages don't have a straightforward
way to represent register values like this (swift) so having this
fallback is quite a quality of life improvement.

I added a test which tests that I didn't mess up either of these
fallbacks, though it doesn't test the actually handling of registers
that I added, since the expression parser for C succeeds in that case
and returns before this code gets run.

I will add a test on the swift fork for that checks that this works the
same way for a swift frame after this check.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The idea behind the address-expression is that it handles all the common
expressions that produce addresses. It handles actual valid expressions
that return a scalar, and it handles useful cases that the various
source languages don't support. At present, the fallback handles:

&lt;symbol_name&gt;{+-}&lt;offset&gt;

which isn't valid C but is very handy.

This patch adds handling of:

$&lt;reg_name&gt;

and

$&lt;reg_name&gt;{+-}&lt;offset&gt;

That's kind of pointless in C because the C expression parser handles
that expression already. But some languages don't have a straightforward
way to represent register values like this (swift) so having this
fallback is quite a quality of life improvement.

I added a test which tests that I didn't mess up either of these
fallbacks, though it doesn't test the actually handling of registers
that I added, since the expression parser for C succeeds in that case
and returns before this code gets run.

I will add a test on the swift fork for that checks that this works the
same way for a swift frame after this check.</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb] Refactor GetFormatFromCString to always check for partial matches  (NFC) (#81018)</title>
<updated>2024-02-08T17:32:12+00:00</updated>
<author>
<name>Dave Lee</name>
<email>davelee.com@gmail.com</email>
</author>
<published>2024-02-08T17:32:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=af97edff70b0d9cb89729dc0d8af1d1ea101686e'/>
<id>af97edff70b0d9cb89729dc0d8af1d1ea101686e</id>
<content type='text'>
Refactors logic in `ParseInternal` that was previously calling
`GetFormatFromCString` twice, once with `partial_match_ok` set to false,
and the second time set to true.

With this change, lldb formats (ie `%@`, `%S`, etc) are checked first.
If a format is not one of those, then `GetFormatFromCString` is called
once, and now always checks for partial matches.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Refactors logic in `ParseInternal` that was previously calling
`GetFormatFromCString` twice, once with `partial_match_ok` set to false,
and the second time set to true.

With this change, lldb formats (ie `%@`, `%S`, etc) are checked first.
If a format is not one of those, then `GetFormatFromCString` is called
once, and now always checks for partial matches.</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb] Use StringRef::{starts,ends}_with (NFC)</title>
<updated>2023-12-16T22:39:37+00:00</updated>
<author>
<name>Kazu Hirata</name>
<email>kazu@google.com</email>
</author>
<published>2023-12-16T22:39:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=744f38913fa380580431df0ae89ef5fb3df30240'/>
<id>744f38913fa380580431df0ae89ef5fb3df30240</id>
<content type='text'>
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.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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.
</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb][NFC] Delete unreachable code and dead variable in OptionArgParser</title>
<updated>2023-12-04T18:23:05+00:00</updated>
<author>
<name>Felipe de Azevedo Piovezan</name>
<email>fpiovezan@apple.com</email>
</author>
<published>2023-12-01T17:47:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=d24d7edaef9517edd9eb2ab26b02969e201bbcad'/>
<id>d24d7edaef9517edd9eb2ab26b02969e201bbcad</id>
<content type='text'>
With the combination of an early return and removing an else-after-return, it
becomes evident that there is unreachable code in the function being changed.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
With the combination of an early return and removing an else-after-return, it
becomes evident that there is unreachable code in the function being changed.
</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb][NFC] Remove else after return in OptionArgParse</title>
<updated>2023-12-04T18:23:05+00:00</updated>
<author>
<name>Felipe de Azevedo Piovezan</name>
<email>fpiovezan@apple.com</email>
</author>
<published>2023-12-01T17:44:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=3e98a285138a517fd918ec0ac8397dc56330d8e7'/>
<id>3e98a285138a517fd918ec0ac8397dc56330d8e7</id>
<content type='text'>
This will enable us to prove that there is unreachable code in this function in
a subsequent commit.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This will enable us to prove that there is unreachable code in this function in
a subsequent commit.
</pre>
</div>
</content>
</entry>
</feed>
