[Lldb-commits] [lldb] [libc] Add invoke / invoke_result type traits (PR #65750)

[Clement Courbet via lldb-commits]

https://github.com/legrosbuffle approved this pull request.


https://github.com/llvm/llvm-project/pull/65750
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][Docs] Document our major differences from the LLVM style (PR #66345)

[David Spickett via lldb-commits]

https://github.com/DavidSpickett updated 
https://github.com/llvm/llvm-project/pull/66345

>From bcabec98725255c4abed93311d73837d09ac8dde Mon Sep 17 00:00:00 2001
From: David Spickett 
Date: Thu, 14 Sep 2023 10:05:44 +0100
Subject: [PATCH 1/2] [lldb][Docs] Document our major differences from the LLVM
 style

Running:
$ clang-format -i $(find -regex "\./lldb/.*\.c") $(find -regex 
"\./lldb/.*\.cpp") $(find -regex "\./lldb/.*\.h")

Resulted in:
 1602 files changed, 25090 insertions(+), 25849 deletions(-)
(note: this includes tests which we wouldn't format, just
using this as an example)

The vast majority of which were whitespace changes. So as far
as formatting we're not deviating from llvm for any reason
other than not churning old code.

Formatting aside, the major features of lldb (single line if,
early return) are all reflected in llvm's style. We differ mainly
on variable naming (proposed to change in 
https://llvm.org/docs/Proposals/VariableNames.html
anyway) and use of asserts. Which was already documented.
---
 lldb/docs/resources/contributing.rst | 39 +---
 1 file changed, 29 insertions(+), 10 deletions(-)

diff --git a/lldb/docs/resources/contributing.rst 
b/lldb/docs/resources/contributing.rst
index 54917f1ce8175b3..9b133706a7fd160 100644
--- a/lldb/docs/resources/contributing.rst
+++ b/lldb/docs/resources/contributing.rst
@@ -18,19 +18,38 @@ Please refer to the `LLVM Developer Policy
 authoring and uploading a patch. LLDB differs from the LLVM Developer
 Policy in the following respects.
 
- - **Test infrastructure**: Like LLVM it is  important to submit tests with 
your
-   patches, but note that LLDB uses a different system for tests. Refer to the
-   `test documentation `_ for more details and the ``lldb/test``
-   folder on disk for examples.
-
- - **Coding Style**: LLDB's code style differs from
-   `LLVM's coding style `_.
-   Unfortunately there is no document describing the differences. Please be
-   consistent with the existing code.
-
 For anything not explicitly listed here, assume that LLDB follows the LLVM
 policy.
 
+Coding Style
+
+
+LLDB's code style differs from `LLVM's coding style 
`_
+in a few ways. The 2 main ones are:
+
+* `Variable naming 
`_:
+  LLDB prefers variables to be ``named_like_this`` and uses the ``m_`` prefix 
for
+  member variables.
+
+* `Use of asserts 
`_:
+  See the :ref:`section below`.
+
+For any other contradications please follow the existing code's style.
+
+Code in LLDB does aim to conform to clang-format but older code may not yet. As
+always, consider the `golden rule 
`_
+when working with such code. Reformatting before starting work is one possible
+option.
+
+Test Infrastructure

+
+Like LLVM it is  important to submit tests with your patches, but note that 
LLDB
+uses a different system for tests. Refer to the `test documentation 
`_
+for more details and the `lldb/test 
`_
+folder for examples.
+
+.. _Error handling:
 
 Error handling and use of assertions in LLDB
 

>From d9061c6e0389487822b90c88d4f9409bf912c368 Mon Sep 17 00:00:00 2001
From: David Spickett 
Date: Fri, 15 Sep 2023 09:32:39 +0100
Subject: [PATCH 2/2] * Cleanup error handling section, remove some dead links.
 * Moved lldbassert() deprecation to a note. * Show variable naming formats
 using the name of the format e.g. snake_case. * Note other variable prefixes.
 * Strengthen statement on clang-format. * Only refer to API tests in test
 section.

---
 lldb/docs/resources/contributing.rst | 58 
 1 file changed, 33 insertions(+), 25 deletions(-)

diff --git a/lldb/docs/resources/contributing.rst 
b/lldb/docs/resources/contributing.rst
index 9b133706a7fd160..5ac4afb82a0747a 100644
--- a/lldb/docs/resources/contributing.rst
+++ b/lldb/docs/resources/contributing.rst
@@ -27,27 +27,34 @@ Coding Style
 LLDB's code style differs from `LLVM's coding style 
`_
 in a few ways. The 2 main ones are:
 
-* `Variable naming 
`_:
-  LLDB prefers variables to be ``named_like_this`` and uses the ``m_`` prefix 
for
-  member variables.
+* `Variable and function naming 
`_:
+
+  * Variables are ``snake_case``.
+
+  * Functions and methods are ``UpperCamelCase``.
+
+  * Static, global and member variables have ``s_``, ``g_`` and ``_m``
+prefixes respectively.
 
 * `Use of as

[Lldb-commits] [lldb] [lldb][Docs] Document our major differences from the LLVM style (PR #66345)

[David Spickett via lldb-commits]

@@ -18,19 +18,38 @@ Please refer to the `LLVM Developer Policy
 authoring and uploading a patch. LLDB differs from the LLVM Developer
 Policy in the following respects.
 
- - **Test infrastructure**: Like LLVM it is  important to submit tests with 
your
-   patches, but note that LLDB uses a different system for tests. Refer to the
-   `test documentation `_ for more details and the ``lldb/test``
-   folder on disk for examples.
-
- - **Coding Style**: LLDB's code style differs from
-   `LLVM's coding style `_.
-   Unfortunately there is no document describing the differences. Please be
-   consistent with the existing code.
-
 For anything not explicitly listed here, assume that LLDB follows the LLVM
 policy.
 
+Coding Style
+
+
+LLDB's code style differs from `LLVM's coding style 
`_
+in a few ways. The 2 main ones are:
+
+* `Variable naming 
`_:
+  LLDB prefers variables to be ``named_like_this`` and uses the ``m_`` prefix 
for
+  member variables.

DavidSpickett wrote:

Done.

https://github.com/llvm/llvm-project/pull/66345
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][Docs] Document our major differences from the LLVM style (PR #66345)

[David Spickett via lldb-commits]

https://github.com/DavidSpickett resolved 
https://github.com/llvm/llvm-project/pull/66345
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][Docs] Document our major differences from the LLVM style (PR #66345)

[David Spickett via lldb-commits]

@@ -18,19 +18,38 @@ Please refer to the `LLVM Developer Policy
 authoring and uploading a patch. LLDB differs from the LLVM Developer
 Policy in the following respects.
 
- - **Test infrastructure**: Like LLVM it is  important to submit tests with 
your
-   patches, but note that LLDB uses a different system for tests. Refer to the
-   `test documentation `_ for more details and the ``lldb/test``
-   folder on disk for examples.
-
- - **Coding Style**: LLDB's code style differs from
-   `LLVM's coding style `_.
-   Unfortunately there is no document describing the differences. Please be
-   consistent with the existing code.
-
 For anything not explicitly listed here, assume that LLDB follows the LLVM
 policy.
 
+Coding Style
+
+
+LLDB's code style differs from `LLVM's coding style 
`_
+in a few ways. The 2 main ones are:
+
+* `Variable naming 
`_:
+  LLDB prefers variables to be ``named_like_this`` and uses the ``m_`` prefix 
for

DavidSpickett wrote:

I've used the name of the format as the example e.g. `snake_case`.

https://github.com/llvm/llvm-project/pull/66345
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][Docs] Document our major differences from the LLVM style (PR #66345)

[David Spickett via lldb-commits]

https://github.com/DavidSpickett resolved 
https://github.com/llvm/llvm-project/pull/66345
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][Docs] Document our major differences from the LLVM style (PR #66345)

[David Spickett via lldb-commits]

@@ -18,19 +18,38 @@ Please refer to the `LLVM Developer Policy
 authoring and uploading a patch. LLDB differs from the LLVM Developer
 Policy in the following respects.
 
- - **Test infrastructure**: Like LLVM it is  important to submit tests with 
your
-   patches, but note that LLDB uses a different system for tests. Refer to the
-   `test documentation `_ for more details and the ``lldb/test``
-   folder on disk for examples.
-
- - **Coding Style**: LLDB's code style differs from
-   `LLVM's coding style `_.
-   Unfortunately there is no document describing the differences. Please be
-   consistent with the existing code.
-
 For anything not explicitly listed here, assume that LLDB follows the LLVM
 policy.
 
+Coding Style
+
+
+LLDB's code style differs from `LLVM's coding style 
`_
+in a few ways. The 2 main ones are:
+
+* `Variable naming 
`_:
+  LLDB prefers variables to be ``named_like_this`` and uses the ``m_`` prefix 
for
+  member variables.
+
+* `Use of asserts 
`_:
+  See the :ref:`section below`.
+
+For any other contradications please follow the existing code's style.
+
+Code in LLDB does aim to conform to clang-format but older code may not yet. As
+always, consider the `golden rule 
`_
+when working with such code. Reformatting before starting work is one possible
+option.
+
+Test Infrastructure

+
+Like LLVM it is  important to submit tests with your patches, but note that 
LLDB
+uses a different system for tests. Refer to the `test documentation 
`_

DavidSpickett wrote:

Done, I think. I limited the statement to the API tests, I don't think 
expanding on it here is worth it it when we have a testing page.

https://github.com/llvm/llvm-project/pull/66345
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][Docs] Document our major differences from the LLVM style (PR #66345)

[David Spickett via lldb-commits]

https://github.com/DavidSpickett resolved 
https://github.com/llvm/llvm-project/pull/66345
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][Docs] Document our major differences from the LLVM style (PR #66345)

[David Spickett via lldb-commits]

@@ -18,19 +18,38 @@ Please refer to the `LLVM Developer Policy
 authoring and uploading a patch. LLDB differs from the LLVM Developer
 Policy in the following respects.
 
- - **Test infrastructure**: Like LLVM it is  important to submit tests with 
your
-   patches, but note that LLDB uses a different system for tests. Refer to the
-   `test documentation `_ for more details and the ``lldb/test``
-   folder on disk for examples.
-
- - **Coding Style**: LLDB's code style differs from
-   `LLVM's coding style `_.
-   Unfortunately there is no document describing the differences. Please be
-   consistent with the existing code.
-
 For anything not explicitly listed here, assume that LLDB follows the LLVM
 policy.
 
+Coding Style
+
+
+LLDB's code style differs from `LLVM's coding style 
`_
+in a few ways. The 2 main ones are:
+
+* `Variable naming 
`_:
+  LLDB prefers variables to be ``named_like_this`` and uses the ``m_`` prefix 
for
+  member variables.
+
+* `Use of asserts 
`_:
+  See the :ref:`section below`.

DavidSpickett wrote:

I take this to mean lldb isn't the odd one out (things like clangd probably 
have similar approaches), but that it's worth keeping the note regardless.

Which I agree with, and we already have the content. I did update it a bit to 
remove some dead links and such.

https://github.com/llvm/llvm-project/pull/66345
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][Docs] Document our major differences from the LLVM style (PR #66345)

[David Spickett via lldb-commits]

https://github.com/DavidSpickett resolved 
https://github.com/llvm/llvm-project/pull/66345
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][Docs] Document our major differences from the LLVM style (PR #66345)

[David Spickett via lldb-commits]

@@ -18,19 +18,38 @@ Please refer to the `LLVM Developer Policy
 authoring and uploading a patch. LLDB differs from the LLVM Developer
 Policy in the following respects.
 
- - **Test infrastructure**: Like LLVM it is  important to submit tests with 
your
-   patches, but note that LLDB uses a different system for tests. Refer to the
-   `test documentation `_ for more details and the ``lldb/test``
-   folder on disk for examples.
-
- - **Coding Style**: LLDB's code style differs from
-   `LLVM's coding style `_.
-   Unfortunately there is no document describing the differences. Please be
-   consistent with the existing code.
-
 For anything not explicitly listed here, assume that LLDB follows the LLVM
 policy.
 
+Coding Style
+
+
+LLDB's code style differs from `LLVM's coding style 
`_
+in a few ways. The 2 main ones are:
+
+* `Variable naming 
`_:
+  LLDB prefers variables to be ``named_like_this`` and uses the ``m_`` prefix 
for
+  member variables.
+
+* `Use of asserts 
`_:
+  See the :ref:`section below`.
+
+For any other contradications please follow the existing code's style.
+
+Code in LLDB does aim to conform to clang-format but older code may not yet. As
+always, consider the `golden rule 
`_
+when working with such code. Reformatting before starting work is one possible
+option.

DavidSpickett wrote:

Done.

https://github.com/llvm/llvm-project/pull/66345
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][Docs] Document our major differences from the LLVM style (PR #66345)

[David Spickett via lldb-commits]

https://github.com/DavidSpickett resolved 
https://github.com/llvm/llvm-project/pull/66345
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][Docs] Document our major differences from the LLVM style (PR #66345)

[David Spickett via lldb-commits]

https://github.com/DavidSpickett resolved 
https://github.com/llvm/llvm-project/pull/66345
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][Docs] Document our major differences from the LLVM style (PR #66345)

[David Spickett via lldb-commits]

@@ -18,19 +18,38 @@ Please refer to the `LLVM Developer Policy
 authoring and uploading a patch. LLDB differs from the LLVM Developer
 Policy in the following respects.
 
- - **Test infrastructure**: Like LLVM it is  important to submit tests with 
your
-   patches, but note that LLDB uses a different system for tests. Refer to the
-   `test documentation `_ for more details and the ``lldb/test``
-   folder on disk for examples.
-
- - **Coding Style**: LLDB's code style differs from
-   `LLVM's coding style `_.
-   Unfortunately there is no document describing the differences. Please be
-   consistent with the existing code.
-
 For anything not explicitly listed here, assume that LLDB follows the LLVM
 policy.
 
+Coding Style
+
+
+LLDB's code style differs from `LLVM's coding style 
`_
+in a few ways. The 2 main ones are:
+
+* `Variable naming 
`_:
+  LLDB prefers variables to be ``named_like_this`` and uses the ``m_`` prefix 
for
+  member variables.
+
+* `Use of asserts 
`_:
+  See the :ref:`section below`.
+
+For any other contradications please follow the existing code's style.
+
+Code in LLDB does aim to conform to clang-format but older code may not yet. As
+always, consider the `golden rule 
`_
+when working with such code. Reformatting before starting work is one possible
+option.
+
+Test Infrastructure

+
+Like LLVM it is  important to submit tests with your patches, but note that 
LLDB

DavidSpickett wrote:

Done.

https://github.com/llvm/llvm-project/pull/66345
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][Docs] Update links in Data Formatter section (PR #66474)

[David Spickett via lldb-commits]

https://github.com/DavidSpickett created 
https://github.com/llvm/llvm-project/pull/66474

Neither actually linked anywhere, but I did find a good target for the 
introduction.

For the architecture side I don't see a page that would fit, so I've just 
removed the sentence.

>From fa5f8a30e309212ed85f5bb4501c4f931d9bd06c Mon Sep 17 00:00:00 2001
From: David Spickett 
Date: Fri, 15 Sep 2023 09:58:54 +0100
Subject: [PATCH] [lldb][Docs] Update links in Data Formatter section

Neither actually linked anywhere, but I did find a good target
for the introduction.

For the architecture side I don't see a page that would fit,
so I've just removed the sentence.
---
 lldb/docs/resources/overview.rst | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/lldb/docs/resources/overview.rst b/lldb/docs/resources/overview.rst
index b76af384e08b978..054fcbfea2164c2 100644
--- a/lldb/docs/resources/overview.rst
+++ b/lldb/docs/resources/overview.rst
@@ -80,8 +80,8 @@ wide variety of classes are implemented:
 - Source manager
 - Value objects
 
-Dataformatters
---
+Data Formatters
+---
 
 A collection of classes that implement the data formatters subsystem.
 
@@ -92,9 +92,7 @@ layers to the implementation: DataVisualization at the 
highest end of the
 spectrum, backed by classes implementing individual formatters, matching rules,
 etc.
 
-For a general user-level introduction to data formatters, you can look here.
-
-More details on the architecture are to be found here.
+For an introduction to data formatters, see :doc:`/use/variable`.
 
 Expression
 --

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][Docs] Update links in Data Formatter section (PR #66474)

[via lldb-commits]

llvmbot wrote:




@llvm/pr-subscribers-lldb


Changes
Neither actually linked anywhere, but I did find a good target for the 
introduction.

For the architecture side I don't see a page that would fit, so I've just 
removed the sentence.
--
Full diff: https://github.com/llvm/llvm-project/pull/66474.diff

1 Files Affected:

- (modified) lldb/docs/resources/overview.rst (+3-5) 



diff --git a/lldb/docs/resources/overview.rst b/lldb/docs/resources/overview.rst
index b76af384e08b978..054fcbfea2164c2 100644
--- a/lldb/docs/resources/overview.rst
+++ b/lldb/docs/resources/overview.rst
@@ -80,8 +80,8 @@ wide variety of classes are implemented:
 - Source manager
 - Value objects
 
-Dataformatters
---
+Data Formatters
+---
 
 A collection of classes that implement the data formatters subsystem.
 
@@ -92,9 +92,7 @@ layers to the implementation: DataVisualization at the 
highest end of the
 spectrum, backed by classes implementing individual formatters, matching rules,
 etc.
 
-For a general user-level introduction to data formatters, you can look here.
-
-More details on the architecture are to be found here.
+For an introduction to data formatters, see :doc:`/use/variable`.
 
 Expression
 --




https://github.com/llvm/llvm-project/pull/66474
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][Docs] Update links in Data Formatter section (PR #66474)

[David Spickett via lldb-commits]

DavidSpickett wrote:

Would skip review, but it's here on the off chance @JDevlieghere knows where 
the second link was supposed to go to.

The original commit was 
https://github.com/llvm/llvm-project/commit/edb874b2310dc6eeaa27330ca1b1c013da7bdd65.

https://github.com/llvm/llvm-project/pull/66474
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [libc] Add invoke / invoke_result type traits (PR #65750)

[Guillaume Chatelet via lldb-commits]

gchatelet wrote:

Thx for the thorough review @legrosbuffle, I really appreciate it.

https://github.com/llvm/llvm-project/pull/65750
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [libc] Add invoke / invoke_result type traits (PR #65750)

[Guillaume Chatelet via lldb-commits]

https://github.com/gchatelet closed 
https://github.com/llvm/llvm-project/pull/65750
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D159502: [lldb][AArch64] Add SME's Array Storage (ZA) register

[Muhammad Omair Javaid via Phabricator via lldb-commits]

omjavaid accepted this revision.
omjavaid added a comment.
This revision is now accepted and ready to land.

This is LGTM. Thanks for your patience.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D159502/new/

https://reviews.llvm.org/D159502

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D159503: [lldb][AArch64] Add SME streaming vector length pseduo register

[Muhammad Omair Javaid via Phabricator via lldb-commits]

omjavaid added a comment.

This looks find just couple of nits inline.




Comment at: 
lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp:354
+
+  // ZA is part of the SME set but uses a seperate member buffer for 
storage.
+  // Therefore its effective byte offset is always 0 even if it isn't 0 
within

this block of code requires clang-format run



Comment at: 
lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.h:117
 
+  struct sme_regs {
+uint64_t svg_reg;

should we name this to sme_pseudo_regs ? sme_regs suggests struct could include 
ZA as well.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D159503/new/

https://reviews.llvm.org/D159503

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D159504: [lldb][AArch64] Implement resizing of SME's ZA register

[Muhammad Omair Javaid via Phabricator via lldb-commits]

omjavaid added inline comments.



Comment at: 
lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp:839
+
+void GDBRemoteDynamicRegisterInfo::UpdateARM64SMERegistersInfos(uint64_t svg) {
+  for (auto ® : m_regs) {

can we combine UpdateARM64SVERegistersInfos and UpdateARM64SMERegistersInfos to 
avoid back to back calls of ConfigureOffsets


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D159504/new/

https://reviews.llvm.org/D159504

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D159503: [lldb][AArch64] Add SME streaming vector length pseduo register

[David Spickett via Phabricator via lldb-commits]

DavidSpickett updated this revision to Diff 556844.
DavidSpickett added a comment.

- sme_regs -> sme_pseudo_regs, also changed the accesor method names.
- clang-format


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D159503/new/

https://reviews.llvm.org/D159503

Files:
  lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp
  lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.h
  lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.cpp
  lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.h

Index: lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.h
===
--- lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.h
+++ lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.h
@@ -135,12 +135,14 @@
   bool IsMTEReg(unsigned reg) const;
   bool IsTLSReg(unsigned reg) const;
   bool IsSMEReg(unsigned reg) const;
+  bool IsSMERegZA(unsigned reg) const;
 
   uint32_t GetRegNumSVEZ0() const;
   uint32_t GetRegNumSVEFFR() const;
   uint32_t GetRegNumFPCR() const;
   uint32_t GetRegNumFPSR() const;
   uint32_t GetRegNumSVEVG() const;
+  uint32_t GetRegNumSMESVG() const;
   uint32_t GetPAuthOffset() const;
   uint32_t GetMTEOffset() const;
   uint32_t GetTLSOffset() const;
Index: lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.cpp
===
--- lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.cpp
+++ lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.cpp
@@ -83,10 +83,11 @@
 // Only present when SME is present
 DEFINE_EXTENSION_REG(tpidr2)};
 
-static lldb_private::RegisterInfo g_register_infos_sme[] =
+static lldb_private::RegisterInfo g_register_infos_sme[] = {
+DEFINE_EXTENSION_REG(svg),
 // 16 is a default size we will change later.
-{{"za", nullptr, 16, 0, lldb::eEncodingVector, lldb::eFormatVectorOfUInt8,
-  KIND_ALL_INVALID, nullptr, nullptr, nullptr}};
+{"za", nullptr, 16, 0, lldb::eEncodingVector, lldb::eFormatVectorOfUInt8,
+ KIND_ALL_INVALID, nullptr, nullptr, nullptr}};
 
 // Number of register sets provided by this context.
 enum {
@@ -96,7 +97,7 @@
   k_num_mte_register = 1,
   // Number of TLS registers is dynamic so it is not listed here.
   k_num_pauth_register = 2,
-  k_num_sme_register = 1,
+  k_num_sme_register = 2,
   k_num_register_sets_default = 2,
   k_num_register_sets = 3
 };
@@ -448,7 +449,7 @@
   // dynamic set and is just 1 register so we make an exception to const here.
   lldb_private::RegisterInfo *non_const_reginfo =
   const_cast(m_register_info_p);
-  non_const_reginfo[m_sme_regnum_collection[0]].byte_size =
+  non_const_reginfo[m_sme_regnum_collection[1]].byte_size =
   (za_vq * 16) * (za_vq * 16);
 }
 
@@ -471,6 +472,10 @@
   return sve_vg == reg;
 }
 
+bool RegisterInfoPOSIX_arm64::IsSMERegZA(unsigned reg) const {
+  return reg == m_sme_regnum_collection[1];
+}
+
 bool RegisterInfoPOSIX_arm64::IsPAuthReg(unsigned reg) const {
   return llvm::is_contained(pauth_regnum_collection, reg);
 }
@@ -497,6 +502,10 @@
 
 uint32_t RegisterInfoPOSIX_arm64::GetRegNumSVEVG() const { return sve_vg; }
 
+uint32_t RegisterInfoPOSIX_arm64::GetRegNumSMESVG() const {
+  return m_sme_regnum_collection[0];
+}
+
 uint32_t RegisterInfoPOSIX_arm64::GetPAuthOffset() const {
   return m_register_info_p[pauth_regnum_collection[0]].byte_offset;
 }
Index: lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.h
===
--- lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.h
+++ lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.h
@@ -114,6 +114,12 @@
 
   uint64_t m_mte_ctrl_reg;
 
+  struct sme_pseudo_regs {
+uint64_t svg_reg;
+  };
+
+  struct sme_pseudo_regs m_sme_pseudo_regs;
+
   struct tls_regs {
 uint64_t tpidr_reg;
 // Only valid when SME is present.
@@ -144,6 +150,8 @@
 
   Status WriteTLS();
 
+  Status ReadSMESVG();
+
   Status ReadZAHeader();
 
   Status ReadZA();
@@ -176,6 +184,8 @@
 
   void *GetTLSBuffer() { return &m_tls_regs; }
 
+  void *GetSMEPseudoBuffer() { return &m_sme_pseudo_regs; }
+
   void *GetSVEBuffer() { return m_sve_ptrace_payload.data(); }
 
   size_t GetSVEHeaderSize() { return sizeof(m_sve_header); }
@@ -194,6 +204,8 @@
 
   size_t GetTLSBufferSize() { return m_tls_size; }
 
+  size_t GetSMEPseudoBufferSize() { return sizeof(m_sme_pseudo_regs); }
+
   llvm::Error ReadHardwareDebugInfo() override;
 
   llvm::Error WriteHardwareDebugRegs(DREGType hwbType) override;
Index: lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp
===
--- lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp
+++ lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp
@@ -

[Lldb-commits] [PATCH] D159503: [lldb][AArch64] Add SME streaming vector length pseduo register

[David Spickett via Phabricator via lldb-commits]

DavidSpickett marked 2 inline comments as done.
DavidSpickett added a comment.

Will apply the rename in core files as well later.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D159503/new/

https://reviews.llvm.org/D159503

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D159503: [lldb][AArch64] Add SME streaming vector length pseduo register

[David Spickett via Phabricator via lldb-commits]

DavidSpickett added a comment.

Note that GetSMEOffset refers to the whole register set which does include ZA, 
so no change of name there.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D159503/new/

https://reviews.llvm.org/D159503

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D159503: [lldb][AArch64] Add SME streaming vector length pseduo register

[David Spickett via Phabricator via lldb-commits]

DavidSpickett updated this revision to Diff 556851.
DavidSpickett added a comment.

Rebase


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D159503/new/

https://reviews.llvm.org/D159503

Files:
  lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp
  lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.h
  lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.cpp
  lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.h

Index: lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.h
===
--- lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.h
+++ lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.h
@@ -135,12 +135,14 @@
   bool IsMTEReg(unsigned reg) const;
   bool IsTLSReg(unsigned reg) const;
   bool IsSMEReg(unsigned reg) const;
+  bool IsSMERegZA(unsigned reg) const;
 
   uint32_t GetRegNumSVEZ0() const;
   uint32_t GetRegNumSVEFFR() const;
   uint32_t GetRegNumFPCR() const;
   uint32_t GetRegNumFPSR() const;
   uint32_t GetRegNumSVEVG() const;
+  uint32_t GetRegNumSMESVG() const;
   uint32_t GetPAuthOffset() const;
   uint32_t GetMTEOffset() const;
   uint32_t GetTLSOffset() const;
Index: lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.cpp
===
--- lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.cpp
+++ lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.cpp
@@ -83,10 +83,11 @@
 // Only present when SME is present
 DEFINE_EXTENSION_REG(tpidr2)};
 
-static lldb_private::RegisterInfo g_register_infos_sme[] =
+static lldb_private::RegisterInfo g_register_infos_sme[] = {
+DEFINE_EXTENSION_REG(svg),
 // 16 is a default size we will change later.
-{{"za", nullptr, 16, 0, lldb::eEncodingVector, lldb::eFormatVectorOfUInt8,
-  KIND_ALL_INVALID, nullptr, nullptr, nullptr}};
+{"za", nullptr, 16, 0, lldb::eEncodingVector, lldb::eFormatVectorOfUInt8,
+ KIND_ALL_INVALID, nullptr, nullptr, nullptr}};
 
 // Number of register sets provided by this context.
 enum {
@@ -96,7 +97,7 @@
   k_num_mte_register = 1,
   // Number of TLS registers is dynamic so it is not listed here.
   k_num_pauth_register = 2,
-  k_num_sme_register = 1,
+  k_num_sme_register = 2,
   k_num_register_sets_default = 2,
   k_num_register_sets = 3
 };
@@ -448,7 +449,7 @@
   // dynamic set and is just 1 register so we make an exception to const here.
   lldb_private::RegisterInfo *non_const_reginfo =
   const_cast(m_register_info_p);
-  non_const_reginfo[m_sme_regnum_collection[0]].byte_size =
+  non_const_reginfo[m_sme_regnum_collection[1]].byte_size =
   (za_vq * 16) * (za_vq * 16);
 }
 
@@ -471,6 +472,10 @@
   return sve_vg == reg;
 }
 
+bool RegisterInfoPOSIX_arm64::IsSMERegZA(unsigned reg) const {
+  return reg == m_sme_regnum_collection[1];
+}
+
 bool RegisterInfoPOSIX_arm64::IsPAuthReg(unsigned reg) const {
   return llvm::is_contained(pauth_regnum_collection, reg);
 }
@@ -497,6 +502,10 @@
 
 uint32_t RegisterInfoPOSIX_arm64::GetRegNumSVEVG() const { return sve_vg; }
 
+uint32_t RegisterInfoPOSIX_arm64::GetRegNumSMESVG() const {
+  return m_sme_regnum_collection[0];
+}
+
 uint32_t RegisterInfoPOSIX_arm64::GetPAuthOffset() const {
   return m_register_info_p[pauth_regnum_collection[0]].byte_offset;
 }
Index: lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.h
===
--- lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.h
+++ lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.h
@@ -114,6 +114,12 @@
 
   uint64_t m_mte_ctrl_reg;
 
+  struct sme_pseudo_regs {
+uint64_t svg_reg;
+  };
+
+  struct sme_pseudo_regs m_sme_pseudo_regs;
+
   struct tls_regs {
 uint64_t tpidr_reg;
 // Only valid when SME is present.
@@ -144,6 +150,8 @@
 
   Status WriteTLS();
 
+  Status ReadSMESVG();
+
   Status ReadZAHeader();
 
   Status ReadZA();
@@ -176,6 +184,8 @@
 
   void *GetTLSBuffer() { return &m_tls_regs; }
 
+  void *GetSMEPseudoBuffer() { return &m_sme_pseudo_regs; }
+
   void *GetSVEBuffer() { return m_sve_ptrace_payload.data(); }
 
   size_t GetSVEHeaderSize() { return sizeof(m_sve_header); }
@@ -194,6 +204,8 @@
 
   size_t GetTLSBufferSize() { return m_tls_size; }
 
+  size_t GetSMEPseudoBufferSize() { return sizeof(m_sme_pseudo_regs); }
+
   llvm::Error ReadHardwareDebugInfo() override;
 
   llvm::Error WriteHardwareDebugRegs(DREGType hwbType) override;
Index: lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp
===
--- lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp
+++ lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp
@@ -147,6 +147,7 @@
   ::memset(&m_sve_header, 0, sizeof(m_sve_header));
   ::mems

[Lldb-commits] [PATCH] D159504: [lldb][AArch64] Implement resizing of SME's ZA register

[David Spickett via Phabricator via lldb-commits]

DavidSpickett updated this revision to Diff 556852.
DavidSpickett added a comment.

Combine reconfigure into one function. The tricky thing is we have to read
svg and vg up front because we can't read registers while we're messing
with register offsets.

Otherwise, the result is a bit clearer and it also avoids a second heap
allocation for the storage.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D159504/new/

https://reviews.llvm.org/D159504

Files:
  lldb/include/lldb/Target/DynamicRegisterInfo.h
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.h
  lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
  lldb/source/Target/DynamicRegisterInfo.cpp

Index: lldb/source/Target/DynamicRegisterInfo.cpp
===
--- lldb/source/Target/DynamicRegisterInfo.cpp
+++ lldb/source/Target/DynamicRegisterInfo.cpp
@@ -614,10 +614,11 @@
   ConfigureOffsets();
 
   // Check if register info is reconfigurable
-  // AArch64 SVE register set has configurable register sizes
+  // AArch64 SVE register set has configurable register sizes, as does the ZA
+  // register that SME added (the streaming state of SME reuses the SVE state).
   if (arch.GetTriple().isAArch64()) {
 for (const auto ® : m_regs) {
-  if (strcmp(reg.name, "vg") == 0) {
+  if ((strcmp(reg.name, "vg") == 0) || (strcmp(reg.name, "svg") == 0)) {
 m_is_reconfigurable = true;
 break;
   }
Index: lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
===
--- lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
+++ lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
@@ -1660,17 +1660,18 @@
 gdb_thread->PrivateSetRegisterValue(lldb_regnum, buffer_sp->GetData());
   }
 
-  // AArch64 SVE specific code below calls AArch64SVEReconfigure to update
-  // SVE register sizes and offsets if value of VG register has changed
-  // since last stop.
+  // AArch64 SVE/SME specific code below updates SVE and ZA register sizes and
+  // offsets if value of VG or SVG registers has changed since last stop.
   const ArchSpec &arch = GetTarget().GetArchitecture();
   if (arch.IsValid() && arch.GetTriple().isAArch64()) {
 GDBRemoteRegisterContext *reg_ctx_sp =
 static_cast(
 gdb_thread->GetRegisterContext().get());
 
-if (reg_ctx_sp)
-  reg_ctx_sp->AArch64SVEReconfigure();
+if (reg_ctx_sp) {
+  reg_ctx_sp->AArch64Reconfigure();
+  reg_ctx_sp->InvalidateAllRegisters();
+}
   }
 
   thread_sp->SetName(thread_name.empty() ? nullptr : thread_name.c_str());
Index: lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.h
===
--- lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.h
+++ lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.h
@@ -39,6 +39,7 @@
   ~GDBRemoteDynamicRegisterInfo() override = default;
 
   void UpdateARM64SVERegistersInfos(uint64_t vg);
+  void UpdateARM64SMERegistersInfos(uint64_t svg);
 };
 
 class GDBRemoteRegisterContext : public RegisterContext {
@@ -77,7 +78,8 @@
   uint32_t ConvertRegisterKindToRegisterNumber(lldb::RegisterKind kind,
uint32_t num) override;
 
-  bool AArch64SVEReconfigure();
+  // Reconfigure variable sized registers for AArch64 SVE and SME.
+  void AArch64Reconfigure();
 
 protected:
   friend class ThreadGDBRemote;
Index: lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
===
--- lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
+++ lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
@@ -373,14 +373,14 @@
   if (dst == nullptr)
 return false;
 
-  // Code below is specific to AArch64 target in SVE state
+  // Code below is specific to AArch64 target in SVE or SME state
   // If vector granule (vg) register is being written then thread's
   // register context reconfiguration is triggered on success.
-  bool do_reconfigure_arm64_sve = false;
+  // We do not allow writes to SVG so it is not mentioned here.
   const ArchSpec &arch = process->GetTarget().GetArchitecture();
-  if (arch.IsValid() && arch.GetTriple().isAArch64())
-if (strcmp(reg_info->name, "vg") == 0)
-  do_reconfigure_arm64_sve = true;
+  bool do_reconfigure_arm64_sve = arch.IsValid() &&
+  arch.GetTriple().isAArch64() &&
+  (strcmp(reg_info->name, "vg") == 0);
 
   if (data.CopyByteOrderedData(data_offset,// src offset
reg_info->byte_size,// src length
@@ -400,10 +400,10 @@
 {m_reg_data.GetDataStart(), size_t(m_reg_dat

[Lldb-commits] [PATCH] D159504: [lldb][AArch64] Implement resizing of SME's ZA register

[David Spickett via Phabricator via lldb-commits]

DavidSpickett marked an inline comment as done.
DavidSpickett added inline comments.



Comment at: 
lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp:839
+
+void GDBRemoteDynamicRegisterInfo::UpdateARM64SMERegistersInfos(uint64_t svg) {
+  for (auto ® : m_regs) {

omjavaid wrote:
> can we combine UpdateARM64SVERegistersInfos and UpdateARM64SMERegistersInfos 
> to avoid back to back calls of ConfigureOffsets
Yes, done. See comments for weird details.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D159504/new/

https://reviews.llvm.org/D159504

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D159505: [lldb][AArch64] Add testing for SME's ZA and SVG registers

[David Spickett via Phabricator via lldb-commits]

DavidSpickett updated this revision to Diff 556853.
DavidSpickett added a comment.

Rebase


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D159505/new/

https://reviews.llvm.org/D159505

Files:
  
lldb/test/API/commands/register/register/aarch64_dynamic_regset/TestArm64DynamicRegsets.py
  
lldb/test/API/commands/register/register/aarch64_sve_registers/rw_access_dynamic_resize/TestSVEThreadedDynamic.py
  
lldb/test/API/commands/register/register/aarch64_za_register/za_dynamic_resize/Makefile
  
lldb/test/API/commands/register/register/aarch64_za_register/za_dynamic_resize/TestZAThreadedDynamic.py
  
lldb/test/API/commands/register/register/aarch64_za_register/za_dynamic_resize/main.c
  
lldb/test/API/commands/register/register/aarch64_za_register/za_save_restore/Makefile
  
lldb/test/API/commands/register/register/aarch64_za_register/za_save_restore/TestZARegisterSaveRestore.py
  
lldb/test/API/commands/register/register/aarch64_za_register/za_save_restore/main.c

Index: lldb/test/API/commands/register/register/aarch64_za_register/za_save_restore/main.c
===
--- /dev/null
+++ lldb/test/API/commands/register/register/aarch64_za_register/za_save_restore/main.c
@@ -0,0 +1,226 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+
+// Important details for this program:
+// * Making a syscall will disable streaming mode if it is active.
+// * Changing the vector length will make streaming mode and ZA inactive.
+// * ZA can be active independent of streaming mode.
+// * ZA's size is the streaming vector length squared.
+
+#ifndef PR_SME_SET_VL
+#define PR_SME_SET_VL 63
+#endif
+
+#ifndef PR_SME_GET_VL
+#define PR_SME_GET_VL 64
+#endif
+
+#ifndef PR_SME_VL_LEN_MASK
+#define PR_SME_VL_LEN_MASK 0x
+#endif
+
+#define SM_INST(c) asm volatile("msr s0_3_c4_c" #c "_3, xzr")
+#define SMSTART SM_INST(7)
+#define SMSTART_SM SM_INST(3)
+#define SMSTART_ZA SM_INST(5)
+#define SMSTOP SM_INST(6)
+#define SMSTOP_SM SM_INST(2)
+#define SMSTOP_ZA SM_INST(4)
+
+int start_vl = 0;
+int other_vl = 0;
+
+void write_sve_regs() {
+  // We assume the smefa64 feature is present, which allows ffr access
+  // in streaming mode.
+  asm volatile("setffr\n\t");
+  asm volatile("ptrue p0.b\n\t");
+  asm volatile("ptrue p1.h\n\t");
+  asm volatile("ptrue p2.s\n\t");
+  asm volatile("ptrue p3.d\n\t");
+  asm volatile("pfalse p4.b\n\t");
+  asm volatile("ptrue p5.b\n\t");
+  asm volatile("ptrue p6.h\n\t");
+  asm volatile("ptrue p7.s\n\t");
+  asm volatile("ptrue p8.d\n\t");
+  asm volatile("pfalse p9.b\n\t");
+  asm volatile("ptrue p10.b\n\t");
+  asm volatile("ptrue p11.h\n\t");
+  asm volatile("ptrue p12.s\n\t");
+  asm volatile("ptrue p13.d\n\t");
+  asm volatile("pfalse p14.b\n\t");
+  asm volatile("ptrue p15.b\n\t");
+
+  asm volatile("cpy  z0.b, p0/z, #1\n\t");
+  asm volatile("cpy  z1.b, p5/z, #2\n\t");
+  asm volatile("cpy  z2.b, p10/z, #3\n\t");
+  asm volatile("cpy  z3.b, p15/z, #4\n\t");
+  asm volatile("cpy  z4.b, p0/z, #5\n\t");
+  asm volatile("cpy  z5.b, p5/z, #6\n\t");
+  asm volatile("cpy  z6.b, p10/z, #7\n\t");
+  asm volatile("cpy  z7.b, p15/z, #8\n\t");
+  asm volatile("cpy  z8.b, p0/z, #9\n\t");
+  asm volatile("cpy  z9.b, p5/z, #10\n\t");
+  asm volatile("cpy  z10.b, p10/z, #11\n\t");
+  asm volatile("cpy  z11.b, p15/z, #12\n\t");
+  asm volatile("cpy  z12.b, p0/z, #13\n\t");
+  asm volatile("cpy  z13.b, p5/z, #14\n\t");
+  asm volatile("cpy  z14.b, p10/z, #15\n\t");
+  asm volatile("cpy  z15.b, p15/z, #16\n\t");
+  asm volatile("cpy  z16.b, p0/z, #17\n\t");
+  asm volatile("cpy  z17.b, p5/z, #18\n\t");
+  asm volatile("cpy  z18.b, p10/z, #19\n\t");
+  asm volatile("cpy  z19.b, p15/z, #20\n\t");
+  asm volatile("cpy  z20.b, p0/z, #21\n\t");
+  asm volatile("cpy  z21.b, p5/z, #22\n\t");
+  asm volatile("cpy  z22.b, p10/z, #23\n\t");
+  asm volatile("cpy  z23.b, p15/z, #24\n\t");
+  asm volatile("cpy  z24.b, p0/z, #25\n\t");
+  asm volatile("cpy  z25.b, p5/z, #26\n\t");
+  asm volatile("cpy  z26.b, p10/z, #27\n\t");
+  asm volatile("cpy  z27.b, p15/z, #28\n\t");
+  asm volatile("cpy  z28.b, p0/z, #29\n\t");
+  asm volatile("cpy  z29.b, p5/z, #30\n\t");
+  asm volatile("cpy  z30.b, p10/z, #31\n\t");
+  asm volatile("cpy  z31.b, p15/z, #32\n\t");
+}
+
+// Write something different so we will know if we didn't restore them
+// correctly.
+void write_sve_regs_expr() {
+  asm volatile("pfalse p0.b\n\t");
+  asm volatile("wrffr p0.b\n\t");
+  asm volatile("pfalse p1.b\n\t");
+  asm volatile("pfalse p2.b\n\t");
+  asm volatile("pfalse p3.b\n\t");
+  asm volatile("ptrue p4.b\n\t");
+  asm volatile("pfalse p5.b\n\t");
+  asm volatile("pfalse p6.b\n\t");
+  asm volatile("pfalse p7.b\n\t");
+  asm volatile("pfalse p8.b\n\t");
+  asm volatile("ptrue p9.b\n\t");
+  asm volatile("pfalse p10.b\n\t");
+  asm volatile("pfalse p11.b\n\t");
+  asm volatile("pfalse p12.b\n\t");
+  asm volatile("pfalse p13.b\n\t");
+  asm volatile

[Lldb-commits] [PATCH] D154927: [lldb][AArch64] Add SME's streaming vector control register

[David Spickett via Phabricator via lldb-commits]

DavidSpickett updated this revision to Diff 556854.
DavidSpickett added a comment.

Rebase, use new sme_pseudo_regs naming.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D154927/new/

https://reviews.llvm.org/D154927

Files:
  lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp
  lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.h
  lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.cpp
  
lldb/test/API/commands/register/register/aarch64_dynamic_regset/TestArm64DynamicRegsets.py
  
lldb/test/API/commands/register/register/aarch64_sve_registers/rw_access_static_config/TestSVERegisters.py
  
lldb/test/API/commands/register/register/aarch64_sve_registers/rw_access_static_config/main.c
  
lldb/test/API/commands/register/register/aarch64_za_register/za_save_restore/TestZARegisterSaveRestore.py

Index: lldb/test/API/commands/register/register/aarch64_za_register/za_save_restore/TestZARegisterSaveRestore.py
===
--- lldb/test/API/commands/register/register/aarch64_za_register/za_save_restore/TestZARegisterSaveRestore.py
+++ lldb/test/API/commands/register/register/aarch64_za_register/za_save_restore/TestZARegisterSaveRestore.py
@@ -164,6 +164,10 @@
 self.runCmd("register read " + sve_reg_names)
 sve_values = self.res.GetOutput()
 
+svcr_value = 1 if sve_mode == Mode.SSVE else 0
+if za_state == ZA.Enabled:
+svcr_value += 2
+
 def check_regs():
 if za_state == ZA.Enabled:
 self.check_za(start_vl)
@@ -175,6 +179,7 @@
 self.assertEqual(start_vg, self.read_vg())
 
 self.expect("register read " + sve_reg_names, substrs=[sve_values])
+self.expect("register read svcr", substrs=["0x{:016x}".format(svcr_value)])
 
 for expr in exprs:
 expr_cmd = "expression {}()".format(expr)
Index: lldb/test/API/commands/register/register/aarch64_sve_registers/rw_access_static_config/main.c
===
--- lldb/test/API/commands/register/register/aarch64_sve_registers/rw_access_static_config/main.c
+++ lldb/test/API/commands/register/register/aarch64_sve_registers/rw_access_static_config/main.c
@@ -5,7 +5,7 @@
 #define PR_SME_SET_VL 63
 #endif
 
-#define SMSTART() asm volatile("msr  s0_3_c4_c7_3, xzr" /*smstart*/)
+#define SMSTART_SM() asm volatile("msr  s0_3_c4_c3_3, xzr" /*smstart sm*/)
 
 void write_sve_regs() {
   // We assume the smefa64 feature is present, which allows ffr access
@@ -126,18 +126,18 @@
   // Note that doing a syscall brings you back to non-streaming mode, so we
   // don't need to SMSTOP here.
   if (streaming)
-SMSTART();
+SMSTART_SM();
   write_sve_regs_expr();
   prctl(SET_VL_OPT, 8 * 4);
   if (streaming)
-SMSTART();
+SMSTART_SM();
   write_sve_regs_expr();
   return 1;
 }
 
 int main() {
 #ifdef START_SSVE
-  SMSTART();
+  SMSTART_SM();
 #endif
   write_sve_regs();
 
Index: lldb/test/API/commands/register/register/aarch64_sve_registers/rw_access_static_config/TestSVERegisters.py
===
--- lldb/test/API/commands/register/register/aarch64_sve_registers/rw_access_static_config/TestSVERegisters.py
+++ lldb/test/API/commands/register/register/aarch64_sve_registers/rw_access_static_config/TestSVERegisters.py
@@ -24,7 +24,15 @@
 reg_value.GetByteSize(), expected, 'Verify "%s" == %i' % (name, expected)
 )
 
-def check_sve_regs_read(self, z_reg_size):
+def check_sve_regs_read(self, z_reg_size, expected_mode):
+if self.isAArch64SME():
+# This test uses SMSTART SM, which only enables streaming mode,
+# leaving ZA disabled.
+expected_value = "1" if expected_mode == Mode.SSVE else "0"
+self.expect(
+"register read svcr", substrs=["0x000" + expected_value]
+)
+
 p_reg_size = int(z_reg_size / 8)
 
 for i in range(32):
@@ -168,7 +176,7 @@
 
 vg_reg_value = sve_registers.GetChildMemberWithName("vg").GetValueAsUnsigned()
 z_reg_size = vg_reg_value * 8
-self.check_sve_regs_read(z_reg_size)
+self.check_sve_regs_read(z_reg_size, start_mode)
 
 # Evaluate simple expression and print function expr_eval_func address.
 self.expect("expression expr_eval_func", substrs=["= 0x"])
@@ -184,7 +192,7 @@
 
 # We called a jitted function above which must not have changed SVE
 # vector length or register values.
-self.check_sve_regs_read(z_reg_size)
+self.check_sve_regs_read(z_reg_size, start_mode)
 
 self.check_sve_regs_read_after_write(z_reg_size)
 
Index: lldb/test/API/commands/register/register/aarch64_dynamic_regset/TestArm64DynamicRegsets.py
==

[Lldb-commits] [lldb] [NFC][CodeGen] Change CodeGenOpt::Level/CodeGenFileType into enum classes (PR #66295)

[Paul T Robinson via lldb-commits]

@@ -661,27 +661,27 @@ static bool FixupInvocation(CompilerInvocation 
&Invocation,
 
 static unsigned getOptimizationLevel(ArgList &Args, InputKind IK,
  DiagnosticsEngine &Diags) {
-  unsigned DefaultOpt = llvm::CodeGenOpt::None;
+  unsigned DefaultOpt = 0;
   if ((IK.getLanguage() == Language::OpenCL ||
IK.getLanguage() == Language::OpenCLCXX) &&
   !Args.hasArg(OPT_cl_opt_disable))
-DefaultOpt = llvm::CodeGenOpt::Default;
+DefaultOpt = 2;

pogo59 wrote:

Actually it looks to me like clang only cares about 0/not-0, and the specific 
non-zero number is irrelevant. So, internally clang codegen would be better off 
with a simple Optimize bool. (It looks like LangOpts does it this way already.) 
CodeGenOpts probably does need to track the actual user-specified level to pass 
down to LLVM, but it doesn't need it for its own purposes.

https://github.com/llvm/llvm-project/pull/66295
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D158500: [lldb][AArch64] Linux corefile support for SME

[David Spickett via Phabricator via lldb-commits]

DavidSpickett updated this revision to Diff 556855.
DavidSpickett added a comment.

sme_regs -> sme_pseudo_regs and rebase.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D158500/new/

https://reviews.llvm.org/D158500

Files:
  lldb/source/Plugins/Process/Utility/RegisterContextPOSIX_arm64.h
  lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm64.cpp
  lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm64.h
  lldb/source/Plugins/Process/elf-core/RegisterUtilities.h
  lldb/test/API/linux/aarch64/sme_core_file/TestAArch64LinuxSMECoreFile.py
  lldb/test/API/linux/aarch64/sme_core_file/core_0_16_32_1
  lldb/test/API/linux/aarch64/sme_core_file/core_0_32_16_0
  lldb/test/API/linux/aarch64/sme_core_file/core_1_16_32_0
  lldb/test/API/linux/aarch64/sme_core_file/core_1_32_16_1
  lldb/test/API/linux/aarch64/sme_core_file/main.c

Index: lldb/test/API/linux/aarch64/sme_core_file/main.c
===
--- /dev/null
+++ lldb/test/API/linux/aarch64/sme_core_file/main.c
@@ -0,0 +1,140 @@
+// clang-format off
+// Compile with:
+// clang -target aarch64-unknown-linux-gnu main.c -o a.out -g -march=armv8.6-a+sve+sme
+//
+// For minimal corefile size, do this before running the program:
+// echo 0x20 > /proc/self/coredeump_filter
+//
+// Must be run on a system that has SVE and SME, including the smefa64
+// extension. Example command:
+// main 0 32 64 1
+//
+// This would not enter streaming mode, set non-streaming VL to 32
+// bytes, streaming VL to 64 bytes and enable ZA.
+// clang-format on
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#ifndef PR_SME_SET_VL
+#define PR_SME_SET_VL 63
+#endif
+
+#define SM_INST(c) asm volatile("msr s0_3_c4_c" #c "_3, xzr")
+#define SMSTART_SM SM_INST(3)
+#define SMSTART_ZA SM_INST(5)
+
+void set_sve_registers() {
+  // We assume the smefa64 feature is present, which allows ffr access
+  // in streaming mode.
+  asm volatile("setffr\n\t");
+  asm volatile("ptrue p0.b\n\t");
+  asm volatile("ptrue p1.h\n\t");
+  asm volatile("ptrue p2.s\n\t");
+  asm volatile("ptrue p3.d\n\t");
+  asm volatile("pfalse p4.b\n\t");
+  asm volatile("ptrue p5.b\n\t");
+  asm volatile("ptrue p6.h\n\t");
+  asm volatile("ptrue p7.s\n\t");
+  asm volatile("ptrue p8.d\n\t");
+  asm volatile("pfalse p9.b\n\t");
+  asm volatile("ptrue p10.b\n\t");
+  asm volatile("ptrue p11.h\n\t");
+  asm volatile("ptrue p12.s\n\t");
+  asm volatile("ptrue p13.d\n\t");
+  asm volatile("pfalse p14.b\n\t");
+  asm volatile("ptrue p15.b\n\t");
+
+  asm volatile("cpy  z0.b, p0/z, #1\n\t");
+  asm volatile("cpy  z1.b, p5/z, #2\n\t");
+  asm volatile("cpy  z2.b, p10/z, #3\n\t");
+  asm volatile("cpy  z3.b, p15/z, #4\n\t");
+  asm volatile("cpy  z4.b, p0/z, #5\n\t");
+  asm volatile("cpy  z5.b, p5/z, #6\n\t");
+  asm volatile("cpy  z6.b, p10/z, #7\n\t");
+  asm volatile("cpy  z7.b, p15/z, #8\n\t");
+  asm volatile("cpy  z8.b, p0/z, #9\n\t");
+  asm volatile("cpy  z9.b, p5/z, #10\n\t");
+  asm volatile("cpy  z10.b, p10/z, #11\n\t");
+  asm volatile("cpy  z11.b, p15/z, #12\n\t");
+  asm volatile("cpy  z12.b, p0/z, #13\n\t");
+  asm volatile("cpy  z13.b, p5/z, #14\n\t");
+  asm volatile("cpy  z14.b, p10/z, #15\n\t");
+  asm volatile("cpy  z15.b, p15/z, #16\n\t");
+  asm volatile("cpy  z16.b, p0/z, #17\n\t");
+  asm volatile("cpy  z17.b, p5/z, #18\n\t");
+  asm volatile("cpy  z18.b, p10/z, #19\n\t");
+  asm volatile("cpy  z19.b, p15/z, #20\n\t");
+  asm volatile("cpy  z20.b, p0/z, #21\n\t");
+  asm volatile("cpy  z21.b, p5/z, #22\n\t");
+  asm volatile("cpy  z22.b, p10/z, #23\n\t");
+  asm volatile("cpy  z23.b, p15/z, #24\n\t");
+  asm volatile("cpy  z24.b, p0/z, #25\n\t");
+  asm volatile("cpy  z25.b, p5/z, #26\n\t");
+  asm volatile("cpy  z26.b, p10/z, #27\n\t");
+  asm volatile("cpy  z27.b, p15/z, #28\n\t");
+  asm volatile("cpy  z28.b, p0/z, #29\n\t");
+  asm volatile("cpy  z29.b, p5/z, #30\n\t");
+  asm volatile("cpy  z30.b, p10/z, #31\n\t");
+  asm volatile("cpy  z31.b, p15/z, #32\n\t");
+}
+
+void set_za_register(int streaming_vl) {
+#define MAX_VL_BYTES 256
+  uint8_t data[MAX_VL_BYTES];
+
+  for (unsigned i = 0; i < streaming_vl; ++i) {
+for (unsigned j = 0; j < MAX_VL_BYTES; ++j)
+  data[j] = i + 1;
+asm volatile("mov w12, %w0\n\t"
+ "ldr za[w12, 0], [%1]\n\t" ::"r"(i),
+ "r"(&data)
+ : "w12");
+  }
+}
+
+void set_tpidr2(uint64_t value) {
+  __asm__ volatile("msr S3_3_C13_C0_5, %0" ::"r"(value));
+}
+
+int main(int argc, char **argv) {
+  // Arguments:
+  //  SVE mode: 1 for streaming SVE (SSVE), any other value
+  //  for non-streaming SVE mode.
+  //   Non-Streaming Vector length: In bytes, an integer e.g. "32".
+  //   Streaming Vector length: As above, but for streaming mode.
+  //   ZA mode: 1 for enabled, any other value for disabled.
+  if (argc != 5)
+return 1;

[Lldb-commits] [PATCH] D158506: [lldb][AArch64] Add release notes and documentation for SME

[David Spickett via Phabricator via lldb-commits]

DavidSpickett updated this revision to Diff 556856.
DavidSpickett added a comment.

Rebase


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D158506/new/

https://reviews.llvm.org/D158506

Files:
  lldb/docs/index.rst
  lldb/docs/use/aarch64-linux.rst
  llvm/docs/ReleaseNotes.rst

Index: llvm/docs/ReleaseNotes.rst
===
--- llvm/docs/ReleaseNotes.rst
+++ llvm/docs/ReleaseNotes.rst
@@ -183,6 +183,10 @@
 * Methods in SBHostOS related to threads have had their implementations
   removed. These methods will return a value indicating failure.
 
+* LLDB now supports debugging the Scalable Matrix Extension (SME) on AArch64
+  Linux for both running processes and core files. For details refer to the
+  `AArch64 Linux documentation `_.
+
 Changes to Sanitizers
 -
 * HWASan now defaults to detecting use-after-scope bugs.
Index: lldb/docs/use/aarch64-linux.rst
===
--- /dev/null
+++ lldb/docs/use/aarch64-linux.rst
@@ -0,0 +1,190 @@
+Using LLDB On AArch64 Linux
+===
+
+This page explains the details of debugging certain AArch64 extensions using
+LLDB. If something is not mentioned here, it likely works as you would expect.
+
+This is not a replacement for ptrace and Linux Kernel documentation. This covers
+how LLDB has chosen to use those things and how that effects your experience as
+a user.
+
+Scalable Vector Extension (SVE)
+---
+
+See `here `__
+to learn about the extension and `here `__
+for the Linux Kernel's handling of it.
+
+In LLDB you will be able to see the following new registers:
+
+* ``z0-z31`` vector registers, each one has size equal to the vector length.
+* ``p0-p15`` predicate registers, each one containing 1 bit per byte in the vector
+  length. Making each one vector length / 8 sized.
+* ``ffr`` the first fault register, same size as a predicate register.
+* ``vg``, the vector length in "granules". Each granule is 8 bytes.
+
+.. code-block::
+
+   Scalable Vector Extension Registers:
+ vg = 0x0002
+ z0 = {0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 <...> }
+   <...>
+ p0 = {0xff 0xff}
+   <...>
+ffr = {0xff 0xff}
+
+The example above has a vector length of 16 bytes. Within LLDB you will always
+see "vg" as in the ``vg`` register, which is 2 in this case (8*2 = 16).
+Elsewhere you may see "vq" which is the vector length in quadwords (16 bytes)
+elsewhere. Where you see "vl", it is in bytes.
+
+Changing the Vector Length
+..
+
+While you can count the size of a P or Z register, it is intended that ``vg`` be
+used to find the current vector length.
+
+vg can be written. Writing the current vector length changes nothing. If you
+increase the vector length, the registers will likely be reset to 0. If you
+decrease it, LLDB will truncate the Z registers but everything else will be reset
+to 0.
+
+Generally you should not assume that SVE state after changing the vector length
+is in any way the same as it was previously. If you need to do it, do it before
+a function's first use of SVE.
+
+Z Register Presentation
+...
+
+LLDB makes no attempt to predict how an SVE Z register will be used. Even if the
+next SVE instruction (which may some distance away) would use, for example, 32
+bit elements, LLDB prints ``z0`` as single bytes.
+
+If you know what format you are going to use, give a format option::
+
+  (lldb) register read z0 -f uint32_t[]
+  z0 = {0x01010101 0x01010101 0x01010101 0x01010101}
+
+FPSIMD and SVE Modes
+
+
+Prior to the debugee's first use of SVE, it is in what the Linux Kernel terms
+SIMD mode. Only the FPU is being used. In this state LLDB will still show the
+SVE registers however the values are simply the FPU values zero extended up to
+the vector length.
+
+On first access to SVE, the process goes into SVE mode. Now the Z values are
+in the real Z registers.
+
+You can also trigger this with LLDB by writing to an SVE register. Note that
+there is no way to undo this change from within LLDB. However, the debugee
+itself could do something to end up back in SIMD mode.
+
+Expression evaluation
+.
+
+If you evaluate an expression, all SVE state is saved prior to, and restored
+after the expression has been evaluated. Including the register values and
+vector length.
+
+Scalable Matrix Extension (SME)
+---
+
+See `here `__
+to learn about the extension and `h

[Lldb-commits] [PATCH] D159505: [lldb][AArch64] Add testing for SME's ZA and SVG registers

[David Spickett via Phabricator via lldb-commits]

DavidSpickett added a comment.

I'll hold off landing any of the prior patches until this is reviewed, in case 
I have to go back and move things.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D159505/new/

https://reviews.llvm.org/D159505

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D159503: [lldb][AArch64] Add SME streaming vector length pseduo register

[Muhammad Omair Javaid via Phabricator via lldb-commits]

omjavaid accepted this revision.
omjavaid added a comment.
This revision is now accepted and ready to land.

This is LGTM as you suggested pending child reviews.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D159503/new/

https://reviews.llvm.org/D159503

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D159504: [lldb][AArch64] Implement resizing of SME's ZA register

[Muhammad Omair Javaid via Phabricator via lldb-commits]

omjavaid accepted this revision.
omjavaid added a comment.
This revision is now accepted and ready to land.

This look good


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D159504/new/

https://reviews.llvm.org/D159504

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][Docs] Update links in Data Formatter section (PR #66474)

[Jonas Devlieghere via lldb-commits]

https://github.com/JDevlieghere approved this pull request.


https://github.com/llvm/llvm-project/pull/66474
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][Docs] Update links in Data Formatter section (PR #66474)

[David Spickett via lldb-commits]

https://github.com/DavidSpickett closed 
https://github.com/llvm/llvm-project/pull/66474
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] 1d75d42 - [lldb][Docs] Update links in Data Formatter section (#66474)

[via lldb-commits]

Author: David Spickett
Date: 2023-09-15T16:39:49+01:00
New Revision: 1d75d426895b9d54509cfafa53d01bb5bd6266d0

URL: 
https://github.com/llvm/llvm-project/commit/1d75d426895b9d54509cfafa53d01bb5bd6266d0
DIFF: 
https://github.com/llvm/llvm-project/commit/1d75d426895b9d54509cfafa53d01bb5bd6266d0.diff

LOG: [lldb][Docs] Update links in Data Formatter section (#66474)

Neither actually linked anywhere, but I did find a good target for the
introduction.

For the architecture side I don't see a page that would fit, so I've
just removed the sentence.

Added: 


Modified: 
lldb/docs/resources/overview.rst

Removed: 




diff  --git a/lldb/docs/resources/overview.rst 
b/lldb/docs/resources/overview.rst
index b76af384e08b978..054fcbfea2164c2 100644
--- a/lldb/docs/resources/overview.rst
+++ b/lldb/docs/resources/overview.rst
@@ -80,8 +80,8 @@ wide variety of classes are implemented:
 - Source manager
 - Value objects
 
-Dataformatters
---
+Data Formatters
+---
 
 A collection of classes that implement the data formatters subsystem.
 
@@ -92,9 +92,7 @@ layers to the implementation: DataVisualization at the 
highest end of the
 spectrum, backed by classes implementing individual formatters, matching rules,
 etc.
 
-For a general user-level introduction to data formatters, you can look here.
-
-More details on the architecture are to be found here.
+For an introduction to data formatters, see :doc:`/use/variable`.
 
 Expression
 --



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][Docs] Update links in Data Formatter section (PR #66474)

[Jonas Devlieghere via lldb-commits]

JDevlieghere wrote:

> Would skip review, but it's here on the off chance @JDevlieghere knows where 
> the second link was supposed to go to.

The original HTML had the following links:

```
For a general user-level introduction to data formatters, you can look here.
More details on the architecture are to be found here.```

The new link is correct but it seems like I didn't port over the other page, 
probably because I didn't realize there were two pages with the same name. I 
didn't read through the second page yet, so I can't tell yet how relevant it 
still is, but I'll put up a PR and we can iterate on it. 

https://github.com/llvm/llvm-project/pull/66474
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] Add `target modules dump separate-debug-info` (PR #66035)

[via lldb-commits]

https://github.com/jimingham commented:

I think it would be easier to read the output if you made a separate column for 
"error".  If you imagine a listing where there are 100 OSO's of which 10 are 
missing, the paths are going to jump over because of the "error: ..." at the 
beginning of those lines making it messy for your eyes to track.  Seems like 
there are only two possible errors "file not found" and "file out of date", so 
it seems like we should be able to make a fairly short error column after the 
ID and then the path?

If you're tired of mucking with tables at this point, this isn't required, but 
I think it would make it easier to scan. 

https://github.com/llvm/llvm-project/pull/66035
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] 4a030f5 - [lldb-vscode][NFC] Access a pointee type in a simpler way

[walter erquinigo via lldb-commits]

Author: walter erquinigo
Date: 2023-09-15T12:26:04-04:00
New Revision: 4a030f5b245b63fe09c29686c50d40796c987d96

URL: 
https://github.com/llvm/llvm-project/commit/4a030f5b245b63fe09c29686c50d40796c987d96
DIFF: 
https://github.com/llvm/llvm-project/commit/4a030f5b245b63fe09c29686c50d40796c987d96.diff

LOG: [lldb-vscode][NFC] Access a pointee type in a simpler way

The new code is a bit simpler bit achieves the same goal. A small test was 
added just in case.

Added: 


Modified: 
lldb/test/API/tools/lldb-vscode/evaluate/TestVSCode_evaluate.py
lldb/tools/lldb-vscode/JSONUtils.cpp

Removed: 




diff  --git a/lldb/test/API/tools/lldb-vscode/evaluate/TestVSCode_evaluate.py 
b/lldb/test/API/tools/lldb-vscode/evaluate/TestVSCode_evaluate.py
index d0172ef9160fdd6..3cfe02ef6aa1576 100644
--- a/lldb/test/API/tools/lldb-vscode/evaluate/TestVSCode_evaluate.py
+++ b/lldb/test/API/tools/lldb-vscode/evaluate/TestVSCode_evaluate.py
@@ -62,6 +62,9 @@ def run_test_evaluate_expressions(
 self.assertEvaluate(
 "struct1", "{foo:15}" if enableAutoVariableSummaries else 
"my_struct @ 0x"
 )
+self.assertEvaluate(
+"struct2", "{foo:16}" if enableAutoVariableSummaries else "0x.*"
+)
 self.assertEvaluate("struct1.foo", "15")
 self.assertEvaluate("struct2->foo", "16")
 

diff  --git a/lldb/tools/lldb-vscode/JSONUtils.cpp 
b/lldb/tools/lldb-vscode/JSONUtils.cpp
index 0d149ff27fd3d3e..c6b422e4d7a02e6 100644
--- a/lldb/tools/lldb-vscode/JSONUtils.cpp
+++ b/lldb/tools/lldb-vscode/JSONUtils.cpp
@@ -203,10 +203,9 @@ static bool ShouldBeDereferencedForSummary(lldb::SBValue 
&v) {
   if (!v.GetType().IsPointerType() && !v.GetType().IsReferenceType())
 return false;
 
-  // If it's a pointer to a pointer, we don't dereference to avoid confusing
+  // If we are referencing a pointer, we don't dereference to avoid confusing
   // the user with the addresses that could shown in the summary.
-  if (v.GetType().IsPointerType() &&
-  v.GetType().GetDereferencedType().IsPointerType())
+  if (v.Dereference().GetType().IsPointerType())
 return false;
 
   // If it's synthetic or a pointer to a basic type that provides a summary, we



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] Add `target modules dump separate-debug-info` (PR #66035)

[Greg Clayton via lldb-commits]

clayborg wrote:

> I think it would be easier to read the output if you made a separate column 
> for "error". If you imagine a listing where there are 100 OSO's of which 10 
> are missing, the paths are going to jump over because of the "error: ..." at 
> the beginning of those lines making it messy for your eyes to track. Seems 
> like there are only two possible errors "file not found" and "file out of 
> date", so it seems like we should be able to make a fairly short error column 
> after the ID and then the path?

The errors are quite long as they mention the offending path to the OSO and the 
OSO paths are often very long, so you would need to run through the results to 
calculate the max width of the OSO path and then you would almost certainly 
overlflow off the right edge of the terminal if you also show the error string.

This patch currently doesn't show the OSO path if there is an error , so we 
show the error in place of the OSO path as the error string contains the path 
in the error text. Would your prefer to always show the modtime + oso path and 
then add the error on the next line?


https://github.com/llvm/llvm-project/pull/66035
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Revive internal data formatter documentation (PR #66527)

[Jonas Devlieghere via lldb-commits]

https://github.com/JDevlieghere created 
https://github.com/llvm/llvm-project/pull/66527

This is a (rough) port of architecture/varformats.html page that got lost 
during the migration to RST in edb874b. I'm not sure how much of its content is 
still relevant today. However, the page is pretty extensive and seems like it's 
worth preserving.

>From f4606b818ff86923668b032b6f8ba82ef15ad6cf Mon Sep 17 00:00:00 2001
From: Jonas Devlieghere 
Date: Fri, 15 Sep 2023 09:31:22 -0700
Subject: [PATCH] [lldb] Revive internal data formatter documentation

This is a (rough) port of architecture/varformats.html page that got
lost during the migration to RST in edb874b. I'm not sure how much of
its content is still relevant today. However, the page is pretty
extensive and seems like it's worth preserving.
---
 lldb/docs/index.rst|   1 +
 lldb/docs/resources/dataformatters.rst | 436 +
 2 files changed, 437 insertions(+)
 create mode 100644 lldb/docs/resources/dataformatters.rst

diff --git a/lldb/docs/index.rst b/lldb/docs/index.rst
index 3b65f81a6d74936..2eb57cefbd883ea 100644
--- a/lldb/docs/index.rst
+++ b/lldb/docs/index.rst
@@ -151,6 +151,7 @@ interesting areas to contribute to lldb.
resources/debugging
resources/fuzzing
resources/sbapi
+   resources/dataformatters
resources/extensions
resources/caveats
resources/projects
diff --git a/lldb/docs/resources/dataformatters.rst 
b/lldb/docs/resources/dataformatters.rst
new file mode 100644
index 000..49bab3a091a166c
--- /dev/null
+++ b/lldb/docs/resources/dataformatters.rst
@@ -0,0 +1,436 @@
+Data Formatters
+===
+
+This page is an introduction to the design of the LLDB data formatters
+subsystem. The intended target audience are people interested in understanding
+or modifying the formatters themselves rather than writing a specific data
+formatter. For this latter purpose, the user documentation about formatters is
+the main relevant document which one should refer to.
+
+This page also highlights some open areas for improvement to the general
+subsystem, and more evolutions not anticipated here are certainly possible.
+
+Overview
+
+
+The LLDB data formatters subsystem is used to allow the debugger as well as the
+end-users to customize the way their variables look upon inspection in the user
+interface (be it the command line tool, or one of the several GUIs that are
+backed by LLDB)
+
+To this aim, they are hooked into the ValueObjects model, in order to provide
+entry points through which such customization questions can be answered. For
+example what format should this number be printed as? How many child elements
+does this ``std::vector`` have?
+
+The architecture of the subsystem is layered, with the highest level layer
+being the user visible interaction features (e.g. the ``type ***`` commands,
+the SB classes, ...). Other layers of interest that will be analyzed in this
+document include
+
+* Classes implementing individual data formatter types
+* Classes implementing formatters navigation, discovery and categorization
+* The ``FormatManager`` layer
+* The ``DataVisualization`` layer
+* The SWIG <> LLDB communication layer
+
+Data Formatter Types
+
+
+As described in the user documentation, there are four types of formatters:
+
+* Formats
+* Summaries
+* Filters
+* Synthetic children
+
+Formatters have descriptor classes, ``Type*Impl``, which contain at least a
+"Flags" nested object, which contains both rules to be used by the matching
+algorithm (e.g. should the formatter for type Foo apply to a Foo*?) or rules to
+be used by the formatter itself (e.g. is this summary a oneliner?).
+
+Individual formatter descriptor classes then also contain data items useful to
+them for performing their functionality. For instance ``TypeFormatImpl``
+(backing formats) contains an ``lldb::Format`` that is the format to then be
+applied were this formatter to be selected. Upon issuing a ``type format add``
+a new ``TypeFormatImpl`` is created that wraps the user-specified format, and
+matching options:
+
+::
+
+  entry.reset(new TypeFormatImpl(
+  format, TypeFormatImpl::Flags()
+  .SetCascades(m_command_options.m_cascade)
+  .SetSkipPointers(m_command_options.m_skip_pointers)
+  .SetSkipReferences(m_command_options.m_skip_references)));
+
+
+While formats are fairly simple and only implemented by one class, the other
+formatter types are backed by a class hierarchy.
+
+Summaries, for instance, can exist in one of three "flavors":
+
+* Summary strings
+* Python script
+* Native C++
+
+The base class for summaries, ``TypeSummaryImpl``, is a pure virtual class that
+wraps, again, the Flags, and exports among others:
+
+::
+
+  virtual bool FormatObject (ValueObject *valobj, std::string& dest) = 0;
+
+
+This is the core entry point, which allows subclasses to specify their mode of
+operation.
+
+``StringSu

[Lldb-commits] [lldb] [lldb] Revive internal data formatter documentation (PR #66527)

[via lldb-commits]

llvmbot wrote:




@llvm/pr-subscribers-lldb


Changes

This is a (rough) port of architecture/varformats.html page that got lost 
during the migration to RST in edb874b. I'm not sure how much of its content is 
still relevant today. However, the page is pretty extensive and seems like it's 
worth preserving.
---

Patch is 23.57 KiB, truncated to 20.00 KiB below, full version: 
https://github.com/llvm/llvm-project/pull/66527.diff


2 Files Affected:

- (modified) lldb/docs/index.rst (+1) 
- (added) lldb/docs/resources/dataformatters.rst (+436) 


``diff
diff --git a/lldb/docs/index.rst b/lldb/docs/index.rst
index 3b65f81a6d74936..2eb57cefbd883ea 100644
--- a/lldb/docs/index.rst
+++ b/lldb/docs/index.rst
@@ -151,6 +151,7 @@ interesting areas to contribute to lldb.
resources/debugging
resources/fuzzing
resources/sbapi
+   resources/dataformatters
resources/extensions
resources/caveats
resources/projects
diff --git a/lldb/docs/resources/dataformatters.rst 
b/lldb/docs/resources/dataformatters.rst
new file mode 100644
index 000..49bab3a091a166c
--- /dev/null
+++ b/lldb/docs/resources/dataformatters.rst
@@ -0,0 +1,436 @@
+Data Formatters
+===
+
+This page is an introduction to the design of the LLDB data formatters
+subsystem. The intended target audience are people interested in understanding
+or modifying the formatters themselves rather than writing a specific data
+formatter. For this latter purpose, the user documentation about formatters is
+the main relevant document which one should refer to.
+
+This page also highlights some open areas for improvement to the general
+subsystem, and more evolutions not anticipated here are certainly possible.
+
+Overview
+
+
+The LLDB data formatters subsystem is used to allow the debugger as well as the
+end-users to customize the way their variables look upon inspection in the user
+interface (be it the command line tool, or one of the several GUIs that are
+backed by LLDB)
+
+To this aim, they are hooked into the ValueObjects model, in order to provide
+entry points through which such customization questions can be answered. For
+example what format should this number be printed as? How many child elements
+does this ``std::vector`` have?
+
+The architecture of the subsystem is layered, with the highest level layer
+being the user visible interaction features (e.g. the ``type ***`` commands,
+the SB classes, ...). Other layers of interest that will be analyzed in this
+document include
+
+* Classes implementing individual data formatter types
+* Classes implementing formatters navigation, discovery and categorization
+* The ``FormatManager`` layer
+* The ``DataVisualization`` layer
+* The SWIG <> LLDB communication layer
+
+Data Formatter Types
+
+
+As described in the user documentation, there are four types of formatters:
+
+* Formats
+* Summaries
+* Filters
+* Synthetic children
+
+Formatters have descriptor classes, ``Type*Impl``, which contain at least a
+"Flags" nested object, which contains both rules to be used by the matching
+algorithm (e.g. should the formatter for type Foo apply to a Foo*?) or rules to
+be used by the formatter itself (e.g. is this summary a oneliner?).
+
+Individual formatter descriptor classes then also contain data items useful to
+them for performing their functionality. For instance ``TypeFormatImpl``
+(backing formats) contains an ``lldb::Format`` that is the format to then be
+applied were this formatter to be selected. Upon issuing a ``type format add``
+a new ``TypeFormatImpl`` is created that wraps the user-specified format, and
+matching options:
+
+::
+
+  entry.reset(new TypeFormatImpl(
+  format, TypeFormatImpl::Flags()
+  .SetCascades(m_command_options.m_cascade)
+  .SetSkipPointers(m_command_options.m_skip_pointers)
+  .SetSkipReferences(m_command_options.m_skip_references)));
+
+
+While formats are fairly simple and only implemented by one class, the other
+formatter types are backed by a class hierarchy.
+
+Summaries, for instance, can exist in one of three "flavors":
+
+* Summary strings
+* Python script
+* Native C++
+
+The base class for summaries, ``TypeSummaryImpl``, is a pure virtual class that
+wraps, again, the Flags, and exports among others:
+
+::
+
+  virtual bool FormatObject (ValueObject *valobj, std::string& dest) = 0;
+
+
+This is the core entry point, which allows subclasses to specify their mode of
+operation.
+
+``StringSummaryFormat``, which is the class that implements summary strings,
+does a check as to whether the summary is a one-liner, and if not, then uses
+its stored summary string to call into ``Debugger::FormatPrompt``, and obtain a
+string back, which it returns in ``dest`` as the resulting summary.
+
+For a Python summary, implemented in ``ScriptSummaryFormat``,
+``FormatObject()`` calls into the ``ScriptInterpreter`` which is supposed to
+hold the knowled

[Lldb-commits] [lldb] Add `target modules dump separate-debug-info` (PR #66035)

[via lldb-commits]

jimingham wrote:

> > I think it would be easier to read the output if you made a separate column 
> > for "error". If you imagine a listing where there are 100 OSO's of which 10 
> > are missing, the paths are going to jump over because of the "error: ..." 
> > at the beginning of those lines making it messy for your eyes to track. 
> > Seems like there are only two possible errors "file not found" and "file 
> > out of date", so it seems like we should be able to make a fairly short 
> > error column after the ID and then the path?
> 
> The errors are quite long as they mention the offending path to the OSO and 
> the OSO paths are often very long, so you would need to run through the 
> results to calculate the max width of the OSO path and then you would almost 
> certainly overlflow off the right edge of the terminal if you also show the 
> error string.
> 
> This patch currently doesn't show the OSO path if there is an error , so we 
> show the error in place of the OSO path as the error string contains the path 
> in the error text. Would your prefer to always show the modtime + oso path 
> and then add the error on the next line?

I was imaging something like:

```
(lldb) image dump separate-debug-info
Symbol file: /home/toyang/workspace/dwo-scratch/a.out
Type: "dwo"
Dwo ID Error Dwo Path
-- --- -
0x9a429da5abb6faae Missing "/home/toyang/workspace/dwo-scratch/a-main.dwo" for 
skeleton DIE 0x0014
0xbcc129959e76ff33 Missing "/home/toyang/workspace/dwo-scratch/a-foo.dwo" for 
skeleton DIE 0x003c
```
Or given that there aren't many errors possible, you could even do a one letter 
thing `S` for success, `M` for missing and `O` for out of date.

If the error was of the form "Not found: ..." or "Out of data:..." then you 
could pick off the error string.  You're in charge of the error string so you 
can arrange to emit it in a way that allows picking this info out of it easily. 
 And you don't need the path in the error since it's in the next "path" field 
anyway.

https://github.com/llvm/llvm-project/pull/66035
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Revive internal data formatter documentation (PR #66527)

[via lldb-commits]

https://github.com/jimingham approved this pull request.

I just did a quick scan but this all seems still pretty accurate, and useful as 
a middle-level description for people who need to work on the data formatter 
system in lldb.

https://github.com/llvm/llvm-project/pull/66527
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Revive internal data formatter documentation (PR #66527)

[Walter Erquinigo via lldb-commits]

@@ -0,0 +1,436 @@
+Data Formatters
+===
+
+This page is an introduction to the design of the LLDB data formatters
+subsystem. The intended target audience are people interested in understanding
+or modifying the formatters themselves rather than writing a specific data
+formatter. For this latter purpose, the user documentation about formatters is
+the main relevant document which one should refer to.
+
+This page also highlights some open areas for improvement to the general
+subsystem, and more evolutions not anticipated here are certainly possible.
+
+Overview
+
+
+The LLDB data formatters subsystem is used to allow the debugger as well as the
+end-users to customize the way their variables look upon inspection in the user
+interface (be it the command line tool, or one of the several GUIs that are
+backed by LLDB)
+
+To this aim, they are hooked into the ValueObjects model, in order to provide
+entry points through which such customization questions can be answered. For
+example what format should this number be printed as? How many child elements

walter-erquinigo wrote:

```suggestion
example: What format should this number be printed as? How many child elements
```

https://github.com/llvm/llvm-project/pull/66527
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Revive internal data formatter documentation (PR #66527)

[Walter Erquinigo via lldb-commits]

@@ -0,0 +1,436 @@
+Data Formatters
+===
+
+This page is an introduction to the design of the LLDB data formatters
+subsystem. The intended target audience are people interested in understanding
+or modifying the formatters themselves rather than writing a specific data
+formatter. For this latter purpose, the user documentation about formatters is
+the main relevant document which one should refer to.
+
+This page also highlights some open areas for improvement to the general
+subsystem, and more evolutions not anticipated here are certainly possible.
+
+Overview
+
+
+The LLDB data formatters subsystem is used to allow the debugger as well as the
+end-users to customize the way their variables look upon inspection in the user
+interface (be it the command line tool, or one of the several GUIs that are
+backed by LLDB)

walter-erquinigo wrote:

```suggestion
backed by LLDB).
```

https://github.com/llvm/llvm-project/pull/66527
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Revive internal data formatter documentation (PR #66527)

[Walter Erquinigo via lldb-commits]

https://github.com/walter-erquinigo edited 
https://github.com/llvm/llvm-project/pull/66527
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Revive internal data formatter documentation (PR #66527)

[Walter Erquinigo via lldb-commits]

@@ -0,0 +1,436 @@
+Data Formatters
+===
+
+This page is an introduction to the design of the LLDB data formatters
+subsystem. The intended target audience are people interested in understanding
+or modifying the formatters themselves rather than writing a specific data
+formatter. For this latter purpose, the user documentation about formatters is
+the main relevant document which one should refer to.
+
+This page also highlights some open areas for improvement to the general
+subsystem, and more evolutions not anticipated here are certainly possible.
+
+Overview
+
+
+The LLDB data formatters subsystem is used to allow the debugger as well as the
+end-users to customize the way their variables look upon inspection in the user
+interface (be it the command line tool, or one of the several GUIs that are
+backed by LLDB)
+
+To this aim, they are hooked into the ValueObjects model, in order to provide
+entry points through which such customization questions can be answered. For
+example what format should this number be printed as? How many child elements
+does this ``std::vector`` have?
+
+The architecture of the subsystem is layered, with the highest level layer
+being the user visible interaction features (e.g. the ``type ***`` commands,
+the SB classes, ...). Other layers of interest that will be analyzed in this
+document include
+
+* Classes implementing individual data formatter types
+* Classes implementing formatters navigation, discovery and categorization
+* The ``FormatManager`` layer
+* The ``DataVisualization`` layer
+* The SWIG <> LLDB communication layer
+
+Data Formatter Types
+
+
+As described in the user documentation, there are four types of formatters:
+
+* Formats
+* Summaries
+* Filters
+* Synthetic children
+
+Formatters have descriptor classes, ``Type*Impl``, which contain at least a
+"Flags" nested object, which contains both rules to be used by the matching
+algorithm (e.g. should the formatter for type Foo apply to a Foo*?) or rules to
+be used by the formatter itself (e.g. is this summary a oneliner?).
+
+Individual formatter descriptor classes then also contain data items useful to
+them for performing their functionality. For instance ``TypeFormatImpl``
+(backing formats) contains an ``lldb::Format`` that is the format to then be
+applied were this formatter to be selected. Upon issuing a ``type format add``
+a new ``TypeFormatImpl`` is created that wraps the user-specified format, and
+matching options:
+
+::
+
+  entry.reset(new TypeFormatImpl(
+  format, TypeFormatImpl::Flags()
+  .SetCascades(m_command_options.m_cascade)
+  .SetSkipPointers(m_command_options.m_skip_pointers)
+  .SetSkipReferences(m_command_options.m_skip_references)));
+
+
+While formats are fairly simple and only implemented by one class, the other
+formatter types are backed by a class hierarchy.
+
+Summaries, for instance, can exist in one of three "flavors":
+
+* Summary strings
+* Python script
+* Native C++
+
+The base class for summaries, ``TypeSummaryImpl``, is a pure virtual class that
+wraps, again, the Flags, and exports among others:
+
+::
+
+  virtual bool FormatObject (ValueObject *valobj, std::string& dest) = 0;
+
+
+This is the core entry point, which allows subclasses to specify their mode of
+operation.
+
+``StringSummaryFormat``, which is the class that implements summary strings,
+does a check as to whether the summary is a one-liner, and if not, then uses
+its stored summary string to call into ``Debugger::FormatPrompt``, and obtain a
+string back, which it returns in ``dest`` as the resulting summary.
+
+For a Python summary, implemented in ``ScriptSummaryFormat``,
+``FormatObject()`` calls into the ``ScriptInterpreter`` which is supposed to
+hold the knowledge on how to bridge back and forth with the scripting language
+(Python in the case of LLDB) in order to produce a valid string. Implementors
+of new ``ScriptInterpreters`` for other languages are expected to provide a
+``GetScriptedSummary()`` entrypoint for this purpose, if they desire to allow
+users to provide formatters in the new language
+
+Lastly, C++ summaries (``CXXFunctionSummaryFormat``), wrap a function pointer
+and call into it to execute their duty. It should be noted that there are no
+facilities for users to interact with C++ formatters, and as such they are
+extremely opaque, effectively being a thin wrapper between plain function
+pointers and the LLDB formatters subsystem.
+
+Also, dynamic loading of C++ formatters in LLDB is currently not implemented,
+and as such it is safe and reasonable for these formatters to deal with
+internal ``ValueObjects`` instances instead of public ``SBValue`` objects.
+
+An interesting data point is that summaries are expected to be stateless. While
+at the Python layer they are handed an ``SBValue`` (since nothing else could be
+visible for scripts), it is not expected that 

[Lldb-commits] [lldb] [lldb] Revive internal data formatter documentation (PR #66527)

[Walter Erquinigo via lldb-commits]

@@ -0,0 +1,436 @@
+Data Formatters
+===
+
+This page is an introduction to the design of the LLDB data formatters
+subsystem. The intended target audience are people interested in understanding
+or modifying the formatters themselves rather than writing a specific data
+formatter. For this latter purpose, the user documentation about formatters is
+the main relevant document which one should refer to.
+
+This page also highlights some open areas for improvement to the general
+subsystem, and more evolutions not anticipated here are certainly possible.
+
+Overview
+
+
+The LLDB data formatters subsystem is used to allow the debugger as well as the
+end-users to customize the way their variables look upon inspection in the user
+interface (be it the command line tool, or one of the several GUIs that are
+backed by LLDB)
+
+To this aim, they are hooked into the ValueObjects model, in order to provide
+entry points through which such customization questions can be answered. For
+example what format should this number be printed as? How many child elements
+does this ``std::vector`` have?
+
+The architecture of the subsystem is layered, with the highest level layer
+being the user visible interaction features (e.g. the ``type ***`` commands,
+the SB classes, ...). Other layers of interest that will be analyzed in this
+document include
+
+* Classes implementing individual data formatter types
+* Classes implementing formatters navigation, discovery and categorization
+* The ``FormatManager`` layer
+* The ``DataVisualization`` layer
+* The SWIG <> LLDB communication layer
+
+Data Formatter Types
+
+
+As described in the user documentation, there are four types of formatters:
+
+* Formats
+* Summaries
+* Filters
+* Synthetic children
+
+Formatters have descriptor classes, ``Type*Impl``, which contain at least a
+"Flags" nested object, which contains both rules to be used by the matching
+algorithm (e.g. should the formatter for type Foo apply to a Foo*?) or rules to
+be used by the formatter itself (e.g. is this summary a oneliner?).
+
+Individual formatter descriptor classes then also contain data items useful to
+them for performing their functionality. For instance ``TypeFormatImpl``
+(backing formats) contains an ``lldb::Format`` that is the format to then be
+applied were this formatter to be selected. Upon issuing a ``type format add``
+a new ``TypeFormatImpl`` is created that wraps the user-specified format, and
+matching options:
+
+::
+
+  entry.reset(new TypeFormatImpl(
+  format, TypeFormatImpl::Flags()
+  .SetCascades(m_command_options.m_cascade)
+  .SetSkipPointers(m_command_options.m_skip_pointers)
+  .SetSkipReferences(m_command_options.m_skip_references)));
+
+
+While formats are fairly simple and only implemented by one class, the other
+formatter types are backed by a class hierarchy.
+
+Summaries, for instance, can exist in one of three "flavors":
+
+* Summary strings
+* Python script
+* Native C++
+
+The base class for summaries, ``TypeSummaryImpl``, is a pure virtual class that
+wraps, again, the Flags, and exports among others:
+
+::
+
+  virtual bool FormatObject (ValueObject *valobj, std::string& dest) = 0;
+
+
+This is the core entry point, which allows subclasses to specify their mode of
+operation.
+
+``StringSummaryFormat``, which is the class that implements summary strings,
+does a check as to whether the summary is a one-liner, and if not, then uses
+its stored summary string to call into ``Debugger::FormatPrompt``, and obtain a
+string back, which it returns in ``dest`` as the resulting summary.
+
+For a Python summary, implemented in ``ScriptSummaryFormat``,
+``FormatObject()`` calls into the ``ScriptInterpreter`` which is supposed to
+hold the knowledge on how to bridge back and forth with the scripting language
+(Python in the case of LLDB) in order to produce a valid string. Implementors
+of new ``ScriptInterpreters`` for other languages are expected to provide a
+``GetScriptedSummary()`` entrypoint for this purpose, if they desire to allow

walter-erquinigo wrote:

```suggestion
``GetScriptedSummary()`` entry point for this purpose, if they desire to allow
```

https://github.com/llvm/llvm-project/pull/66527
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Revive internal data formatter documentation (PR #66527)

[Walter Erquinigo via lldb-commits]

@@ -0,0 +1,436 @@
+Data Formatters
+===
+
+This page is an introduction to the design of the LLDB data formatters
+subsystem. The intended target audience are people interested in understanding
+or modifying the formatters themselves rather than writing a specific data
+formatter. For this latter purpose, the user documentation about formatters is
+the main relevant document which one should refer to.
+
+This page also highlights some open areas for improvement to the general
+subsystem, and more evolutions not anticipated here are certainly possible.
+
+Overview
+
+
+The LLDB data formatters subsystem is used to allow the debugger as well as the
+end-users to customize the way their variables look upon inspection in the user
+interface (be it the command line tool, or one of the several GUIs that are
+backed by LLDB)
+
+To this aim, they are hooked into the ValueObjects model, in order to provide
+entry points through which such customization questions can be answered. For
+example what format should this number be printed as? How many child elements
+does this ``std::vector`` have?
+
+The architecture of the subsystem is layered, with the highest level layer
+being the user visible interaction features (e.g. the ``type ***`` commands,
+the SB classes, ...). Other layers of interest that will be analyzed in this
+document include
+
+* Classes implementing individual data formatter types
+* Classes implementing formatters navigation, discovery and categorization
+* The ``FormatManager`` layer
+* The ``DataVisualization`` layer
+* The SWIG <> LLDB communication layer
+
+Data Formatter Types
+
+
+As described in the user documentation, there are four types of formatters:
+
+* Formats
+* Summaries
+* Filters
+* Synthetic children
+
+Formatters have descriptor classes, ``Type*Impl``, which contain at least a
+"Flags" nested object, which contains both rules to be used by the matching
+algorithm (e.g. should the formatter for type Foo apply to a Foo*?) or rules to
+be used by the formatter itself (e.g. is this summary a oneliner?).
+
+Individual formatter descriptor classes then also contain data items useful to
+them for performing their functionality. For instance ``TypeFormatImpl``
+(backing formats) contains an ``lldb::Format`` that is the format to then be
+applied were this formatter to be selected. Upon issuing a ``type format add``
+a new ``TypeFormatImpl`` is created that wraps the user-specified format, and
+matching options:
+
+::
+
+  entry.reset(new TypeFormatImpl(
+  format, TypeFormatImpl::Flags()
+  .SetCascades(m_command_options.m_cascade)
+  .SetSkipPointers(m_command_options.m_skip_pointers)
+  .SetSkipReferences(m_command_options.m_skip_references)));
+
+
+While formats are fairly simple and only implemented by one class, the other
+formatter types are backed by a class hierarchy.
+
+Summaries, for instance, can exist in one of three "flavors":
+
+* Summary strings
+* Python script
+* Native C++
+
+The base class for summaries, ``TypeSummaryImpl``, is a pure virtual class that
+wraps, again, the Flags, and exports among others:
+
+::
+
+  virtual bool FormatObject (ValueObject *valobj, std::string& dest) = 0;
+
+
+This is the core entry point, which allows subclasses to specify their mode of
+operation.
+
+``StringSummaryFormat``, which is the class that implements summary strings,
+does a check as to whether the summary is a one-liner, and if not, then uses
+its stored summary string to call into ``Debugger::FormatPrompt``, and obtain a
+string back, which it returns in ``dest`` as the resulting summary.
+
+For a Python summary, implemented in ``ScriptSummaryFormat``,
+``FormatObject()`` calls into the ``ScriptInterpreter`` which is supposed to
+hold the knowledge on how to bridge back and forth with the scripting language
+(Python in the case of LLDB) in order to produce a valid string. Implementors
+of new ``ScriptInterpreters`` for other languages are expected to provide a
+``GetScriptedSummary()`` entrypoint for this purpose, if they desire to allow
+users to provide formatters in the new language
+
+Lastly, C++ summaries (``CXXFunctionSummaryFormat``), wrap a function pointer
+and call into it to execute their duty. It should be noted that there are no
+facilities for users to interact with C++ formatters, and as such they are
+extremely opaque, effectively being a thin wrapper between plain function
+pointers and the LLDB formatters subsystem.
+
+Also, dynamic loading of C++ formatters in LLDB is currently not implemented,
+and as such it is safe and reasonable for these formatters to deal with
+internal ``ValueObjects`` instances instead of public ``SBValue`` objects.
+
+An interesting data point is that summaries are expected to be stateless. While
+at the Python layer they are handed an ``SBValue`` (since nothing else could be
+visible for scripts), it is not expected that 

[Lldb-commits] [lldb] [lldb] Revive internal data formatter documentation (PR #66527)

[Walter Erquinigo via lldb-commits]

https://github.com/walter-erquinigo commented:

Awesome doc!

https://github.com/llvm/llvm-project/pull/66527
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Revive internal data formatter documentation (PR #66527)

[Walter Erquinigo via lldb-commits]

@@ -0,0 +1,436 @@
+Data Formatters
+===
+
+This page is an introduction to the design of the LLDB data formatters
+subsystem. The intended target audience are people interested in understanding
+or modifying the formatters themselves rather than writing a specific data
+formatter. For this latter purpose, the user documentation about formatters is
+the main relevant document which one should refer to.
+
+This page also highlights some open areas for improvement to the general
+subsystem, and more evolutions not anticipated here are certainly possible.
+
+Overview
+
+
+The LLDB data formatters subsystem is used to allow the debugger as well as the
+end-users to customize the way their variables look upon inspection in the user
+interface (be it the command line tool, or one of the several GUIs that are
+backed by LLDB)
+
+To this aim, they are hooked into the ValueObjects model, in order to provide
+entry points through which such customization questions can be answered. For
+example what format should this number be printed as? How many child elements
+does this ``std::vector`` have?
+
+The architecture of the subsystem is layered, with the highest level layer
+being the user visible interaction features (e.g. the ``type ***`` commands,
+the SB classes, ...). Other layers of interest that will be analyzed in this
+document include
+
+* Classes implementing individual data formatter types
+* Classes implementing formatters navigation, discovery and categorization
+* The ``FormatManager`` layer
+* The ``DataVisualization`` layer
+* The SWIG <> LLDB communication layer
+
+Data Formatter Types
+
+
+As described in the user documentation, there are four types of formatters:
+
+* Formats
+* Summaries
+* Filters
+* Synthetic children
+
+Formatters have descriptor classes, ``Type*Impl``, which contain at least a
+"Flags" nested object, which contains both rules to be used by the matching
+algorithm (e.g. should the formatter for type Foo apply to a Foo*?) or rules to
+be used by the formatter itself (e.g. is this summary a oneliner?).
+
+Individual formatter descriptor classes then also contain data items useful to
+them for performing their functionality. For instance ``TypeFormatImpl``
+(backing formats) contains an ``lldb::Format`` that is the format to then be
+applied were this formatter to be selected. Upon issuing a ``type format add``
+a new ``TypeFormatImpl`` is created that wraps the user-specified format, and
+matching options:
+
+::
+
+  entry.reset(new TypeFormatImpl(
+  format, TypeFormatImpl::Flags()
+  .SetCascades(m_command_options.m_cascade)
+  .SetSkipPointers(m_command_options.m_skip_pointers)
+  .SetSkipReferences(m_command_options.m_skip_references)));
+
+
+While formats are fairly simple and only implemented by one class, the other
+formatter types are backed by a class hierarchy.
+
+Summaries, for instance, can exist in one of three "flavors":
+
+* Summary strings
+* Python script
+* Native C++
+
+The base class for summaries, ``TypeSummaryImpl``, is a pure virtual class that
+wraps, again, the Flags, and exports among others:
+
+::
+
+  virtual bool FormatObject (ValueObject *valobj, std::string& dest) = 0;
+
+
+This is the core entry point, which allows subclasses to specify their mode of
+operation.
+
+``StringSummaryFormat``, which is the class that implements summary strings,
+does a check as to whether the summary is a one-liner, and if not, then uses
+its stored summary string to call into ``Debugger::FormatPrompt``, and obtain a
+string back, which it returns in ``dest`` as the resulting summary.
+
+For a Python summary, implemented in ``ScriptSummaryFormat``,
+``FormatObject()`` calls into the ``ScriptInterpreter`` which is supposed to
+hold the knowledge on how to bridge back and forth with the scripting language
+(Python in the case of LLDB) in order to produce a valid string. Implementors
+of new ``ScriptInterpreters`` for other languages are expected to provide a
+``GetScriptedSummary()`` entrypoint for this purpose, if they desire to allow
+users to provide formatters in the new language
+
+Lastly, C++ summaries (``CXXFunctionSummaryFormat``), wrap a function pointer
+and call into it to execute their duty. It should be noted that there are no
+facilities for users to interact with C++ formatters, and as such they are
+extremely opaque, effectively being a thin wrapper between plain function
+pointers and the LLDB formatters subsystem.
+
+Also, dynamic loading of C++ formatters in LLDB is currently not implemented,
+and as such it is safe and reasonable for these formatters to deal with
+internal ``ValueObjects`` instances instead of public ``SBValue`` objects.
+
+An interesting data point is that summaries are expected to be stateless. While
+at the Python layer they are handed an ``SBValue`` (since nothing else could be
+visible for scripts), it is not expected that 

[Lldb-commits] [lldb] [lldb-vscode] Show value addresses in a short format (PR #66534)

[Walter Erquinigo via lldb-commits]

https://github.com/walter-erquinigo created 
https://github.com/llvm/llvm-project/pull/66534

The variables pane on VSCode is very narrow by default, and lldb-vscode has 
been using the default formatter for addresses, which uses 18 characters for 
each address. That's a bit too much because it prints too many leading zeroes.
As a way to improve readability of variables, I'm adding some logic to format 
addresses manually using as few chars as possible. I don't want to mess with 
the default LLDB formatter because, if the user uses the debug console, they 
should see addresses formatted in the regular way.


>From 82a50d63e896bcce943370e12e14f442c2a140b7 Mon Sep 17 00:00:00 2001
From: walter erquinigo 
Date: Fri, 15 Sep 2023 12:40:33 -0400
Subject: [PATCH] [lldb-vscode] Show value addresses in a short format

The variables pane on VSCode is very narrow by default, and lldb-vscode has 
been using the default formatter for addresses, which uses 18 characters for 
each address. That's a bit too much because it prints too many leading zeroes.
As a way to improve readability of variables, I'm adding some logic to format 
addresses manually using as few chars as possible. I don't want to mess with 
the default LLDB formatter because, if the user uses the debug console, they 
should see addresses formatted in the regular way.
---
 lldb/include/lldb/API/SBType.h|   4 +
 lldb/source/API/SBType.cpp|   4 +
 .../API/tools/lldb-vscode/evaluate/main.cpp   |   2 +-
 .../variables/TestVSCode_variables.py | 107 +++---
 .../API/tools/lldb-vscode/variables/main.cpp  |   6 +
 lldb/tools/lldb-vscode/JSONUtils.cpp  |  21 +++-
 6 files changed, 127 insertions(+), 17 deletions(-)

diff --git a/lldb/include/lldb/API/SBType.h b/lldb/include/lldb/API/SBType.h
index 5962f0c50dee14f..c8fcb759dede6b2 100644
--- a/lldb/include/lldb/API/SBType.h
+++ b/lldb/include/lldb/API/SBType.h
@@ -121,6 +121,10 @@ class SBType {
 
   uint64_t GetByteSize();
 
+  /// \return
+  ///Whether the type is a pointer or a reference.
+  bool IsPointerOrReferenceType();
+
   bool IsPointerType();
 
   bool IsReferenceType();
diff --git a/lldb/source/API/SBType.cpp b/lldb/source/API/SBType.cpp
index ee5b6447428098e..38fcb54f5ea98dc 100644
--- a/lldb/source/API/SBType.cpp
+++ b/lldb/source/API/SBType.cpp
@@ -127,6 +127,10 @@ uint64_t SBType::GetByteSize() {
   return 0;
 }
 
+bool SBType::IsPointerOrReferenceType() {
+  return IsPointerType() || IsReferenceType();
+}
+
 bool SBType::IsPointerType() {
   LLDB_INSTRUMENT_VA(this);
 
diff --git a/lldb/test/API/tools/lldb-vscode/evaluate/main.cpp 
b/lldb/test/API/tools/lldb-vscode/evaluate/main.cpp
index 3a541b21b220828..bed853ba6e1433e 100644
--- a/lldb/test/API/tools/lldb-vscode/evaluate/main.cpp
+++ b/lldb/test/API/tools/lldb-vscode/evaluate/main.cpp
@@ -43,6 +43,6 @@ int main(int argc, char const *argv[]) {
   my_bool_vec.push_back(true);
   my_bool_vec.push_back(false); // breakpoint 6
   my_bool_vec.push_back(true); // breakpoint 7
-  
+
   return 0;
 }
diff --git a/lldb/test/API/tools/lldb-vscode/variables/TestVSCode_variables.py 
b/lldb/test/API/tools/lldb-vscode/variables/TestVSCode_variables.py
index fc24b3b34e70283..efb5f3ec284589f 100644
--- a/lldb/test/API/tools/lldb-vscode/variables/TestVSCode_variables.py
+++ b/lldb/test/API/tools/lldb-vscode/variables/TestVSCode_variables.py
@@ -42,6 +42,17 @@ def verify_values(self, verify_dict, actual, 
varref_dict=None, expression=None):
 ('"%s" value "%s" doesn\'t start with' ' "%s")')
 % (key, actual_value, verify_value),
 )
+if "notstartswith" in verify_dict:
+verify = verify_dict["notstartswith"]
+for key in verify:
+verify_value = verify[key]
+actual_value = actual[key]
+startswith = actual_value.startswith(verify_value)
+self.assertFalse(
+startswith,
+('"%s" value "%s" starts with' ' "%s")')
+% (key, actual_value, verify_value),
+)
 if "contains" in verify_dict:
 verify = verify_dict["contains"]
 for key in verify:
@@ -155,6 +166,7 @@ def do_test_scopes_variables_setVariable_evaluate(
 "argv": {
 "equals": {"type": "const char **"},
 "startswith": {"value": "0x"},
+"notstartswith": {"value": "0x0"},
 "hasVariablesReference": True,
 },
 "pt": {
@@ -166,8 +178,53 @@ def do_test_scopes_variables_setVariable_evaluate(
 "buffer": {"children": buffer_children},
 },
 },
+"pt_ptr": {
+"equals": {"type": "PointType *"},
+"startswith": {"value": "0x"},
+"notstartswith": {"value": "0x0"},
+"hasVariablesReference": True,
+   

[Lldb-commits] [lldb] [lldb-vscode] Show value addresses in a short format (PR #66534)

[via lldb-commits]

llvmbot wrote:




@llvm/pr-subscribers-lldb


Changes

The variables pane on VSCode is very narrow by default, and lldb-vscode has 
been using the default formatter for addresses, which uses 18 characters for 
each address. That's a bit too much because it prints too many leading zeroes.
As a way to improve readability of variables, I'm adding some logic to format 
addresses manually using as few chars as possible. I don't want to mess with 
the default LLDB formatter because, if the user uses the debug console, they 
should see addresses formatted in the regular way.

---
Full diff: https://github.com/llvm/llvm-project/pull/66534.diff


6 Files Affected:

- (modified) lldb/include/lldb/API/SBType.h (+4) 
- (modified) lldb/source/API/SBType.cpp (+4) 
- (modified) lldb/test/API/tools/lldb-vscode/evaluate/main.cpp (+1-1) 
- (modified) lldb/test/API/tools/lldb-vscode/variables/TestVSCode_variables.py 
(+93-14) 
- (modified) lldb/test/API/tools/lldb-vscode/variables/main.cpp (+6) 
- (modified) lldb/tools/lldb-vscode/JSONUtils.cpp (+19-2) 


``diff
diff --git a/lldb/include/lldb/API/SBType.h b/lldb/include/lldb/API/SBType.h
index 5962f0c50dee14f..c8fcb759dede6b2 100644
--- a/lldb/include/lldb/API/SBType.h
+++ b/lldb/include/lldb/API/SBType.h
@@ -121,6 +121,10 @@ class SBType {
 
   uint64_t GetByteSize();
 
+  /// \return
+  ///Whether the type is a pointer or a reference.
+  bool IsPointerOrReferenceType();
+
   bool IsPointerType();
 
   bool IsReferenceType();
diff --git a/lldb/source/API/SBType.cpp b/lldb/source/API/SBType.cpp
index ee5b6447428098e..38fcb54f5ea98dc 100644
--- a/lldb/source/API/SBType.cpp
+++ b/lldb/source/API/SBType.cpp
@@ -127,6 +127,10 @@ uint64_t SBType::GetByteSize() {
   return 0;
 }
 
+bool SBType::IsPointerOrReferenceType() {
+  return IsPointerType() || IsReferenceType();
+}
+
 bool SBType::IsPointerType() {
   LLDB_INSTRUMENT_VA(this);
 
diff --git a/lldb/test/API/tools/lldb-vscode/evaluate/main.cpp 
b/lldb/test/API/tools/lldb-vscode/evaluate/main.cpp
index 3a541b21b220828..bed853ba6e1433e 100644
--- a/lldb/test/API/tools/lldb-vscode/evaluate/main.cpp
+++ b/lldb/test/API/tools/lldb-vscode/evaluate/main.cpp
@@ -43,6 +43,6 @@ int main(int argc, char const *argv[]) {
   my_bool_vec.push_back(true);
   my_bool_vec.push_back(false); // breakpoint 6
   my_bool_vec.push_back(true); // breakpoint 7
-  
+
   return 0;
 }
diff --git a/lldb/test/API/tools/lldb-vscode/variables/TestVSCode_variables.py 
b/lldb/test/API/tools/lldb-vscode/variables/TestVSCode_variables.py
index fc24b3b34e70283..efb5f3ec284589f 100644
--- a/lldb/test/API/tools/lldb-vscode/variables/TestVSCode_variables.py
+++ b/lldb/test/API/tools/lldb-vscode/variables/TestVSCode_variables.py
@@ -42,6 +42,17 @@ def verify_values(self, verify_dict, actual, 
varref_dict=None, expression=None):
 ('"%s" value "%s" doesn\'t start with' ' "%s")')
 % (key, actual_value, verify_value),
 )
+if "notstartswith" in verify_dict:
+verify = verify_dict["notstartswith"]
+for key in verify:
+verify_value = verify[key]
+actual_value = actual[key]
+startswith = actual_value.startswith(verify_value)
+self.assertFalse(
+startswith,
+('"%s" value "%s" starts with' ' "%s")')
+% (key, actual_value, verify_value),
+)
 if "contains" in verify_dict:
 verify = verify_dict["contains"]
 for key in verify:
@@ -155,6 +166,7 @@ def do_test_scopes_variables_setVariable_evaluate(
 "argv": {
 "equals": {"type": "const char **"},
 "startswith": {"value": "0x"},
+"notstartswith": {"value": "0x0"},
 "hasVariablesReference": True,
 },
 "pt": {
@@ -166,8 +178,53 @@ def do_test_scopes_variables_setVariable_evaluate(
 "buffer": {"children": buffer_children},
 },
 },
+"pt_ptr": {
+"equals": {"type": "PointType *"},
+"startswith": {"value": "0x"},
+"notstartswith": {"value": "0x0"},
+"hasVariablesReference": True,
+},
+"another_pt_ptr": {
+"equals": {"type": "PointType *"},
+"startswith": {"value": ""},
+"hasVariablesReference": True,
+},
 "x": {"equals": {"type": "int"}},
+"some_int": {
+"equals": {
+"type": "int",
+"value": "10",
+},
+},
+"some_int_ptr": {
+"equals": {"type": "int *"},
+"startswith": {"value": "0x"},
+"notstartswith": {"value": "0x0"},
+},
+"another_int_ptr": {
+"equals": {
+  

[Lldb-commits] [lldb] [lldb-vscode] Show value addresses in a short format (PR #66534)

[Walter Erquinigo via lldb-commits]

https://github.com/walter-erquinigo updated 
https://github.com/llvm/llvm-project/pull/66534

>From d8060f818b18b3fe64641d9683fa49ffca0b3736 Mon Sep 17 00:00:00 2001
From: walter erquinigo 
Date: Fri, 15 Sep 2023 12:40:33 -0400
Subject: [PATCH] [lldb-vscode] Show value addresses in a short format

The variables pane on VSCode is very narrow by default, and lldb-vscode has 
been using the default formatter for addresses, which uses 18 characters for 
each address. That's a bit too much because it prints too many leading zeroes.
As a way to improve readability of variables, I'm adding some logic to format 
addresses manually using as few chars as possible. I don't want to mess with 
the default LLDB formatter because, if the user uses the debug console, they 
should see addresses formatted in the regular way.
---
 lldb/include/lldb/API/SBType.h|   4 +
 lldb/source/API/SBType.cpp|   4 +
 .../API/tools/lldb-vscode/evaluate/main.cpp   |   2 +-
 .../variables/TestVSCode_variables.py | 107 +++---
 .../API/tools/lldb-vscode/variables/main.cpp  |   6 +
 lldb/tools/lldb-vscode/JSONUtils.cpp  |  21 +++-
 6 files changed, 127 insertions(+), 17 deletions(-)

diff --git a/lldb/include/lldb/API/SBType.h b/lldb/include/lldb/API/SBType.h
index 5962f0c50dee14f..c8fcb759dede6b2 100644
--- a/lldb/include/lldb/API/SBType.h
+++ b/lldb/include/lldb/API/SBType.h
@@ -121,6 +121,10 @@ class SBType {
 
   uint64_t GetByteSize();
 
+  /// \return
+  ///Whether the type is a pointer or a reference.
+  bool IsPointerOrReferenceType();
+
   bool IsPointerType();
 
   bool IsReferenceType();
diff --git a/lldb/source/API/SBType.cpp b/lldb/source/API/SBType.cpp
index ee5b6447428098e..38fcb54f5ea98dc 100644
--- a/lldb/source/API/SBType.cpp
+++ b/lldb/source/API/SBType.cpp
@@ -127,6 +127,10 @@ uint64_t SBType::GetByteSize() {
   return 0;
 }
 
+bool SBType::IsPointerOrReferenceType() {
+  return IsPointerType() || IsReferenceType();
+}
+
 bool SBType::IsPointerType() {
   LLDB_INSTRUMENT_VA(this);
 
diff --git a/lldb/test/API/tools/lldb-vscode/evaluate/main.cpp 
b/lldb/test/API/tools/lldb-vscode/evaluate/main.cpp
index 3a541b21b220828..bed853ba6e1433e 100644
--- a/lldb/test/API/tools/lldb-vscode/evaluate/main.cpp
+++ b/lldb/test/API/tools/lldb-vscode/evaluate/main.cpp
@@ -43,6 +43,6 @@ int main(int argc, char const *argv[]) {
   my_bool_vec.push_back(true);
   my_bool_vec.push_back(false); // breakpoint 6
   my_bool_vec.push_back(true); // breakpoint 7
-  
+
   return 0;
 }
diff --git a/lldb/test/API/tools/lldb-vscode/variables/TestVSCode_variables.py 
b/lldb/test/API/tools/lldb-vscode/variables/TestVSCode_variables.py
index fc24b3b34e70283..e54a42814f1e9d4 100644
--- a/lldb/test/API/tools/lldb-vscode/variables/TestVSCode_variables.py
+++ b/lldb/test/API/tools/lldb-vscode/variables/TestVSCode_variables.py
@@ -42,6 +42,17 @@ def verify_values(self, verify_dict, actual, 
varref_dict=None, expression=None):
 ('"%s" value "%s" doesn\'t start with' ' "%s")')
 % (key, actual_value, verify_value),
 )
+if "notstartswith" in verify_dict:
+verify = verify_dict["notstartswith"]
+for key in verify:
+verify_value = verify[key]
+actual_value = actual[key]
+startswith = actual_value.startswith(verify_value)
+self.assertFalse(
+startswith,
+('"%s" value "%s" starts with' ' "%s")')
+% (key, actual_value, verify_value),
+)
 if "contains" in verify_dict:
 verify = verify_dict["contains"]
 for key in verify:
@@ -155,6 +166,7 @@ def do_test_scopes_variables_setVariable_evaluate(
 "argv": {
 "equals": {"type": "const char **"},
 "startswith": {"value": "0x"},
+"notstartswith": {"value": "0x0"},
 "hasVariablesReference": True,
 },
 "pt": {
@@ -166,8 +178,53 @@ def do_test_scopes_variables_setVariable_evaluate(
 "buffer": {"children": buffer_children},
 },
 },
+"pt_ptr": {
+"equals": {"type": "PointType *"},
+"startswith": {"value": "0x"},
+"notstartswith": {"value": "0x0"},
+"hasVariablesReference": True,
+},
+"another_pt_ptr": {
+"equals": {"type": "PointType *"},
+"startswith": {"value": ""},
+"hasVariablesReference": True,
+},
 "x": {"equals": {"type": "int"}},
+"some_int": {
+"equals": {
+"type": "int",
+"value": "10",
+},
+},
+"some_int_ptr": {
+"equals": {"type": "int *"},
+"startswit

[Lldb-commits] [lldb] [lldb-vscode] Show value addresses in a short format (PR #66534)

[Walter Erquinigo via lldb-commits]

https://github.com/walter-erquinigo edited 
https://github.com/llvm/llvm-project/pull/66534
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb-vscode] Show value addresses in a short format (PR #66534)

[Walter Erquinigo via lldb-commits]

https://github.com/walter-erquinigo ready_for_review 
https://github.com/llvm/llvm-project/pull/66534
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Revive internal data formatter documentation (PR #66527)

[Jonas Devlieghere via lldb-commits]

https://github.com/JDevlieghere updated 
https://github.com/llvm/llvm-project/pull/66527

>From d67ae6c562f0367df98ce72f866c088cf433b62d Mon Sep 17 00:00:00 2001
From: Jonas Devlieghere 
Date: Fri, 15 Sep 2023 09:31:22 -0700
Subject: [PATCH] [lldb] Revive internal data formatter documentation

This is a (rough) port of architecture/varformats.html page that got
lost during the migration to RST in edb874b. I'm not sure how much of
its content is still relevant today. However, the page is pretty
extensive and seems like it's worth preserving.
---
 lldb/docs/index.rst|   1 +
 lldb/docs/resources/dataformatters.rst | 439 +
 2 files changed, 440 insertions(+)
 create mode 100644 lldb/docs/resources/dataformatters.rst

diff --git a/lldb/docs/index.rst b/lldb/docs/index.rst
index 3b65f81a6d74936..2eb57cefbd883ea 100644
--- a/lldb/docs/index.rst
+++ b/lldb/docs/index.rst
@@ -151,6 +151,7 @@ interesting areas to contribute to lldb.
resources/debugging
resources/fuzzing
resources/sbapi
+   resources/dataformatters
resources/extensions
resources/caveats
resources/projects
diff --git a/lldb/docs/resources/dataformatters.rst 
b/lldb/docs/resources/dataformatters.rst
new file mode 100644
index 000..a5b6261e363aefc
--- /dev/null
+++ b/lldb/docs/resources/dataformatters.rst
@@ -0,0 +1,439 @@
+Data Formatters
+===
+
+This page is an introduction to the design of the LLDB data formatters
+subsystem. The intended target audience are people interested in understanding
+or modifying the formatters themselves rather than writing a specific data
+formatter. For this latter purpose, the user documentation about formatters is
+the main relevant document which one should refer to.
+
+This page also highlights some open areas for improvement to the general
+subsystem, and more evolutions not anticipated here are certainly possible.
+
+Overview
+
+
+The LLDB data formatters subsystem is used to allow the debugger as well as the
+end-users to customize the way their variables look upon inspection in the user
+interface (be it the command line tool, or one of the several GUIs that are
+backed by LLDB).
+
+To this aim, they are hooked into the ``ValueObjects`` model, in order to
+provide entry points through which such customization questions can be
+answered. For example: What format should this number be printed as? How many
+child elements does this ``std::vector`` have?
+
+The architecture of the subsystem is layered, with the highest level layer
+being the user visible interaction features (e.g. the ``type ***`` commands,
+the SB classes, ...). Other layers of interest that will be analyzed in this
+document include:
+
+* Classes implementing individual data formatter types
+* Classes implementing formatters navigation, discovery and categorization
+* The ``FormatManager`` layer
+* The ``DataVisualization`` layer
+* The SWIG <> LLDB communication layer
+
+Data Formatter Types
+
+
+As described in the user documentation, there are four types of formatters:
+
+* Formats
+* Summaries
+* Filters
+* Synthetic children
+
+Formatters have descriptor classes, ``Type*Impl``, which contain at least a
+"Flags" nested object, which contains both rules to be used by the matching
+algorithm (e.g. should the formatter for type Foo apply to a Foo*?) or rules to
+be used by the formatter itself (e.g. is this summary a oneliner?).
+
+Individual formatter descriptor classes then also contain data items useful to
+them for performing their functionality. For instance ``TypeFormatImpl``
+(backing formats) contains an ``lldb::Format`` that is the format to then be
+applied were this formatter to be selected. Upon issuing a ``type format add``
+a new ``TypeFormatImpl`` is created that wraps the user-specified format, and
+matching options:
+
+::
+
+  entry.reset(new TypeFormatImpl(
+  format, TypeFormatImpl::Flags()
+  .SetCascades(m_command_options.m_cascade)
+  .SetSkipPointers(m_command_options.m_skip_pointers)
+  .SetSkipReferences(m_command_options.m_skip_references)));
+
+
+While formats are fairly simple and only implemented by one class, the other
+formatter types are backed by a class hierarchy.
+
+Summaries, for instance, can exist in one of three "flavors":
+
+* Summary strings
+* Python script
+* Native C++
+
+The base class for summaries, ``TypeSummaryImpl``, is a pure virtual class that
+wraps, again, the Flags, and exports among others:
+
+::
+
+  virtual bool FormatObject (ValueObject *valobj, std::string& dest) = 0;
+
+
+This is the core entry point, which allows subclasses to specify their mode of
+operation.
+
+``StringSummaryFormat``, which is the class that implements summary strings,
+does a check as to whether the summary is a one-liner, and if not, then uses
+its stored summary string to call into ``Debugger::FormatPrompt``, and obtain a
+string back, which it 

[Lldb-commits] [lldb] [lldb] Revive internal data formatter documentation (PR #66527)

[Jonas Devlieghere via lldb-commits]

https://github.com/JDevlieghere closed 
https://github.com/llvm/llvm-project/pull/66527
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] c60ccfb - [lldb] Revive internal data formatter documentation (#66527)

[via lldb-commits]

Author: Jonas Devlieghere
Date: 2023-09-15T11:15:13-07:00
New Revision: c60ccfbb898148449946f82cbac6140f1e01cb12

URL: 
https://github.com/llvm/llvm-project/commit/c60ccfbb898148449946f82cbac6140f1e01cb12
DIFF: 
https://github.com/llvm/llvm-project/commit/c60ccfbb898148449946f82cbac6140f1e01cb12.diff

LOG: [lldb] Revive internal data formatter documentation (#66527)

This is a (rough) port of architecture/varformats.html page that got
lost during the migration to RST in edb874b. I'm not sure how much of
its content is still relevant today. However, the page is pretty
extensive and seems like it's worth preserving.

Added: 
lldb/docs/resources/dataformatters.rst

Modified: 
lldb/docs/index.rst

Removed: 




diff  --git a/lldb/docs/index.rst b/lldb/docs/index.rst
index 3b65f81a6d74936..2eb57cefbd883ea 100644
--- a/lldb/docs/index.rst
+++ b/lldb/docs/index.rst
@@ -151,6 +151,7 @@ interesting areas to contribute to lldb.
resources/debugging
resources/fuzzing
resources/sbapi
+   resources/dataformatters
resources/extensions
resources/caveats
resources/projects

diff  --git a/lldb/docs/resources/dataformatters.rst 
b/lldb/docs/resources/dataformatters.rst
new file mode 100644
index 000..a5b6261e363aefc
--- /dev/null
+++ b/lldb/docs/resources/dataformatters.rst
@@ -0,0 +1,439 @@
+Data Formatters
+===
+
+This page is an introduction to the design of the LLDB data formatters
+subsystem. The intended target audience are people interested in understanding
+or modifying the formatters themselves rather than writing a specific data
+formatter. For this latter purpose, the user documentation about formatters is
+the main relevant document which one should refer to.
+
+This page also highlights some open areas for improvement to the general
+subsystem, and more evolutions not anticipated here are certainly possible.
+
+Overview
+
+
+The LLDB data formatters subsystem is used to allow the debugger as well as the
+end-users to customize the way their variables look upon inspection in the user
+interface (be it the command line tool, or one of the several GUIs that are
+backed by LLDB).
+
+To this aim, they are hooked into the ``ValueObjects`` model, in order to
+provide entry points through which such customization questions can be
+answered. For example: What format should this number be printed as? How many
+child elements does this ``std::vector`` have?
+
+The architecture of the subsystem is layered, with the highest level layer
+being the user visible interaction features (e.g. the ``type ***`` commands,
+the SB classes, ...). Other layers of interest that will be analyzed in this
+document include:
+
+* Classes implementing individual data formatter types
+* Classes implementing formatters navigation, discovery and categorization
+* The ``FormatManager`` layer
+* The ``DataVisualization`` layer
+* The SWIG <> LLDB communication layer
+
+Data Formatter Types
+
+
+As described in the user documentation, there are four types of formatters:
+
+* Formats
+* Summaries
+* Filters
+* Synthetic children
+
+Formatters have descriptor classes, ``Type*Impl``, which contain at least a
+"Flags" nested object, which contains both rules to be used by the matching
+algorithm (e.g. should the formatter for type Foo apply to a Foo*?) or rules to
+be used by the formatter itself (e.g. is this summary a oneliner?).
+
+Individual formatter descriptor classes then also contain data items useful to
+them for performing their functionality. For instance ``TypeFormatImpl``
+(backing formats) contains an ``lldb::Format`` that is the format to then be
+applied were this formatter to be selected. Upon issuing a ``type format add``
+a new ``TypeFormatImpl`` is created that wraps the user-specified format, and
+matching options:
+
+::
+
+  entry.reset(new TypeFormatImpl(
+  format, TypeFormatImpl::Flags()
+  .SetCascades(m_command_options.m_cascade)
+  .SetSkipPointers(m_command_options.m_skip_pointers)
+  .SetSkipReferences(m_command_options.m_skip_references)));
+
+
+While formats are fairly simple and only implemented by one class, the other
+formatter types are backed by a class hierarchy.
+
+Summaries, for instance, can exist in one of three "flavors":
+
+* Summary strings
+* Python script
+* Native C++
+
+The base class for summaries, ``TypeSummaryImpl``, is a pure virtual class that
+wraps, again, the Flags, and exports among others:
+
+::
+
+  virtual bool FormatObject (ValueObject *valobj, std::string& dest) = 0;
+
+
+This is the core entry point, which allows subclasses to specify their mode of
+operation.
+
+``StringSummaryFormat``, which is the class that implements summary strings,
+does a check as to whether the summary is a one-liner, and if not, then uses
+its stored summary string to call into ``Debugger::FormatP

[Lldb-commits] [lldb] Add `target modules dump separate-debug-info` (PR #66035)

[Tom Yang via lldb-commits]

zhyty wrote:

> > > I think it would be easier to read the output if you made a separate 
> > > column for "error". If you imagine a listing where there are 100 OSO's of 
> > > which 10 are missing, the paths are going to jump over because of the 
> > > "error: ..." at the beginning of those lines making it messy for your 
> > > eyes to track. Seems like there are only two possible errors "file not 
> > > found" and "file out of date", so it seems like we should be able to make 
> > > a fairly short error column after the ID and then the path?
> > 
> > 
> > The errors are quite long as they mention the offending path to the OSO and 
> > the OSO paths are often very long, so you would need to run through the 
> > results to calculate the max width of the OSO path and then you would 
> > almost certainly overlflow off the right edge of the terminal if you also 
> > show the error string.
> > This patch currently doesn't show the OSO path if there is an error , so we 
> > show the error in place of the OSO path as the error string contains the 
> > path in the error text. Would your prefer to always show the modtime + oso 
> > path and then add the error on the next line?
> 
> I was imaging something like:
> 
> ```
> (lldb) image dump separate-debug-info
> Symbol file: /home/toyang/workspace/dwo-scratch/a.out
> Type: "dwo"
> Dwo ID Error Dwo Path
> -- --- -
> 0x9a429da5abb6faae Missing "/home/toyang/workspace/dwo-scratch/a-main.dwo" 
> for skeleton DIE 0x0014
> 0xbcc129959e76ff33 Missing "/home/toyang/workspace/dwo-scratch/a-foo.dwo" for 
> skeleton DIE 0x003c
> ```
> 
> Or given that there aren't many errors possible, you could even do a one 
> letter thing `S` for success, `M` for missing and `O` for out of date.
> 
> If the error was of the form "Not found: ..." or "Out of data:..." then you 
> could pick off the error string. You're in charge of the error string so you 
> can arrange to emit it in a way that allows picking this info out of it 
> easily. And you don't need the path in the error since it's in the next 
> "path" field anyway.

It might be nice having a separate error column with just a one letter thing 
for now, maybe with just two options "S" and "E" for now. The errors are just 
arbitrary strings decided by the DWO/OSO-specific logic at the moment -- if we 
wanted to categorize all of the errors properly, that would probably be outside 
the scope of this PR?


https://github.com/llvm/llvm-project/pull/66035
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] Add `target modules dump separate-debug-info` (PR #66035)

[via lldb-commits]

jimingham wrote:

People can either look at the detailed JSON output or just go look at that path 
to figure out what went wrong, so just S & E would be fine for now.

Jim


> On Sep 15, 2023, at 11:18 AM, Tom Yang ***@***.***> wrote:
> 
> 
> I think it would be easier to read the output if you made a separate column 
> for "error". If you imagine a listing where there are 100 OSO's of which 10 
> are missing, the paths are going to jump over because of the "error: ..." at 
> the beginning of those lines making it messy for your eyes to track. Seems 
> like there are only two possible errors "file not found" and "file out of 
> date", so it seems like we should be able to make a fairly short error column 
> after the ID and then the path?
> 
> The errors are quite long as they mention the offending path to the OSO and 
> the OSO paths are often very long, so you would need to run through the 
> results to calculate the max width of the OSO path and then you would almost 
> certainly overlflow off the right edge of the terminal if you also show the 
> error string.
> This patch currently doesn't show the OSO path if there is an error , so we 
> show the error in place of the OSO path as the error string contains the path 
> in the error text. Would your prefer to always show the modtime + oso path 
> and then add the error on the next line?
> 
> I was imaging something like:
> 
> (lldb) image dump separate-debug-info
> Symbol file: /home/toyang/workspace/dwo-scratch/a.out
> Type: "dwo"
> Dwo ID Error Dwo Path
> -- --- -
> 0x9a429da5abb6faae Missing "/home/toyang/workspace/dwo-scratch/a-main.dwo" 
> for skeleton DIE 0x0014
> 0xbcc129959e76ff33 Missing "/home/toyang/workspace/dwo-scratch/a-foo.dwo" for 
> skeleton DIE 0x003c
> Or given that there aren't many errors possible, you could even do a one 
> letter thing S for success, M for missing and O for out of date.
> 
> If the error was of the form "Not found: ..." or "Out of data:..." then you 
> could pick off the error string. You're in charge of the error string so you 
> can arrange to emit it in a way that allows picking this info out of it 
> easily. And you don't need the path in the error since it's in the next 
> "path" field anyway.
> 
> It might be nice having a separate error column with just a one letter thing 
> for now, maybe with just two options "S" and "E" for now. The errors are just 
> arbitrary strings decided by the DWO/OSO-specific logic at the moment -- if 
> we wanted to categorize all of the errors properly, that would probably be 
> outside the scope of this PR?
> 
> —
> Reply to this email directly, view it on GitHub 
> , or 
> unsubscribe 
> .
> You are receiving this because you were mentioned.
> 



https://github.com/llvm/llvm-project/pull/66035
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb-vscode] Show value addresses in a short format (PR #66534)

[Greg Clayton via lldb-commits]

https://github.com/clayborg requested changes to this pull request.

I would rather we add a new setting in lldb that controls if we see hex values 
with leading zeroes and allow users to set this. It will be _very_ easy to fix 
this as all you need to do is fix lldb_private::DumpDataExtractor() and change 
the "case eFormatHex:" case.

Setting could be:
```
(lldb) settings set target.show-hex-values-with-leading-zeroes true
(lldb) settings set target.show-hex-values-with-leading-zeroes false
```
Then users can choose how they want to see their values and it will be 
consistent across the command line and IDEs

https://github.com/llvm/llvm-project/pull/66534
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb-vscode] Show value addresses in a short format (PR #66534)

[Greg Clayton via lldb-commits]

@@ -228,7 +228,24 @@ void SetValueForKey(lldb::SBValue &v, llvm::json::Object 
&object,
 strm << "";
   } else {
 auto tryDumpSummaryAndValue = [&strm](lldb::SBValue value) {
-  llvm::StringRef val = value.GetValue();
+  std::string val;
+  // Whenever the value is a non-synthetic address, we format it ourselves
+  // to use as few chars as possible because the variables pane on VS Code
+  // is by default narrow.
+  if (!value.IsSynthetic() && value.GetType().IsPointerOrReferenceType()) {
+lldb::addr_t address = value.GetValueAsUnsigned(LLDB_INVALID_ADDRESS);
+if (address == LLDB_INVALID_ADDRESS) {
+  val = "";
+} else if (address == 0) {
+  val = "";
+} else {
+  llvm::raw_string_ostream os(val);
+  os << llvm::format_hex(address, 0);
+}

clayborg wrote:

I wouldn't mess with the values or try to display them in any fancy way, I 
would always use:
```
llvm::raw_string_ostream os(val);
os << llvm::format_hex(address, 0);
```
Users might encode -1 into their pointers as a special value and you wouldn't 
want to see "" as the value. Also I would rather see "0x0" 
instead of "".

https://github.com/llvm/llvm-project/pull/66534
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb-vscode] Show value addresses in a short format (PR #66534)

[Greg Clayton via lldb-commits]

https://github.com/clayborg edited 
https://github.com/llvm/llvm-project/pull/66534
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb-vscode] Show value addresses in a short format (PR #66534)

[Greg Clayton via lldb-commits]

clayborg wrote:

I have verified that if I change DumpDataExtractor() you can easily do this:
```
case eFormatHex:
case eFormatHexUppercase: {
  bool wantsuppercase = (item_format == eFormatHexUppercase);
  switch (item_byte_size) {
  case 1:
  case 2:
  case 4:
  case 8:
if (/*check if leading zeroes is enabled*/) {
  s->Printf(wantsuppercase ? "0x%*.*" PRIX64 : "0x%*.*" PRIx64,
(int)(2 * item_byte_size), (int)(2 * item_byte_size),
DE.GetMaxU64Bitfield(&offset, item_byte_size, item_bit_size,
 item_bit_offset));
} else {
  s->Printf(wantsuppercase ? "0x%" PRIX64 : "0x%" PRIx64,
DE.GetMaxU64Bitfield(&offset, item_byte_size, item_bit_size,
 item_bit_offset));
}
break;



https://github.com/llvm/llvm-project/pull/66534
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb-vscode] Show value addresses in a short format (PR #66534)

[Greg Clayton via lldb-commits]

clayborg wrote:

If you create a setting, be sure to make it a global setting (a bool in the 
setting definition) so it can always be accessed via:
```
  static TargetProperties &Target::GetGlobalProperties();
```


https://github.com/llvm/llvm-project/pull/66534
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb-vscode] Show value addresses in a short format (PR #66534)

[Greg Clayton via lldb-commits]

clayborg wrote:

Then no changes are needed for vs code files at all and we can test this with a 
normal LLDB variable tests.

https://github.com/llvm/llvm-project/pull/66534
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb-vscode] Show value addresses in a short format (PR #66534)

[Walter Erquinigo via lldb-commits]

walter-erquinigo wrote:

I initially didn't want to mess with global configurations, but after a second 
thought, I think your solution is better. I'll try that out

https://github.com/llvm/llvm-project/pull/66534
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb-vscode] Show value addresses in a short format (PR #66534)

[Walter Erquinigo via lldb-commits]

https://github.com/walter-erquinigo closed 
https://github.com/llvm/llvm-project/pull/66534
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [LLDB] Add a setting for print hex values without leading zeroes (PR #66548)

[Walter Erquinigo via lldb-commits]

https://github.com/walter-erquinigo created 
https://github.com/llvm/llvm-project/pull/66548

As suggested by Greg in https://github.com/llvm/llvm-project/pull/66534, I'm 
adding a setting at the Target level that controls whether to show leading 
zeroes in hex ValueObject values.

This has the benefit of reducing the amount of characters displayed in certain 
interfaces, like VSCode.


>From 750c8566bc31a359fe5a69ee5f10a79ccb78d9ce Mon Sep 17 00:00:00 2001
From: walter erquinigo 
Date: Fri, 15 Sep 2023 16:41:23 -0400
Subject: [PATCH] [LLDB] Add a setting for print hex values without leading
 zeroes

As suggested by Greg in https://github.com/llvm/llvm-project/pull/66534, I'm 
adding a setting at the Target level that controls whether to show leading 
zeroes in hex ValueObject values.

This has the benefit of reducing the amount of characters displayed in certain 
interfaces, like VSCode.
---
 lldb/include/lldb/Target/Target.h  |  2 ++
 lldb/source/Core/DumpDataExtractor.cpp | 15 +++
 lldb/source/Target/Target.cpp  | 10 --
 lldb/source/Target/TargetProperties.td |  3 +++
 lldb/test/API/python_api/value/TestValueAPI.py | 17 -
 lldb/test/API/python_api/value/main.c  |  7 +--
 6 files changed, 45 insertions(+), 9 deletions(-)

diff --git a/lldb/include/lldb/Target/Target.h 
b/lldb/include/lldb/Target/Target.h
index ed0ecbbddbf8149..b2dcd3b0b3d30a0 100644
--- a/lldb/include/lldb/Target/Target.h
+++ b/lldb/include/lldb/Target/Target.h
@@ -167,6 +167,8 @@ class TargetProperties : public Properties {
 
   bool GetEnableSyntheticValue() const;
 
+  bool ShouldShowHexValuesWithLeadingZeroes() const;
+
   uint32_t GetMaxZeroPaddingInFloatFormat() const;
 
   uint32_t GetMaximumNumberOfChildrenToDisplay() const;
diff --git a/lldb/source/Core/DumpDataExtractor.cpp 
b/lldb/source/Core/DumpDataExtractor.cpp
index cb76b118325b7ef..fa9c5209ed490ff 100644
--- a/lldb/source/Core/DumpDataExtractor.cpp
+++ b/lldb/source/Core/DumpDataExtractor.cpp
@@ -620,10 +620,17 @@ lldb::offset_t lldb_private::DumpDataExtractor(
   case 2:
   case 4:
   case 8:
-s->Printf(wantsuppercase ? "0x%*.*" PRIX64 : "0x%*.*" PRIx64,
-  (int)(2 * item_byte_size), (int)(2 * item_byte_size),
-  DE.GetMaxU64Bitfield(&offset, item_byte_size, item_bit_size,
-   item_bit_offset));
+if (exe_scope->CalculateTarget()
+->ShouldShowHexValuesWithLeadingZeroes()) {
+  s->Printf(wantsuppercase ? "0x%*.*" PRIX64 : "0x%*.*" PRIx64,
+(int)(2 * item_byte_size), (int)(2 * item_byte_size),
+DE.GetMaxU64Bitfield(&offset, item_byte_size, 
item_bit_size,
+ item_bit_offset));
+} else {
+  s->Printf(wantsuppercase ? "0x%" PRIX64 : "0x%" PRIx64,
+DE.GetMaxU64Bitfield(&offset, item_byte_size, 
item_bit_size,
+ item_bit_offset));
+}
 break;
   default: {
 assert(item_bit_size == 0 && item_bit_offset == 0);
diff --git a/lldb/source/Target/Target.cpp b/lldb/source/Target/Target.cpp
index 35f5ef324fde667..87746d7aa3c32aa 100644
--- a/lldb/source/Target/Target.cpp
+++ b/lldb/source/Target/Target.cpp
@@ -4236,8 +4236,8 @@ bool 
TargetProperties::SetPreferDynamicValue(lldb::DynamicValueType d) {
 }
 
 bool TargetProperties::GetPreloadSymbols() const {
-  if (INTERRUPT_REQUESTED(m_target->GetDebugger(), 
-  "Interrupted checking preload symbols")) {
+  if (INTERRUPT_REQUESTED(m_target->GetDebugger(),
+  "Interrupted checking preload symbols")) {
 return false;
   }
   const uint32_t idx = ePropertyPreloadSymbols;
@@ -4539,6 +4539,12 @@ bool TargetProperties::GetEnableSyntheticValue() const {
   idx, g_target_properties[idx].default_uint_value != 0);
 }
 
+bool TargetProperties::ShouldShowHexValuesWithLeadingZeroes() const {
+  const uint32_t idx = ePropertyShowHexValuesWithLeadingZeroes;
+  return GetPropertyAtIndexAs(
+  idx, g_target_properties[idx].default_uint_value != 0);
+}
+
 uint32_t TargetProperties::GetMaxZeroPaddingInFloatFormat() const {
   const uint32_t idx = ePropertyMaxZeroPaddingInFloatFormat;
   return GetPropertyAtIndexAs(
diff --git a/lldb/source/Target/TargetProperties.td 
b/lldb/source/Target/TargetProperties.td
index 3bfdfa8cfaa957f..9f639842a80841a 100644
--- a/lldb/source/Target/TargetProperties.td
+++ b/lldb/source/Target/TargetProperties.td
@@ -82,6 +82,9 @@ let Definition = "target" in {
   def SaveObjectsDir: Property<"save-jit-objects-dir", "FileSpec">,
 DefaultStringValue<"">,
 Desc<"If specified, the directory to save intermediate object files 
generated by the LLVM JIT">;
+  def ShowHexValuesWithLeadingZeroes: 
Property<"show-hex-values-with-leading-zeroes", "Boolean">,
+DefaultTrue,
+Desc<"Whether to displa

[Lldb-commits] [lldb] [LLDB] Add a setting for print hex values without leading zeroes (PR #66548)

[Walter Erquinigo via lldb-commits]

https://github.com/walter-erquinigo ready_for_review 
https://github.com/llvm/llvm-project/pull/66548
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [LLDB] Add a setting for print hex values without leading zeroes (PR #66548)

[via lldb-commits]

llvmbot wrote:




@llvm/pr-subscribers-lldb


Changes

As suggested by Greg in https://github.com/llvm/llvm-project/pull/66534, I'm 
adding a setting at the Target level that controls whether to show leading 
zeroes in hex ValueObject values.

This has the benefit of reducing the amount of characters displayed in certain 
interfaces, like VSCode.

---
Full diff: https://github.com/llvm/llvm-project/pull/66548.diff


6 Files Affected:

- (modified) lldb/include/lldb/Target/Target.h (+2) 
- (modified) lldb/source/Core/DumpDataExtractor.cpp (+11-4) 
- (modified) lldb/source/Target/Target.cpp (+8-2) 
- (modified) lldb/source/Target/TargetProperties.td (+3) 
- (modified) lldb/test/API/python_api/value/TestValueAPI.py (+16-1) 
- (modified) lldb/test/API/python_api/value/main.c (+5-2) 


``diff
diff --git a/lldb/include/lldb/Target/Target.h 
b/lldb/include/lldb/Target/Target.h
index ed0ecbbddbf8149..b2dcd3b0b3d30a0 100644
--- a/lldb/include/lldb/Target/Target.h
+++ b/lldb/include/lldb/Target/Target.h
@@ -167,6 +167,8 @@ class TargetProperties : public Properties {
 
   bool GetEnableSyntheticValue() const;
 
+  bool ShouldShowHexValuesWithLeadingZeroes() const;
+
   uint32_t GetMaxZeroPaddingInFloatFormat() const;
 
   uint32_t GetMaximumNumberOfChildrenToDisplay() const;
diff --git a/lldb/source/Core/DumpDataExtractor.cpp 
b/lldb/source/Core/DumpDataExtractor.cpp
index cb76b118325b7ef..fa9c5209ed490ff 100644
--- a/lldb/source/Core/DumpDataExtractor.cpp
+++ b/lldb/source/Core/DumpDataExtractor.cpp
@@ -620,10 +620,17 @@ lldb::offset_t lldb_private::DumpDataExtractor(
   case 2:
   case 4:
   case 8:
-s->Printf(wantsuppercase ? "0x%*.*" PRIX64 : "0x%*.*" PRIx64,
-  (int)(2 * item_byte_size), (int)(2 * item_byte_size),
-  DE.GetMaxU64Bitfield(&offset, item_byte_size, item_bit_size,
-   item_bit_offset));
+if (exe_scope->CalculateTarget()
+->ShouldShowHexValuesWithLeadingZeroes()) {
+  s->Printf(wantsuppercase ? "0x%*.*" PRIX64 : "0x%*.*" PRIx64,
+(int)(2 * item_byte_size), (int)(2 * item_byte_size),
+DE.GetMaxU64Bitfield(&offset, item_byte_size, 
item_bit_size,
+ item_bit_offset));
+} else {
+  s->Printf(wantsuppercase ? "0x%" PRIX64 : "0x%" PRIx64,
+DE.GetMaxU64Bitfield(&offset, item_byte_size, 
item_bit_size,
+ item_bit_offset));
+}
 break;
   default: {
 assert(item_bit_size == 0 && item_bit_offset == 0);
diff --git a/lldb/source/Target/Target.cpp b/lldb/source/Target/Target.cpp
index 35f5ef324fde667..87746d7aa3c32aa 100644
--- a/lldb/source/Target/Target.cpp
+++ b/lldb/source/Target/Target.cpp
@@ -4236,8 +4236,8 @@ bool 
TargetProperties::SetPreferDynamicValue(lldb::DynamicValueType d) {
 }
 
 bool TargetProperties::GetPreloadSymbols() const {
-  if (INTERRUPT_REQUESTED(m_target->GetDebugger(), 
-  "Interrupted checking preload symbols")) {
+  if (INTERRUPT_REQUESTED(m_target->GetDebugger(),
+  "Interrupted checking preload symbols")) {
 return false;
   }
   const uint32_t idx = ePropertyPreloadSymbols;
@@ -4539,6 +4539,12 @@ bool TargetProperties::GetEnableSyntheticValue() const {
   idx, g_target_properties[idx].default_uint_value != 0);
 }
 
+bool TargetProperties::ShouldShowHexValuesWithLeadingZeroes() const {
+  const uint32_t idx = ePropertyShowHexValuesWithLeadingZeroes;
+  return GetPropertyAtIndexAs(
+  idx, g_target_properties[idx].default_uint_value != 0);
+}
+
 uint32_t TargetProperties::GetMaxZeroPaddingInFloatFormat() const {
   const uint32_t idx = ePropertyMaxZeroPaddingInFloatFormat;
   return GetPropertyAtIndexAs(
diff --git a/lldb/source/Target/TargetProperties.td 
b/lldb/source/Target/TargetProperties.td
index 3bfdfa8cfaa957f..9f639842a80841a 100644
--- a/lldb/source/Target/TargetProperties.td
+++ b/lldb/source/Target/TargetProperties.td
@@ -82,6 +82,9 @@ let Definition = "target" in {
   def SaveObjectsDir: Property<"save-jit-objects-dir", "FileSpec">,
 DefaultStringValue<"">,
 Desc<"If specified, the directory to save intermediate object files 
generated by the LLVM JIT">;
+  def ShowHexValuesWithLeadingZeroes: 
Property<"show-hex-values-with-leading-zeroes", "Boolean">,
+DefaultTrue,
+Desc<"Whether to display leading zeroes in hex ValueObject values.">;
   def MaxZeroPaddingInFloatFormat: 
Property<"max-zero-padding-in-float-format", "UInt64">,
 DefaultUnsignedValue<6>,
 Desc<"The maximum number of zeroes to insert when displaying a very small 
float before falling back to scientific notation.">;
diff --git a/lldb/test/API/python_api/value/TestValueAPI.py 
b/lldb/test/API/python_api/value/TestValueAPI.py
index eb709ca4728b089..05670b8db9bb77a 100644
--- a/lldb/test/API/python_api/value/TestValueAPI.py
+++ b/lldb/test/

[Lldb-commits] [lldb] [LLDB] Add a setting for print hex values without leading zeroes (PR #66548)

[Greg Clayton via lldb-commits]

https://github.com/clayborg approved this pull request.

Nice! LGTM

https://github.com/llvm/llvm-project/pull/66548
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [LLDB] Add a setting for print hex values without leading zeroes (PR #66548)

[Greg Clayton via lldb-commits]

https://github.com/clayborg edited 
https://github.com/llvm/llvm-project/pull/66548
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [LLDB] Add a setting for print hex values without leading zeroes (PR #66548)

[Greg Clayton via lldb-commits]

@@ -620,10 +620,17 @@ lldb::offset_t lldb_private::DumpDataExtractor(
   case 2:
   case 4:
   case 8:
-s->Printf(wantsuppercase ? "0x%*.*" PRIX64 : "0x%*.*" PRIx64,
-  (int)(2 * item_byte_size), (int)(2 * item_byte_size),
-  DE.GetMaxU64Bitfield(&offset, item_byte_size, item_bit_size,
-   item_bit_offset));
+if (exe_scope->CalculateTarget()

clayborg wrote:

Actually do you need to test if "exe_scope" is not NULL here?

https://github.com/llvm/llvm-project/pull/66548
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [LLDB] Add a setting for print hex values without leading zeroes (PR #66548)

[Greg Clayton via lldb-commits]

https://github.com/clayborg requested changes to this pull request.


https://github.com/llvm/llvm-project/pull/66548
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [LLDB] Add a setting for print hex values without leading zeroes (PR #66548)

[Walter Erquinigo via lldb-commits]

https://github.com/walter-erquinigo updated 
https://github.com/llvm/llvm-project/pull/66548

>From 99b2a5e3663263fd1a92e350a3254fafbe9724c5 Mon Sep 17 00:00:00 2001
From: walter erquinigo 
Date: Fri, 15 Sep 2023 16:41:23 -0400
Subject: [PATCH] [LLDB] Add a setting for print hex values without leading
 zeroes

As suggested by Greg in https://github.com/llvm/llvm-project/pull/66534, I'm 
adding a setting at the Target level that controls whether to show leading 
zeroes in hex ValueObject values.

This has the benefit of reducing the amount of characters displayed in certain 
interfaces, like VSCode.
---
 lldb/include/lldb/Target/Target.h  |  2 ++
 lldb/source/Core/DumpDataExtractor.cpp | 18 ++
 lldb/source/Target/Target.cpp  | 10 --
 lldb/source/Target/TargetProperties.td |  3 +++
 lldb/test/API/python_api/value/TestValueAPI.py | 17 -
 lldb/test/API/python_api/value/main.c  |  7 +--
 6 files changed, 48 insertions(+), 9 deletions(-)

diff --git a/lldb/include/lldb/Target/Target.h 
b/lldb/include/lldb/Target/Target.h
index ed0ecbbddbf8149..b2dcd3b0b3d30a0 100644
--- a/lldb/include/lldb/Target/Target.h
+++ b/lldb/include/lldb/Target/Target.h
@@ -167,6 +167,8 @@ class TargetProperties : public Properties {
 
   bool GetEnableSyntheticValue() const;
 
+  bool ShouldShowHexValuesWithLeadingZeroes() const;
+
   uint32_t GetMaxZeroPaddingInFloatFormat() const;
 
   uint32_t GetMaximumNumberOfChildrenToDisplay() const;
diff --git a/lldb/source/Core/DumpDataExtractor.cpp 
b/lldb/source/Core/DumpDataExtractor.cpp
index cb76b118325b7ef..3db751b6faa3ff9 100644
--- a/lldb/source/Core/DumpDataExtractor.cpp
+++ b/lldb/source/Core/DumpDataExtractor.cpp
@@ -620,10 +620,20 @@ lldb::offset_t lldb_private::DumpDataExtractor(
   case 2:
   case 4:
   case 8:
-s->Printf(wantsuppercase ? "0x%*.*" PRIX64 : "0x%*.*" PRIx64,
-  (int)(2 * item_byte_size), (int)(2 * item_byte_size),
-  DE.GetMaxU64Bitfield(&offset, item_byte_size, item_bit_size,
-   item_bit_offset));
+// If we don't have an ExecutionScope, we print with leading zeroes to
+// preserve behavior that LLDB had before the
+// show-hex-values-with-leading-zeroes setting was added.
+if (!exe_scope || exe_scope->CalculateTarget()
+  ->ShouldShowHexValuesWithLeadingZeroes()) {
+  s->Printf(wantsuppercase ? "0x%*.*" PRIX64 : "0x%*.*" PRIx64,
+(int)(2 * item_byte_size), (int)(2 * item_byte_size),
+DE.GetMaxU64Bitfield(&offset, item_byte_size, 
item_bit_size,
+ item_bit_offset));
+} else {
+  s->Printf(wantsuppercase ? "0x%" PRIX64 : "0x%" PRIx64,
+DE.GetMaxU64Bitfield(&offset, item_byte_size, 
item_bit_size,
+ item_bit_offset));
+}
 break;
   default: {
 assert(item_bit_size == 0 && item_bit_offset == 0);
diff --git a/lldb/source/Target/Target.cpp b/lldb/source/Target/Target.cpp
index 35f5ef324fde667..87746d7aa3c32aa 100644
--- a/lldb/source/Target/Target.cpp
+++ b/lldb/source/Target/Target.cpp
@@ -4236,8 +4236,8 @@ bool 
TargetProperties::SetPreferDynamicValue(lldb::DynamicValueType d) {
 }
 
 bool TargetProperties::GetPreloadSymbols() const {
-  if (INTERRUPT_REQUESTED(m_target->GetDebugger(), 
-  "Interrupted checking preload symbols")) {
+  if (INTERRUPT_REQUESTED(m_target->GetDebugger(),
+  "Interrupted checking preload symbols")) {
 return false;
   }
   const uint32_t idx = ePropertyPreloadSymbols;
@@ -4539,6 +4539,12 @@ bool TargetProperties::GetEnableSyntheticValue() const {
   idx, g_target_properties[idx].default_uint_value != 0);
 }
 
+bool TargetProperties::ShouldShowHexValuesWithLeadingZeroes() const {
+  const uint32_t idx = ePropertyShowHexValuesWithLeadingZeroes;
+  return GetPropertyAtIndexAs(
+  idx, g_target_properties[idx].default_uint_value != 0);
+}
+
 uint32_t TargetProperties::GetMaxZeroPaddingInFloatFormat() const {
   const uint32_t idx = ePropertyMaxZeroPaddingInFloatFormat;
   return GetPropertyAtIndexAs(
diff --git a/lldb/source/Target/TargetProperties.td 
b/lldb/source/Target/TargetProperties.td
index 3bfdfa8cfaa957f..9f639842a80841a 100644
--- a/lldb/source/Target/TargetProperties.td
+++ b/lldb/source/Target/TargetProperties.td
@@ -82,6 +82,9 @@ let Definition = "target" in {
   def SaveObjectsDir: Property<"save-jit-objects-dir", "FileSpec">,
 DefaultStringValue<"">,
 Desc<"If specified, the directory to save intermediate object files 
generated by the LLVM JIT">;
+  def ShowHexValuesWithLeadingZeroes: 
Property<"show-hex-values-with-leading-zeroes", "Boolean">,
+DefaultTrue,
+Desc<"Whether to display leading zeroes in hex ValueObject values.">;
   def MaxZeroPa

[Lldb-commits] [lldb] [LLDB] Add a setting for print hex values without leading zeroes (PR #66548)

[via lldb-commits]

jimingham wrote:

There are other places we print hex numbers that don't go through the 
DataExtractor.  For instance, the "location" for a ValueObject is printed 
directly, so this change wouldn't catch it.  It's a little off-putting if you 
set a global setting to "not print leading zeros" and then sometimes we still 
print leading zeros.

This is not an objection to the contents of this patch, but I think to be 
complete we're going to end up finding more places where we should be checking 
this policy setting.

https://github.com/llvm/llvm-project/pull/66548
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [LLDB] Add a setting for printing ValueObject hex values without leading zeroes (PR #66548)

[Walter Erquinigo via lldb-commits]

https://github.com/walter-erquinigo edited 
https://github.com/llvm/llvm-project/pull/66548
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [LLDB] Add a setting for printing ValueObject hex values without leading zeroes (PR #66548)

[Walter Erquinigo via lldb-commits]

walter-erquinigo wrote:

@jimingham , that's a good catch. Probably I should rename this because I want 
this setting to affect only SBValueObject::GetValue(), which is want ends up 
being sent to IDEs as a common interface. Trying to control all places that 
print as hex value is a bit too much and it'll be hard to enforce in the long 
term. Any particular suggestion? Because I can't really come up with a good 
name better than  `show-leading-zeroes-in-valueobject-values`.

https://github.com/llvm/llvm-project/pull/66548
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Add 'modify' type watchpoints, make it default (PR #66308)

[Jason Molenda via lldb-commits]

https://github.com/jasonmolenda updated 
https://github.com/llvm/llvm-project/pull/66308

>From 1efbce9f3b754f45372f0098163e70c2118b57d9 Mon Sep 17 00:00:00 2001
From: Jason Molenda 
Date: Wed, 13 Sep 2023 17:38:31 -0700
Subject: [PATCH 1/2] [lldb] Add 'modify' type watchpoints, make it default

Watchpoints in lldb can be either 'read', 'write', or
'read/write'.  This is exposing the actual behavior of
hardware watchpoints.  gdb has a different behavior:
a "write" type watchpoint only stops when the watched
memory region *changes*.

A user is using a watchpoint for one of three reasons:

1. Want to find what is changing/corrupting this memory.
3. Want to find what is reading from this memory.
2. Want to find what is writing to this memory.

I believe (1) is the most common use case for watchpoints,
and it currently can't be done in lldb -- the user needs
to continue every time the same value is written to the
watched-memory manually.  I think gdb's behavior is the
correct one.  There are some use cases where a developer
wants to find every function that writes/reads to/from a memory
region, regardless of value, I want to still allow that
functionality.

This is also a bit of groundwork for my large watchpoint
support proposal
https://discourse.llvm.org/t/rfc-large-watchpoint-support-in-lldb/72116
where I will be adding support for AArch64 MASK watchpoints
which watch power-of-2 memory regions.  A user might ask
to watch 24 bytes, and a MASK watchpoint stub can do this
with a 32-byte MASK watchpoint if it is properly aligned.
And we need to ignore writes to the final 8 bytes of that
watched region, and not show those hits to the user.

This patch adds a new 'modify' watchpoint type and it
is the default.

The part of this patch I think is the most questionable
is the
SBTarget::CreateWatchpoint(addr, size, bool read, bool write, error)
which I currently change the meaning of write==True to be
Modify.  This is part of making 'modify' the default watchpoint
type - a driver is likely setting write==True for its watchpoints.

I chatted with Alex and Jim about this a little and I'm not sure
how I should solve this for real.  Add a new SBTarget::CreateWatchpoint
API with a third `bool modify` argument in addition to the old one?
Add a new SBWatchpointOptions class in case we want to add more
types of watchpoints?  I'm not sure what other types of watchpoints
we'd want to hardcode in our support.  We have conditional expressions
or python callbacks that can do more unique operations.

There's more work here - the SB API needs to give the driver a way
to specify all three possible types of watchpoint ('write' and
'modify' being exclusive of the other) - but I'd love to hear what
other people think we should do for this API especially.
---
 lldb/include/lldb/Breakpoint/Watchpoint.h |  5 ++-
 .../lldb/Interpreter/OptionGroupWatchpoint.h  |  6 ++-
 lldb/include/lldb/lldb-defines.h  |  4 +-
 lldb/source/API/SBTarget.cpp  |  2 +-
 lldb/source/API/SBValue.cpp   |  2 +-
 lldb/source/Breakpoint/Watchpoint.cpp | 43 +--
 .../Commands/CommandObjectWatchpoint.cpp  | 30 ++---
 .../Interpreter/OptionGroupWatchpoint.cpp |  9 +++-
 .../Process/gdb-remote/ProcessGDBRemote.cpp   |  9 ++--
 lldb/source/Target/StopInfo.cpp   |  7 +++
 lldb/source/Target/Target.cpp |  3 +-
 .../watchpoint/modify-watchpoints/Makefile|  3 ++
 .../TestModifyWatchpoint.py   | 27 
 .../watchpoint/modify-watchpoints/main.c  | 17 
 14 files changed, 143 insertions(+), 24 deletions(-)
 create mode 100644 
lldb/test/API/functionalities/watchpoint/modify-watchpoints/Makefile
 create mode 100644 
lldb/test/API/functionalities/watchpoint/modify-watchpoints/TestModifyWatchpoint.py
 create mode 100644 
lldb/test/API/functionalities/watchpoint/modify-watchpoints/main.c

diff --git a/lldb/include/lldb/Breakpoint/Watchpoint.h 
b/lldb/include/lldb/Breakpoint/Watchpoint.h
index 8fde3b563a3f064..c86d3c7f8c0 100644
--- a/lldb/include/lldb/Breakpoint/Watchpoint.h
+++ b/lldb/include/lldb/Breakpoint/Watchpoint.h
@@ -76,12 +76,14 @@ class Watchpoint : public 
std::enable_shared_from_this,
   
   bool WatchpointRead() const;
   bool WatchpointWrite() const;
+  bool WatchpointModify() const;
   uint32_t GetIgnoreCount() const;
   void SetIgnoreCount(uint32_t n);
   void SetWatchpointType(uint32_t type, bool notify = true);
   void SetDeclInfo(const std::string &str);
   std::string GetWatchSpec();
   void SetWatchSpec(const std::string &str);
+  bool WatchedValueReportable(const ExecutionContext &exe_ctx);
 
   // Snapshot management interface.
   bool IsWatchVariable() const;
@@ -212,7 +214,8 @@ class Watchpoint : public 
std::enable_shared_from_this,
   // again, we check the count, if it is more than 1, it means the user-
   // supplied actions actually want the watchpoint to be disabled!
   uint32_t m_watch_read :

[Lldb-commits] [lldb] [LLDB] Add a setting for printing ValueObject hex values without leading zeroes (PR #66548)

[via lldb-commits]

jimingham wrote:

That really should be 
`show-leading-zeros-in-valueobject-variables-using-hex-format`, shouldn't it?  
I think you can actually just document what it actually does in the help string 
and then you shouldn't have to make the name overly pedantic.   The one you 
have already is probably enough.

https://github.com/llvm/llvm-project/pull/66548
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [LLDB] Add a setting for printing ValueObject hex values without leading zeroes (PR #66548)

[Greg Clayton via lldb-commits]

clayborg wrote:

> @jimingham , that's a good catch. Probably I should rename this because I 
> want this setting to affect only SBValueObject::GetValue(), which is want 
> ends up being sent to IDEs as a common interface. Trying to control all 
> places that print as hex value is a bit too much and it'll be hard to enforce 
> in the long term. Any particular suggestion? Because I can't really come up 
> with a good name better than `show-leading-zeroes-in-valueobject-values`.

I think the setting name is ok as is. No one outside of LLDB developers have 
any idea what "valueobject" means. Also this setting is 
"show-hex-values-with-leading-zeroes" which does mention "values" so it can be 
ok for not all hex values emitted that are not values to have leading zeroes. 
The location is not a "value" technically and we might want some values coming 
out with leading zeroes like any command that dumps out table style output like 
"image dymp symtab" and other areas. Maybe we can name this setting:
```
show-hex-variable-values-with-leading-zeroes
```
The confirm this is for variable values only and not a system wide thing? 

If we switch the setting to be global in the target settings we can get the 
global target settings without needing to check the exe_scope. Thoughts?

https://github.com/llvm/llvm-project/pull/66548
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [LLDB] Add a setting for printing ValueObject hex values without leading zeroes (PR #66548)

[Walter Erquinigo via lldb-commits]

walter-erquinigo wrote:

I like Greg's proposal of naming it 
`show-hex-variable-values-with-leading-zeroes`. Seems very clear. I also like 
the idea of making it a global target config, which would simplify the code.

https://github.com/llvm/llvm-project/pull/66548
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb-vscode] Show addresses next to dereferenced summaries when using enableAutoVariableSummaries (PR #66551)

[Walter Erquinigo via lldb-commits]

https://github.com/walter-erquinigo created 
https://github.com/llvm/llvm-project/pull/66551

enableAutoVariableSummaries is a setting that enhances the summaries of 
variables in the IDE. A shortcoming of this feature is that it wasn't showing 
the addresses of pointers, which is valuable information. This fixes it by 
adding it whenever applicable.


>From 776f589a3fdfd160ce449461d0d2936e52849bd2 Mon Sep 17 00:00:00 2001
From: walter erquinigo 
Date: Fri, 15 Sep 2023 16:50:35 -0400
Subject: [PATCH] [lldb-vscode] Show addresses next to dereferenced summaries
 when using enableAutoVariableSummaries

enableAutoVariableSummaries is a setting that enhances the summaries of 
variables in the IDE. A shortcoming of this feature is that it wasn't showing 
the addresses of pointers, which is valuable information. This fixes it by 
adding it whenever applicable.
---
 .../evaluate/TestVSCode_evaluate.py   |  5 +-
 .../API/tools/lldb-vscode/evaluate/main.cpp   |  3 +-
 lldb/tools/lldb-vscode/JSONUtils.cpp  | 51 +++
 3 files changed, 36 insertions(+), 23 deletions(-)

diff --git a/lldb/test/API/tools/lldb-vscode/evaluate/TestVSCode_evaluate.py 
b/lldb/test/API/tools/lldb-vscode/evaluate/TestVSCode_evaluate.py
index 3cfe02ef6aa1576..bf3b16067fed2fa 100644
--- a/lldb/test/API/tools/lldb-vscode/evaluate/TestVSCode_evaluate.py
+++ b/lldb/test/API/tools/lldb-vscode/evaluate/TestVSCode_evaluate.py
@@ -63,7 +63,10 @@ def run_test_evaluate_expressions(
 "struct1", "{foo:15}" if enableAutoVariableSummaries else 
"my_struct @ 0x"
 )
 self.assertEvaluate(
-"struct2", "{foo:16}" if enableAutoVariableSummaries else "0x.*"
+"struct2", "0x.* → {foo:16}" if enableAutoVariableSummaries else 
"0x.*"
+)
+self.assertEvaluate(
+"struct3", "0x.*0"
 )
 self.assertEvaluate("struct1.foo", "15")
 self.assertEvaluate("struct2->foo", "16")
diff --git a/lldb/test/API/tools/lldb-vscode/evaluate/main.cpp 
b/lldb/test/API/tools/lldb-vscode/evaluate/main.cpp
index 3a541b21b220828..f09d00e6444bb79 100644
--- a/lldb/test/API/tools/lldb-vscode/evaluate/main.cpp
+++ b/lldb/test/API/tools/lldb-vscode/evaluate/main.cpp
@@ -18,6 +18,7 @@ struct my_struct {
 int main(int argc, char const *argv[]) {
   my_struct struct1 = {15};
   my_struct *struct2 = new my_struct{16};
+  my_struct *struct3 = nullptr;
   int var1 = 20;
   int var2 = 21;
   int var3 = static_int; // breakpoint 1
@@ -43,6 +44,6 @@ int main(int argc, char const *argv[]) {
   my_bool_vec.push_back(true);
   my_bool_vec.push_back(false); // breakpoint 6
   my_bool_vec.push_back(true); // breakpoint 7
-  
+
   return 0;
 }
diff --git a/lldb/tools/lldb-vscode/JSONUtils.cpp 
b/lldb/tools/lldb-vscode/JSONUtils.cpp
index c6b422e4d7a02e6..d475f45bec459bb 100644
--- a/lldb/tools/lldb-vscode/JSONUtils.cpp
+++ b/lldb/tools/lldb-vscode/JSONUtils.cpp
@@ -203,10 +203,12 @@ static bool ShouldBeDereferencedForSummary(lldb::SBValue 
&v) {
   if (!v.GetType().IsPointerType() && !v.GetType().IsReferenceType())
 return false;
 
-  // If we are referencing a pointer, we don't dereference to avoid confusing
-  // the user with the addresses that could shown in the summary.
-  if (v.Dereference().GetType().IsPointerType())
-return false;
+  // We don't want to dereference invalid data.
+  if (!v.IsSynthetic()) {
+lldb::addr_t address = v.GetValueAsUnsigned(0);
+if (address == 0 && address == LLDB_INVALID_ADDRESS)
+  return false;
+  }
 
   // If it's synthetic or a pointer to a basic type that provides a summary, we
   // don't dereference.
@@ -227,33 +229,40 @@ void SetValueForKey(lldb::SBValue &v, llvm::json::Object 
&object,
   if (!error.Success()) {
 strm << "";
   } else {
-auto tryDumpSummaryAndValue = [&strm](lldb::SBValue value) {
+auto tryDumpSummaryAndValue =
+[](lldb::SBValue value) -> std::optional {
   llvm::StringRef val = value.GetValue();
   llvm::StringRef summary = value.GetSummary();
   if (!val.empty()) {
-strm << val;
+std::string dump;
+llvm::raw_string_ostream os(dump);
+os << val;
 if (!summary.empty())
-  strm << ' ' << summary;
-return true;
+  os << ' ' << summary;
+return dump;
   }
-  if (!summary.empty()) {
-strm << ' ' << summary;
-return true;
-  }
-  if (auto container_summary = GetSyntheticSummaryForContainer(value)) {
-strm << *container_summary;
-return true;
-  }
-  return false;
+  if (!summary.empty())
+return summary.str();
+  return GetSyntheticSummaryForContainer(value);
 };
 
+bool done = false;
 // We first try to get the summary from its dereferenced value.
-bool done = ShouldBeDereferencedForSummary(v) &&
-tryDumpSummaryAndValue(v.Dereference());
+if (ShouldBeDereferencedForSummary(v)) {
+  if (std::optio

[Lldb-commits] [lldb] [lldb-vscode] Show addresses next to dereferenced summaries when using enableAutoVariableSummaries (PR #66551)

[Walter Erquinigo via lldb-commits]

https://github.com/walter-erquinigo edited 
https://github.com/llvm/llvm-project/pull/66551
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb-vscode] Show addresses next to dereferenced summaries when using enableAutoVariableSummaries (PR #66551)

[via lldb-commits]

llvmbot wrote:




@llvm/pr-subscribers-lldb


Changes

enableAutoVariableSummaries is a setting that enhances the summaries of 
variables in the IDE. A shortcoming of this feature is that it wasn't showing 
the addresses of pointers, which is valuable information. This fixes it by 
adding it whenever applicable.

An example of the proposal:
;

---
Full diff: https://github.com/llvm/llvm-project/pull/66551.diff


3 Files Affected:

- (modified) lldb/test/API/tools/lldb-vscode/evaluate/TestVSCode_evaluate.py 
(+4-1) 
- (modified) lldb/test/API/tools/lldb-vscode/evaluate/main.cpp (+2-1) 
- (modified) lldb/tools/lldb-vscode/JSONUtils.cpp (+30-21) 


``diff
diff --git a/lldb/test/API/tools/lldb-vscode/evaluate/TestVSCode_evaluate.py 
b/lldb/test/API/tools/lldb-vscode/evaluate/TestVSCode_evaluate.py
index 3cfe02ef6aa1576..bf3b16067fed2fa 100644
--- a/lldb/test/API/tools/lldb-vscode/evaluate/TestVSCode_evaluate.py
+++ b/lldb/test/API/tools/lldb-vscode/evaluate/TestVSCode_evaluate.py
@@ -63,7 +63,10 @@ def run_test_evaluate_expressions(
 "struct1", "{foo:15}" if enableAutoVariableSummaries else 
"my_struct @ 0x"
 )
 self.assertEvaluate(
-"struct2", "{foo:16}" if enableAutoVariableSummaries else "0x.*"
+"struct2", "0x.* → {foo:16}" if enableAutoVariableSummaries else 
"0x.*"
+)
+self.assertEvaluate(
+"struct3", "0x.*0"
 )
 self.assertEvaluate("struct1.foo", "15")
 self.assertEvaluate("struct2->foo", "16")
diff --git a/lldb/test/API/tools/lldb-vscode/evaluate/main.cpp 
b/lldb/test/API/tools/lldb-vscode/evaluate/main.cpp
index 3a541b21b220828..f09d00e6444bb79 100644
--- a/lldb/test/API/tools/lldb-vscode/evaluate/main.cpp
+++ b/lldb/test/API/tools/lldb-vscode/evaluate/main.cpp
@@ -18,6 +18,7 @@ struct my_struct {
 int main(int argc, char const *argv[]) {
   my_struct struct1 = {15};
   my_struct *struct2 = new my_struct{16};
+  my_struct *struct3 = nullptr;
   int var1 = 20;
   int var2 = 21;
   int var3 = static_int; // breakpoint 1
@@ -43,6 +44,6 @@ int main(int argc, char const *argv[]) {
   my_bool_vec.push_back(true);
   my_bool_vec.push_back(false); // breakpoint 6
   my_bool_vec.push_back(true); // breakpoint 7
-  
+
   return 0;
 }
diff --git a/lldb/tools/lldb-vscode/JSONUtils.cpp 
b/lldb/tools/lldb-vscode/JSONUtils.cpp
index c6b422e4d7a02e6..d475f45bec459bb 100644
--- a/lldb/tools/lldb-vscode/JSONUtils.cpp
+++ b/lldb/tools/lldb-vscode/JSONUtils.cpp
@@ -203,10 +203,12 @@ static bool ShouldBeDereferencedForSummary(lldb::SBValue 
&v) {
   if (!v.GetType().IsPointerType() && !v.GetType().IsReferenceType())
 return false;
 
-  // If we are referencing a pointer, we don't dereference to avoid confusing
-  // the user with the addresses that could shown in the summary.
-  if (v.Dereference().GetType().IsPointerType())
-return false;
+  // We don't want to dereference invalid data.
+  if (!v.IsSynthetic()) {
+lldb::addr_t address = v.GetValueAsUnsigned(0);
+if (address == 0 && address == LLDB_INVALID_ADDRESS)
+  return false;
+  }
 
   // If it's synthetic or a pointer to a basic type that provides a summary, we
   // don't dereference.
@@ -227,33 +229,40 @@ void SetValueForKey(lldb::SBValue &v, llvm::json::Object 
&object,
   if (!error.Success()) {
 strm << "";
   } else {
-auto tryDumpSummaryAndValue = [&strm](lldb::SBValue value) {
+auto tryDumpSummaryAndValue =
+[](lldb::SBValue value) -> std::optional {
   llvm::StringRef val = value.GetValue();
   llvm::StringRef summary = value.GetSummary();
   if (!val.empty()) {
-strm << val;
+std::string dump;
+llvm::raw_string_ostream os(dump);
+os << val;
 if (!summary.empty())
-  strm << ' ' << summary;
-return true;
+  os << ' ' << summary;
+return dump;
   }
-  if (!summary.empty()) {
-strm << ' ' << summary;
-return true;
-  }
-  if (auto container_summary = GetSyntheticSummaryForContainer(value)) {
-strm << *container_summary;
-return true;
-  }
-  return false;
+  if (!summary.empty())
+return summary.str();
+  return GetSyntheticSummaryForContainer(value);
 };
 
+bool done = false;
 // We first try to get the summary from its dereferenced value.
-bool done = ShouldBeDereferencedForSummary(v) &&
-tryDumpSummaryAndValue(v.Dereference());
+if (ShouldBeDereferencedForSummary(v)) {
+  if (std::optional text =
+  tryDumpSummaryAndValue(v.Dereference())) {
+strm << v.GetValue() << " → " << *text;
+done = true;
+  }
+}
 
 // We then try to get it from the current value itself.
-if (!done)
-  done = tryDumpSummaryAndValue(v);
+   

[Lldb-commits] [lldb] [lldb] Add 'modify' type watchpoints, make it default (PR #66308)

[Greg Clayton via lldb-commits]

@@ -0,0 +1,44 @@
+//===-- SBWatchpointOptions.h ---*- C++ 
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef LLDB_API_SBWATCHPOINTOPTIONS_H
+#define LLDB_API_SBWATCHPOINTOPTIONS_H
+
+#include "lldb/API/SBDefines.h"
+
+class WatchpointOptionsImpl;
+
+namespace lldb {
+
+class LLDB_API SBWatchpointOptions {
+public:
+  SBWatchpointOptions();
+
+  SBWatchpointOptions(const lldb::SBWatchpointOptions &rhs);
+
+  ~SBWatchpointOptions();
+
+  const SBWatchpointOptions &operator=(const lldb::SBWatchpointOptions &rhs);
+
+  void SetWatchpointTypeRead(bool read);
+  bool GetWatchpointTypeRead() const;
+

clayborg wrote:

Add header doc here to explain that write mode will stop on any write even if 
the value doesn't change

https://github.com/llvm/llvm-project/pull/66308
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Add 'modify' type watchpoints, make it default (PR #66308)

[Greg Clayton via lldb-commits]

@@ -1326,23 +1326,35 @@ lldb::SBWatchpoint SBTarget::WatchAddress(lldb::addr_t 
addr, size_t size,
   SBError &error) {
   LLDB_INSTRUMENT_VA(this, addr, size, read, write, error);
 
+  SBWatchpointOptions options;
+  options.SetWatchpointTypeRead(read);
+  options.SetWatchpointTypeModify(write);

clayborg wrote:

do we want to rename this argument from "write" to "modify" to clarify what 
will happen? Variable names are not included in the mangled name, so we can 
rename as long as we don't change the type and not affect the API backwards 
compat. If we do rename, then update the header file as well

https://github.com/llvm/llvm-project/pull/66308
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Add 'modify' type watchpoints, make it default (PR #66308)

[Greg Clayton via lldb-commits]

@@ -46,7 +46,9 @@ def test_unaligned_watchpoint(self):
 a_bytebuf_6 = frame.GetValueForVariablePath("a.bytebuf[6]")
 a_bytebuf_6_addr = a_bytebuf_6.GetAddress().GetLoadAddress(target)
 err = lldb.SBError()
-wp = target.WatchAddress(a_bytebuf_6_addr, 4, False, True, err)
+wp_opts = lldb.SBWatchpointOptions()
+wp_opts.SetWatchpointTypeModify(True)
+wp = target.WatchpointCreateByAddress(a_bytebuf_6_addr, 4, wp_opts, 
err)
 self.assertTrue(err.Success())

clayborg wrote:

No need to change this test if it still uses the old API. Revert?

https://github.com/llvm/llvm-project/pull/66308
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Add 'modify' type watchpoints, make it default (PR #66308)

[Greg Clayton via lldb-commits]

@@ -0,0 +1,44 @@
+//===-- SBWatchpointOptions.h ---*- C++ 
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef LLDB_API_SBWATCHPOINTOPTIONS_H
+#define LLDB_API_SBWATCHPOINTOPTIONS_H
+
+#include "lldb/API/SBDefines.h"
+
+class WatchpointOptionsImpl;
+
+namespace lldb {
+
+class LLDB_API SBWatchpointOptions {
+public:
+  SBWatchpointOptions();
+
+  SBWatchpointOptions(const lldb::SBWatchpointOptions &rhs);
+
+  ~SBWatchpointOptions();
+
+  const SBWatchpointOptions &operator=(const lldb::SBWatchpointOptions &rhs);
+

clayborg wrote:

add a header doc explaining this will stop any time memory is read from. Might 
want to mention if this works along with "modify" at all to only stop when 
reading a value and that value has changed?

https://github.com/llvm/llvm-project/pull/66308
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Add 'modify' type watchpoints, make it default (PR #66308)

[Greg Clayton via lldb-commits]

@@ -53,7 +53,10 @@ def fuzz_obj(obj):
 obj.GetByteOrder()
 obj.GetTriple()
 error = lldb.SBError()
-obj.WatchAddress(123, 8, True, True, error)
+wp_opts = lldb.SBWatchpointOptions()
+wp_opts.SetWatchpointTypeRead(True)
+wp_opts.SetWatchpointTypeModify(True)
+obj.WatchpointCreateByAddress(123, 8, wp_opts, error)

clayborg wrote:

Revert and keep old API usage?

https://github.com/llvm/llvm-project/pull/66308
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Add 'modify' type watchpoints, make it default (PR #66308)

[Greg Clayton via lldb-commits]

@@ -0,0 +1,67 @@
+//===-- SBWatchpointOptions.cpp 
---===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "lldb/API/SBWatchpointOptions.h"
+#include "lldb/Breakpoint/Watchpoint.h"
+#include "lldb/Utility/Instrumentation.h"
+
+#include "Utils.h"
+
+using namespace lldb;
+using namespace lldb_private;
+
+class WatchpointOptionsImpl {
+public:
+  bool m_read = false;
+  bool m_write = false;
+  bool m_modify = false;
+};

clayborg wrote:

This could be moved to Watchpoint.h and then used in our internal API as well 
if you like that idea.

https://github.com/llvm/llvm-project/pull/66308
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Add 'modify' type watchpoints, make it default (PR #66308)

[Greg Clayton via lldb-commits]

@@ -0,0 +1,44 @@
+//===-- SBWatchpointOptions.h ---*- C++ 
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef LLDB_API_SBWATCHPOINTOPTIONS_H
+#define LLDB_API_SBWATCHPOINTOPTIONS_H
+
+#include "lldb/API/SBDefines.h"
+
+class WatchpointOptionsImpl;
+
+namespace lldb {
+
+class LLDB_API SBWatchpointOptions {
+public:
+  SBWatchpointOptions();
+
+  SBWatchpointOptions(const lldb::SBWatchpointOptions &rhs);
+
+  ~SBWatchpointOptions();
+
+  const SBWatchpointOptions &operator=(const lldb::SBWatchpointOptions &rhs);
+
+  void SetWatchpointTypeRead(bool read);
+  bool GetWatchpointTypeRead() const;
+
+  void SetWatchpointTypeWrite(bool write);
+  bool GetWatchpointTypeWrite() const;
+
+  void SetWatchpointTypeModify(bool modify);

clayborg wrote:

add a header doc explaining this does and if it can be used along with "read" 
or "write" or only "write"?

https://github.com/llvm/llvm-project/pull/66308
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb-vscode] Show addresses next to dereferenced summaries when using enableAutoVariableSummaries (PR #66551)

[Walter Erquinigo via lldb-commits]

https://github.com/walter-erquinigo ready_for_review 
https://github.com/llvm/llvm-project/pull/66551
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb-vscode] Show addresses next to dereferenced summaries when using enableAutoVariableSummaries (PR #66551)

[Walter Erquinigo via lldb-commits]

https://github.com/walter-erquinigo updated 
https://github.com/llvm/llvm-project/pull/66551

>From 31236a70c8d1736563a253dc3a2582366220cb8f Mon Sep 17 00:00:00 2001
From: walter erquinigo 
Date: Fri, 15 Sep 2023 16:50:35 -0400
Subject: [PATCH] [lldb-vscode] Show addresses next to dereferenced summaries
 when using enableAutoVariableSummaries

enableAutoVariableSummaries is a setting that enhances the summaries of 
variables in the IDE. A shortcoming of this feature is that it wasn't showing 
the addresses of pointers, which is valuable information. This fixes it by 
adding it whenever applicable.
---
 .../evaluate/TestVSCode_evaluate.py   |  3 +-
 .../API/tools/lldb-vscode/evaluate/main.cpp   |  3 +-
 lldb/tools/lldb-vscode/JSONUtils.cpp  | 51 +++
 3 files changed, 34 insertions(+), 23 deletions(-)

diff --git a/lldb/test/API/tools/lldb-vscode/evaluate/TestVSCode_evaluate.py 
b/lldb/test/API/tools/lldb-vscode/evaluate/TestVSCode_evaluate.py
index 3cfe02ef6aa1576..5632f33ae910724 100644
--- a/lldb/test/API/tools/lldb-vscode/evaluate/TestVSCode_evaluate.py
+++ b/lldb/test/API/tools/lldb-vscode/evaluate/TestVSCode_evaluate.py
@@ -63,8 +63,9 @@ def run_test_evaluate_expressions(
 "struct1", "{foo:15}" if enableAutoVariableSummaries else 
"my_struct @ 0x"
 )
 self.assertEvaluate(
-"struct2", "{foo:16}" if enableAutoVariableSummaries else "0x.*"
+"struct2", "0x.* → {foo:16}" if enableAutoVariableSummaries else 
"0x.*"
 )
+self.assertEvaluate("struct3", "0x.*0")
 self.assertEvaluate("struct1.foo", "15")
 self.assertEvaluate("struct2->foo", "16")
 
diff --git a/lldb/test/API/tools/lldb-vscode/evaluate/main.cpp 
b/lldb/test/API/tools/lldb-vscode/evaluate/main.cpp
index 3a541b21b220828..f09d00e6444bb79 100644
--- a/lldb/test/API/tools/lldb-vscode/evaluate/main.cpp
+++ b/lldb/test/API/tools/lldb-vscode/evaluate/main.cpp
@@ -18,6 +18,7 @@ struct my_struct {
 int main(int argc, char const *argv[]) {
   my_struct struct1 = {15};
   my_struct *struct2 = new my_struct{16};
+  my_struct *struct3 = nullptr;
   int var1 = 20;
   int var2 = 21;
   int var3 = static_int; // breakpoint 1
@@ -43,6 +44,6 @@ int main(int argc, char const *argv[]) {
   my_bool_vec.push_back(true);
   my_bool_vec.push_back(false); // breakpoint 6
   my_bool_vec.push_back(true); // breakpoint 7
-  
+
   return 0;
 }
diff --git a/lldb/tools/lldb-vscode/JSONUtils.cpp 
b/lldb/tools/lldb-vscode/JSONUtils.cpp
index c6b422e4d7a02e6..d475f45bec459bb 100644
--- a/lldb/tools/lldb-vscode/JSONUtils.cpp
+++ b/lldb/tools/lldb-vscode/JSONUtils.cpp
@@ -203,10 +203,12 @@ static bool ShouldBeDereferencedForSummary(lldb::SBValue 
&v) {
   if (!v.GetType().IsPointerType() && !v.GetType().IsReferenceType())
 return false;
 
-  // If we are referencing a pointer, we don't dereference to avoid confusing
-  // the user with the addresses that could shown in the summary.
-  if (v.Dereference().GetType().IsPointerType())
-return false;
+  // We don't want to dereference invalid data.
+  if (!v.IsSynthetic()) {
+lldb::addr_t address = v.GetValueAsUnsigned(0);
+if (address == 0 && address == LLDB_INVALID_ADDRESS)
+  return false;
+  }
 
   // If it's synthetic or a pointer to a basic type that provides a summary, we
   // don't dereference.
@@ -227,33 +229,40 @@ void SetValueForKey(lldb::SBValue &v, llvm::json::Object 
&object,
   if (!error.Success()) {
 strm << "";
   } else {
-auto tryDumpSummaryAndValue = [&strm](lldb::SBValue value) {
+auto tryDumpSummaryAndValue =
+[](lldb::SBValue value) -> std::optional {
   llvm::StringRef val = value.GetValue();
   llvm::StringRef summary = value.GetSummary();
   if (!val.empty()) {
-strm << val;
+std::string dump;
+llvm::raw_string_ostream os(dump);
+os << val;
 if (!summary.empty())
-  strm << ' ' << summary;
-return true;
+  os << ' ' << summary;
+return dump;
   }
-  if (!summary.empty()) {
-strm << ' ' << summary;
-return true;
-  }
-  if (auto container_summary = GetSyntheticSummaryForContainer(value)) {
-strm << *container_summary;
-return true;
-  }
-  return false;
+  if (!summary.empty())
+return summary.str();
+  return GetSyntheticSummaryForContainer(value);
 };
 
+bool done = false;
 // We first try to get the summary from its dereferenced value.
-bool done = ShouldBeDereferencedForSummary(v) &&
-tryDumpSummaryAndValue(v.Dereference());
+if (ShouldBeDereferencedForSummary(v)) {
+  if (std::optional text =
+  tryDumpSummaryAndValue(v.Dereference())) {
+strm << v.GetValue() << " → " << *text;
+done = true;
+  }
+}
 
 // We then try to get it from the current value itself.
-if (!done)
-  done = tryDumpSummaryAndValue(v);
+if