[Lldb-commits] [lldb] 41dc04e - [lldb] Add swig doc for SBProcess address mask methods
Author: Jason Molenda
Date: 2024-04-08T18:56:39-07:00
New Revision: 41dc04e5283adef9979cad2b126ab3e6c156034a
URL:
https://github.com/llvm/llvm-project/commit/41dc04e5283adef9979cad2b126ab3e6c156034a
DIFF:
https://github.com/llvm/llvm-project/commit/41dc04e5283adef9979cad2b126ab3e6c156034a.diff
LOG: [lldb] Add swig doc for SBProcess address mask methods
Add descriptions of `GetAddressMask`, `SetAddressMask`,
`SetAddressableBits`, and `FixAddress` SBProcess methods.
Added:
Modified:
lldb/bindings/interface/SBProcessDocstrings.i
Removed:
diff --git a/lldb/bindings/interface/SBProcessDocstrings.i
b/lldb/bindings/interface/SBProcessDocstrings.i
index c20ef3e4655bd4..1b98a79e4f6d36 100644
--- a/lldb/bindings/interface/SBProcessDocstrings.i
+++ b/lldb/bindings/interface/SBProcessDocstrings.i
@@ -199,6 +199,47 @@ SBProcess supports thread iteration. For example (from
test/lldbutil.py), ::
process_info.GetProcessID()"
) lldb::SBProcess::GetProcessInfo;
+%feature("docstring", "
+Get the current address mask in this Process of a given type.
+There are lldb.eAddressMaskTypeCode and lldb.eAddressMaskTypeData address
+masks, and on most Targets, the the Data address mask is more general
+because there are no alignment restrictions, as there can be with Code
+addresses.
+lldb.eAddressMaskTypeAny may be used to get the most general mask.
+The bits which are not used for addressing are set to 1 in the returned
+mask.
+In an unusual environment with
diff erent address masks for high and low
+memory, this may also be specified. This is uncommon, default is
+lldb.eAddressMaskRangeLow."
+) lldb::SBProcess::GetAddressMask;
+
+%feature("docstring", "
+Set the current address mask in this Process for a given type,
+lldb.eAddressMaskTypeCode or lldb.eAddressMaskTypeData. Bits that are not
+used for addressing should be set to 1 in the mask.
+When setting all masks, lldb.eAddressMaskTypeAll may be specified.
+In an unusual environment with
diff erent address masks for high and low
+memory, this may also be specified. This is uncommon, default is
+lldb.eAddressMaskRangeLow."
+) lldb::SBProcess::SetAddressMask;
+
+%feature("docstring", "
+Set the number of low bits relevant for addressing in this Process
+for a given type, lldb.eAddressMaskTypeCode or lldb.eAddressMaskTypeData.
+When setting all masks, lldb.eAddressMaskTypeAll may be specified.
+In an unusual environment with
diff erent address masks for high and low
+memory, the address range may also be specified. This is uncommon,
+default is lldb.eAddressMaskRangeLow."
+) lldb::SBProcess::SetAddressableBits;
+
+%feature("docstring", "
+Given a virtual address, clear the bits that are not used for addressing
+(and may be used for metadata, memory tagging, point authentication, etc).
+By default the most general mask, lldb.eAddressMaskTypeAny is used to
+process the address, but lldb.eAddressMaskTypeData and
+lldb.eAddressMaskTypeCode may be specified if the type of address is
known."
+) lldb::SBProcess::FixAddress;
+
%feature("docstring", "
Allocates a block of memory within the process, with size and
access permissions specified in the arguments. The permissions
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] [NFC] Fix swig docstring annotations (PR #88073)
https://github.com/jasonmolenda closed https://github.com/llvm/llvm-project/pull/88073 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] e35fb3f - [lldb] [NFC] Fix swig docstring annotations (#88073)
Author: Jason Molenda
Date: 2024-04-08T17:57:35-07:00
New Revision: e35fb3fb8bfcb732ace3738f9589989b3fac1508
URL:
https://github.com/llvm/llvm-project/commit/e35fb3fb8bfcb732ace3738f9589989b3fac1508
DIFF:
https://github.com/llvm/llvm-project/commit/e35fb3fb8bfcb732ace3738f9589989b3fac1508.diff
LOG: [lldb] [NFC] Fix swig docstring annotations (#88073)
Some of the SB API method description docstrings for swing are annotated
as `%feature("autodoc")` - but `"autodoc"` annotations are only to
substitute a string showing the arguments and return variables - either
in a single line, or in multiple lines. SBMemoryRegionInfo used
`"autodoc"` correctly describing the parameters and return type, but
then it added a description too which is not correct either.
Change all of these that are adding a method description to use
`%feature("docstring")` instead. There were a half dozen instances where
`"autodoc"` was correctly being used and we have overriden the parameter
and return types with a more readable version.
Added:
Modified:
lldb/bindings/interface/SBMemoryRegionInfoDocstrings.i
lldb/bindings/interface/SBProcessDocstrings.i
lldb/bindings/interface/SBQueueDocstrings.i
lldb/bindings/interface/SBThreadDocstrings.i
Removed:
diff --git a/lldb/bindings/interface/SBMemoryRegionInfoDocstrings.i
b/lldb/bindings/interface/SBMemoryRegionInfoDocstrings.i
index bd80740f3fdd3b..d7c68baf100e27 100644
--- a/lldb/bindings/interface/SBMemoryRegionInfoDocstrings.i
+++ b/lldb/bindings/interface/SBMemoryRegionInfoDocstrings.i
@@ -2,8 +2,7 @@
"API clients can get information about memory regions in processes."
) lldb::SBMemoryRegionInfo;
-%feature("autodoc", "
-GetRegionEnd(SBMemoryRegionInfo self) -> lldb::addr_t
+%feature("docstring", "
Returns whether this memory region has a list of modified (dirty)
pages available or not. When calling GetNumDirtyPages(), you will
have 0 returned for both \"dirty page list is not known\" and
@@ -11,8 +10,7 @@
memory region). You must use this method to disambiguate."
) lldb::SBMemoryRegionInfo::HasDirtyMemoryPageList;
-%feature("autodoc", "
-GetNumDirtyPages(SBMemoryRegionInfo self) -> uint32_t
+%feature("docstring", "
Return the number of dirty (modified) memory pages in this
memory region, if available. You must use the
SBMemoryRegionInfo::HasDirtyMemoryPageList() method to
@@ -20,16 +18,14 @@
on the target system can provide this information."
) lldb::SBMemoryRegionInfo::GetNumDirtyPages;
-%feature("autodoc", "
-GetDirtyPageAddressAtIndex(SBMemoryRegionInfo self, uint32_t idx) ->
lldb::addr_t
+%feature("docstring", "
Return the address of a modified, or dirty, page of memory.
If the provided index is out of range, or this memory region
does not have dirty page information, LLDB_INVALID_ADDRESS
is returned."
) lldb::SBMemoryRegionInfo::GetDirtyPageAddressAtIndex;
-%feature("autodoc", "
-GetPageSize(SBMemoryRegionInfo self) -> int
+%feature("docstring", "
Return the size of pages in this memory region. 0 will be returned
if this information was unavailable."
) lldb::SBMemoryRegionInfo::GetPageSize();
diff --git a/lldb/bindings/interface/SBProcessDocstrings.i
b/lldb/bindings/interface/SBProcessDocstrings.i
index 3ee17e0c7f2fbb..c20ef3e4655bd4 100644
--- a/lldb/bindings/interface/SBProcessDocstrings.i
+++ b/lldb/bindings/interface/SBProcessDocstrings.i
@@ -20,18 +20,18 @@ SBProcess supports thread iteration. For example (from
test/lldbutil.py), ::
"
) lldb::SBProcess;
-%feature("autodoc", "
+%feature("docstring", "
Writes data into the current process's stdin. API client specifies a Python
string as the only argument."
) lldb::SBProcess::PutSTDIN;
-%feature("autodoc", "
+%feature("docstring", "
Reads data from the current process's stdout stream. API client specifies
the size of the buffer to read data into. It returns the byte buffer in a
Python string."
) lldb::SBProcess::GetSTDOUT;
-%feature("autodoc", "
+%feature("docstring", "
Reads data from the current process's stderr stream. API client specifies
the size of the buffer to read data into. It returns the byte buffer in a
Python string."
@@ -47,34 +47,34 @@ SBProcess supports thread iteration. For example (from
test/lldbutil.py), ::
"See SBTarget.Launch for argument description and usage."
) lldb::SBProcess::RemoteLaunch;
-%feature("autodoc", "
+%feature("docstring", "
Returns the INDEX'th thread from the list of current threads. The index
of a thread is only valid for the current stop. For a persistent thread
identifier use either the thread ID or the IndexID. See help on SBThread
for more details."
) lldb::SBProcess::GetThreadAtIndex;
-%feature("autodoc", "
+%
[Lldb-commits] [lldb] [lldb] [NFC] Fix swig docstring annotations (PR #88073)
https://github.com/JDevlieghere approved this pull request. Good catch, that matches the [documentation](https://www.swig.org/Doc4.0/Python.html#Python_nn70). LGTM! https://github.com/llvm/llvm-project/pull/88073 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] [NFC] Fix swig docstring annotations (PR #88073)
jasonmolenda wrote: An example of the difference in the output this makes for `script help (lldb.SBProcess)`. Old: ``` | PutSTDIN(self, src) | Writes data into the current process's stdin. API client specifies a Python | string as the only argument. ``` new: ``` | PutSTDIN(self, src) | PutSTDIN(SBProcess self, char const * src) -> size_t | | Writes data into the current process's stdin. API client specifies a Python | string as the only argument. ``` https://github.com/llvm/llvm-project/pull/88073 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] [NFC] Fix swig docstring annotations (PR #88073)
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Jason Molenda (jasonmolenda)
Changes
Some of the SB API method description docstrings for swing are annotated as
`%feature("autodoc")` - but `"autodoc"` annotations are only to substitute a
string showing the arguments and return variables - either in a single line, or
in multiple lines. SBMemoryRegionInfo used `"autodoc"` correctly describing the
parameters and return type, but then it added a description too which is not
correct either.
Change all of these that are adding a method description to use
`%feature("docstring")` instead. There were a half dozen instances where
`"autodoc"` was correctly being used and we have overriden the parameter and
return types with a more readable version.
---
Full diff: https://github.com/llvm/llvm-project/pull/88073.diff
4 Files Affected:
- (modified) lldb/bindings/interface/SBMemoryRegionInfoDocstrings.i (+4-8)
- (modified) lldb/bindings/interface/SBProcessDocstrings.i (+25-25)
- (modified) lldb/bindings/interface/SBQueueDocstrings.i (+2-2)
- (modified) lldb/bindings/interface/SBThreadDocstrings.i (+17-19)
``diff
diff --git a/lldb/bindings/interface/SBMemoryRegionInfoDocstrings.i
b/lldb/bindings/interface/SBMemoryRegionInfoDocstrings.i
index bd80740f3fdd3b..d7c68baf100e27 100644
--- a/lldb/bindings/interface/SBMemoryRegionInfoDocstrings.i
+++ b/lldb/bindings/interface/SBMemoryRegionInfoDocstrings.i
@@ -2,8 +2,7 @@
"API clients can get information about memory regions in processes."
) lldb::SBMemoryRegionInfo;
-%feature("autodoc", "
-GetRegionEnd(SBMemoryRegionInfo self) -> lldb::addr_t
+%feature("docstring", "
Returns whether this memory region has a list of modified (dirty)
pages available or not. When calling GetNumDirtyPages(), you will
have 0 returned for both \"dirty page list is not known\" and
@@ -11,8 +10,7 @@
memory region). You must use this method to disambiguate."
) lldb::SBMemoryRegionInfo::HasDirtyMemoryPageList;
-%feature("autodoc", "
-GetNumDirtyPages(SBMemoryRegionInfo self) -> uint32_t
+%feature("docstring", "
Return the number of dirty (modified) memory pages in this
memory region, if available. You must use the
SBMemoryRegionInfo::HasDirtyMemoryPageList() method to
@@ -20,16 +18,14 @@
on the target system can provide this information."
) lldb::SBMemoryRegionInfo::GetNumDirtyPages;
-%feature("autodoc", "
-GetDirtyPageAddressAtIndex(SBMemoryRegionInfo self, uint32_t idx) ->
lldb::addr_t
+%feature("docstring", "
Return the address of a modified, or dirty, page of memory.
If the provided index is out of range, or this memory region
does not have dirty page information, LLDB_INVALID_ADDRESS
is returned."
) lldb::SBMemoryRegionInfo::GetDirtyPageAddressAtIndex;
-%feature("autodoc", "
-GetPageSize(SBMemoryRegionInfo self) -> int
+%feature("docstring", "
Return the size of pages in this memory region. 0 will be returned
if this information was unavailable."
) lldb::SBMemoryRegionInfo::GetPageSize();
diff --git a/lldb/bindings/interface/SBProcessDocstrings.i
b/lldb/bindings/interface/SBProcessDocstrings.i
index 3ee17e0c7f2fbb..c20ef3e4655bd4 100644
--- a/lldb/bindings/interface/SBProcessDocstrings.i
+++ b/lldb/bindings/interface/SBProcessDocstrings.i
@@ -20,18 +20,18 @@ SBProcess supports thread iteration. For example (from
test/lldbutil.py), ::
"
) lldb::SBProcess;
-%feature("autodoc", "
+%feature("docstring", "
Writes data into the current process's stdin. API client specifies a Python
string as the only argument."
) lldb::SBProcess::PutSTDIN;
-%feature("autodoc", "
+%feature("docstring", "
Reads data from the current process's stdout stream. API client specifies
the size of the buffer to read data into. It returns the byte buffer in a
Python string."
) lldb::SBProcess::GetSTDOUT;
-%feature("autodoc", "
+%feature("docstring", "
Reads data from the current process's stderr stream. API client specifies
the size of the buffer to read data into. It returns the byte buffer in a
Python string."
@@ -47,34 +47,34 @@ SBProcess supports thread iteration. For example (from
test/lldbutil.py), ::
"See SBTarget.Launch for argument description and usage."
) lldb::SBProcess::RemoteLaunch;
-%feature("autodoc", "
+%feature("docstring", "
Returns the INDEX'th thread from the list of current threads. The index
of a thread is only valid for the current stop. For a persistent thread
identifier use either the thread ID or the IndexID. See help on SBThread
for more details."
) lldb::SBProcess::GetThreadAtIndex;
-%feature("autodoc", "
+%feature("docstring", "
Returns the thread with the given thread ID."
) lldb::SBProcess::GetThreadByID;
-%feature("autodoc", "
+%feature("docstring", "
Returns the thread with the given thread
[Lldb-commits] [lldb] [lldb] [NFC] Fix swig docstring annotations (PR #88073)
https://github.com/jasonmolenda created
https://github.com/llvm/llvm-project/pull/88073
Some of the SB API method description docstrings for swing are annotated as
`%feature("autodoc")` - but `"autodoc"` annotations are only to substitute a
string showing the arguments and return variables - either in a single line, or
in multiple lines. SBMemoryRegionInfo used `"autodoc"` correctly describing the
parameters and return type, but then it added a description too which is not
correct either.
Change all of these that are adding a method description to use
`%feature("docstring")` instead. There were a half dozen instances where
`"autodoc"` was correctly being used and we have overriden the parameter and
return types with a more readable version.
>From 97f8f87fc4b14a973eb0bb0ac67ff36f1f4ef08a Mon Sep 17 00:00:00 2001
From: Jason Molenda
Date: Mon, 8 Apr 2024 17:17:16 -0700
Subject: [PATCH] [lldb] [NFC] Fix swig docstring annotations
Some of the SB API method description docstrings for swing are
annotated as `%feature("autodoc")` - but `"autodoc"` annotations
are only to substitute a string showing the arguments and return
variables - either in a single line, or in multiple lines.
SBMemoryRegionInfo used `"autodoc"` correctly describing the
parameters and return type, but then it added a description too
which is not correct either.
Change all of these that are adding a method description to use
`%feature("docstring")` instead. There were a half dozen instances
where `"autodoc"` was correctly being used and we have overriden
the parameter and return types with a more readable version.
---
.../interface/SBMemoryRegionInfoDocstrings.i | 12 ++---
lldb/bindings/interface/SBProcessDocstrings.i | 50 +--
lldb/bindings/interface/SBQueueDocstrings.i | 4 +-
lldb/bindings/interface/SBThreadDocstrings.i | 36 +++--
4 files changed, 48 insertions(+), 54 deletions(-)
diff --git a/lldb/bindings/interface/SBMemoryRegionInfoDocstrings.i
b/lldb/bindings/interface/SBMemoryRegionInfoDocstrings.i
index bd80740f3fdd3b..d7c68baf100e27 100644
--- a/lldb/bindings/interface/SBMemoryRegionInfoDocstrings.i
+++ b/lldb/bindings/interface/SBMemoryRegionInfoDocstrings.i
@@ -2,8 +2,7 @@
"API clients can get information about memory regions in processes."
) lldb::SBMemoryRegionInfo;
-%feature("autodoc", "
-GetRegionEnd(SBMemoryRegionInfo self) -> lldb::addr_t
+%feature("docstring", "
Returns whether this memory region has a list of modified (dirty)
pages available or not. When calling GetNumDirtyPages(), you will
have 0 returned for both \"dirty page list is not known\" and
@@ -11,8 +10,7 @@
memory region). You must use this method to disambiguate."
) lldb::SBMemoryRegionInfo::HasDirtyMemoryPageList;
-%feature("autodoc", "
-GetNumDirtyPages(SBMemoryRegionInfo self) -> uint32_t
+%feature("docstring", "
Return the number of dirty (modified) memory pages in this
memory region, if available. You must use the
SBMemoryRegionInfo::HasDirtyMemoryPageList() method to
@@ -20,16 +18,14 @@
on the target system can provide this information."
) lldb::SBMemoryRegionInfo::GetNumDirtyPages;
-%feature("autodoc", "
-GetDirtyPageAddressAtIndex(SBMemoryRegionInfo self, uint32_t idx) ->
lldb::addr_t
+%feature("docstring", "
Return the address of a modified, or dirty, page of memory.
If the provided index is out of range, or this memory region
does not have dirty page information, LLDB_INVALID_ADDRESS
is returned."
) lldb::SBMemoryRegionInfo::GetDirtyPageAddressAtIndex;
-%feature("autodoc", "
-GetPageSize(SBMemoryRegionInfo self) -> int
+%feature("docstring", "
Return the size of pages in this memory region. 0 will be returned
if this information was unavailable."
) lldb::SBMemoryRegionInfo::GetPageSize();
diff --git a/lldb/bindings/interface/SBProcessDocstrings.i
b/lldb/bindings/interface/SBProcessDocstrings.i
index 3ee17e0c7f2fbb..c20ef3e4655bd4 100644
--- a/lldb/bindings/interface/SBProcessDocstrings.i
+++ b/lldb/bindings/interface/SBProcessDocstrings.i
@@ -20,18 +20,18 @@ SBProcess supports thread iteration. For example (from
test/lldbutil.py), ::
"
) lldb::SBProcess;
-%feature("autodoc", "
+%feature("docstring", "
Writes data into the current process's stdin. API client specifies a Python
string as the only argument."
) lldb::SBProcess::PutSTDIN;
-%feature("autodoc", "
+%feature("docstring", "
Reads data from the current process's stdout stream. API client specifies
the size of the buffer to read data into. It returns the byte buffer in a
Python string."
) lldb::SBProcess::GetSTDOUT;
-%feature("autodoc", "
+%feature("docstring", "
Reads data from the current process's stderr stream. API client specifies
the size of the buffer to read data into. It returns the byte buffer in a
Python s
[Lldb-commits] [lldb] [lldb][sbdebugger] Match progress category enum bit in Debugger.h (PR #87409)
https://github.com/chelcassanova updated
https://github.com/llvm/llvm-project/pull/87409
>From 7561d03d775822f789a61a5b827dfa04b29b57b2 Mon Sep 17 00:00:00 2001
From: Chelsea Cassanova
Date: Tue, 2 Apr 2024 13:22:15 -0700
Subject: [PATCH 1/2] [lldb][sbdebugger] Match progress category enum bit in
Debugger.h
When the `eBroadcastBitProgressCategory` bit was originally added to
Debugger.h and SBDebugger.h, each corresponding bit was added in order
of the other bits that were previously there. Since `Debugger.h` has an
enum bit that `SBDebugger.h` does not, this meant that their offsets did
not match. This commit changes it so that the bit offsets match each other.
---
lldb/include/lldb/API/SBDebugger.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/lldb/include/lldb/API/SBDebugger.h
b/lldb/include/lldb/API/SBDebugger.h
index 62b2f91f5076d5..a994874dde6d4a 100644
--- a/lldb/include/lldb/API/SBDebugger.h
+++ b/lldb/include/lldb/API/SBDebugger.h
@@ -42,11 +42,13 @@ class LLDB_API SBInputReader {
class LLDB_API SBDebugger {
public:
+ // The enum values here need to match their corresponding values in
+ // Debugger.h.
FLAGS_ANONYMOUS_ENUM(){
eBroadcastBitProgress = (1 << 0),
eBroadcastBitWarning = (1 << 1),
eBroadcastBitError = (1 << 2),
- eBroadcastBitProgressCategory = (1 << 3),
+ eBroadcastBitProgressCategory = (1 << 4),
};
SBDebugger();
>From a37c65dea5794e474e554f4b1762f0f630965afe Mon Sep 17 00:00:00 2001
From: Chelsea Cassanova
Date: Mon, 8 Apr 2024 16:39:41 -0700
Subject: [PATCH 2/2] Add SBDebugger broadcast bits to lldb-enumerations
Per Alex's suggestions, adds the broadcast bits from SBDebugger
into lldb-enumerations.
---
lldb/include/lldb/lldb-enumerations.h | 8
1 file changed, 8 insertions(+)
diff --git a/lldb/include/lldb/lldb-enumerations.h
b/lldb/include/lldb/lldb-enumerations.h
index 646f7bfda98475..17f4125c50cced 100644
--- a/lldb/include/lldb/lldb-enumerations.h
+++ b/lldb/include/lldb/lldb-enumerations.h
@@ -1339,6 +1339,14 @@ enum AddressMaskRange {
eAddressMaskRangeAll = eAddressMaskRangeAny,
};
+/// Used by the debugger to indicate which events are being broadcasted.
+enum DebuggerBroadcast {
+ eBroadcastBitProgress = (1 << 0),
+ eBroadcastBitWarning = (1 << 1),
+ eBroadcastBitError = (1 << 2),
+ eBroadcastBitProgressCategory = (1 << 4),
+};
+
} // namespace lldb
#endif // LLDB_LLDB_ENUMERATIONS_H
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][TypeSynthetic][NFC] Make SyntheticChildrenFrontend::Update() return an enum (PR #80167)
JDevlieghere wrote: @Michael137 I'm a little late to the party but I just noticed that `ChildCacheState` is the only `enum class` in `lldb-enumerations.h`. Is that intentional? Is there a reason this cannot be a old-school enum like everything else in that file? I don't feel super strongly about I'd like to make sure there's a reason for the inconsistency. https://github.com/llvm/llvm-project/pull/80167 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Fix error in unrecognized register name handling for "SBFrame.register" (PR #88047)
github-actions[bot] wrote: :warning: Python code formatter, darker found issues in your code. :warning: You can test this locally with the following command: ``bash darker --check --diff -r 5b959310b0fae723bd119ed8815bf1cb1a8c67d4...d1336d9f8877c45dfd9a427eaa900f5208153de1 lldb/test/API/python_api/frame/TestFrames.py `` View the diff from darker here. ``diff --- TestFrames.py 2024-04-08 21:20:17.00 + +++ TestFrames.py 2024-04-08 21:34:19.896474 + @@ -82,12 +82,14 @@ iterator_pc_value = int(reg.GetValue(), 0) break pc_value_int = int(pc_value.GetValue(), 0) self.assertTrue(found_pc, "Found the PC value in the register list") -self.assertEqual(iterator_pc_value, pc_value_int, "The methods of finding pc match") - +self.assertEqual( +iterator_pc_value, pc_value_int, "The methods of finding pc match" +) + # Make sure on arm targets we dont mismatch PC value on the basis of thumb bit. # Frame PC will not have thumb bit set in case of a thumb # instruction as PC. if self.getArchitecture() in ["arm", "armv7", "armv7k"]: pc_value_int &= ~1 `` https://github.com/llvm/llvm-project/pull/88047 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Fix error in unrecognized register name handling for "SBFrame.register" (PR #88047)
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: None (jimingham)
Changes
The code returned lldb.SBValue() when you passed in an unrecognized variable
name. But referring to "lldb" is apparently not legal within the module.
I changed this to just return SBValue(), but then this construct:
(lldb) script
>>> for reg_set in lldb.target.process.thread[0].frames[0].register
...print(reg)
Runs forever printing "No Value". The __getitem__(key) gets called with a
monotonically increasing by 1 series of integers. I don't know why Python
decided the class we defined should have a generator that returns positive
integers in order, but we can add a more useful one here by returning an
iterator over the flattened list of registers.
Note, the not very aptly named "SBFrame.registers" is an iterator over register
sets, not registers, so the two are not redundant.
---
Full diff: https://github.com/llvm/llvm-project/pull/88047.diff
2 Files Affected:
- (modified) lldb/bindings/interface/SBFrameExtensions.i (+11-1)
- (modified) lldb/test/API/python_api/frame/TestFrames.py (+12)
``diff
diff --git a/lldb/bindings/interface/SBFrameExtensions.i
b/lldb/bindings/interface/SBFrameExtensions.i
index 43b22ed7a6b325..e0472280666ab9 100644
--- a/lldb/bindings/interface/SBFrameExtensions.i
+++ b/lldb/bindings/interface/SBFrameExtensions.i
@@ -44,6 +44,16 @@ STRING_EXTENSION_OUTSIDE(SBFrame)
def __init__(self, regs):
self.regs = regs
+def __iter__(self):
+return self.get_registers()
+
+def get_registers(self):
+for i in range(0,len(self.regs)):
+rs = self.regs[i]
+for j in range (0,rs.num_children):
+reg = rs.GetChildAtIndex(j)
+yield reg
+
def __getitem__(self, key):
if type(key) is str:
for i in range(0,len(self.regs)):
@@ -52,7 +62,7 @@ STRING_EXTENSION_OUTSIDE(SBFrame)
reg = rs.GetChildAtIndex(j)
if reg.name == key: return reg
else:
-return lldb.SBValue()
+return SBValue()
return registers_access(self.registers)
diff --git a/lldb/test/API/python_api/frame/TestFrames.py
b/lldb/test/API/python_api/frame/TestFrames.py
index a82b129bc8099d..dfa96d51830bae 100644
--- a/lldb/test/API/python_api/frame/TestFrames.py
+++ b/lldb/test/API/python_api/frame/TestFrames.py
@@ -73,7 +73,19 @@ def test_get_arg_vals_for_call_stack(self):
gpr_reg_set = lldbutil.get_GPRs(frame)
pc_value = gpr_reg_set.GetChildMemberWithName("pc")
self.assertTrue(pc_value, "We should have a valid PC.")
+# Make sure we can also get this from the "register" property:
+iterator_pc_value = 0
+found_pc = False
+for reg in frame.register:
+if reg.name == "pc":
+found_pc = True
+iterator_pc_value = int(reg.GetValue(), 0)
+break
+
pc_value_int = int(pc_value.GetValue(), 0)
+self.assertTrue(found_pc, "Found the PC value in the register
list")
+self.assertEqual(iterator_pc_value, pc_value_int, "The methods
of finding pc match")
+
# Make sure on arm targets we dont mismatch PC value on the
basis of thumb bit.
# Frame PC will not have thumb bit set in case of a thumb
# instruction as PC.
``
https://github.com/llvm/llvm-project/pull/88047
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Fix error in unrecognized register name handling for "SBFrame.register" (PR #88047)
https://github.com/jimingham created
https://github.com/llvm/llvm-project/pull/88047
The code returned lldb.SBValue() when you passed in an unrecognized variable
name. But referring to "lldb" is apparently not legal within the module.
I changed this to just return SBValue(), but then this construct:
(lldb) script
>>> for reg_set in lldb.target.process.thread[0].frames[0].register
...print(reg)
Runs forever printing "No Value". The __getitem__(key) gets called with a
monotonically increasing by 1 series of integers. I don't know why Python
decided the class we defined should have a generator that returns positive
integers in order, but we can add a more useful one here by returning an
iterator over the flattened list of registers.
Note, the not very aptly named "SBFrame.registers" is an iterator over register
sets, not registers, so the two are not redundant.
>From d1336d9f8877c45dfd9a427eaa900f5208153de1 Mon Sep 17 00:00:00 2001
From: Jim Ingham
Date: Mon, 8 Apr 2024 13:44:00 -0700
Subject: [PATCH] Fix error in unrecognized register name handling for
"SBFrame.register".
The code returned lldb.SBValue() which is not legal in the module.
I changed this to just return SBValue(), but then this construct:
(lldb) script
>>> for reg_set in lldb.target.process.thread[0].frames[0].register
...print(reg)
Runs forever printing "No Value". The __getitem__(key) gets called
with an ever increasing by 1 series of integers. I don't know why
Python decided the class we defined should have a generator that returns
positive integers in order, but we can add a more useful one here by
returning an iterator over the flattened list of registers.
Note, the not very aptly named "SBFrame.registers" is an iterator over
register sets, not registers, so the two are not redundant.
---
lldb/bindings/interface/SBFrameExtensions.i | 12 +++-
lldb/test/API/python_api/frame/TestFrames.py | 12
2 files changed, 23 insertions(+), 1 deletion(-)
diff --git a/lldb/bindings/interface/SBFrameExtensions.i
b/lldb/bindings/interface/SBFrameExtensions.i
index 43b22ed7a6b325..e0472280666ab9 100644
--- a/lldb/bindings/interface/SBFrameExtensions.i
+++ b/lldb/bindings/interface/SBFrameExtensions.i
@@ -44,6 +44,16 @@ STRING_EXTENSION_OUTSIDE(SBFrame)
def __init__(self, regs):
self.regs = regs
+def __iter__(self):
+return self.get_registers()
+
+def get_registers(self):
+for i in range(0,len(self.regs)):
+rs = self.regs[i]
+for j in range (0,rs.num_children):
+reg = rs.GetChildAtIndex(j)
+yield reg
+
def __getitem__(self, key):
if type(key) is str:
for i in range(0,len(self.regs)):
@@ -52,7 +62,7 @@ STRING_EXTENSION_OUTSIDE(SBFrame)
reg = rs.GetChildAtIndex(j)
if reg.name == key: return reg
else:
-return lldb.SBValue()
+return SBValue()
return registers_access(self.registers)
diff --git a/lldb/test/API/python_api/frame/TestFrames.py
b/lldb/test/API/python_api/frame/TestFrames.py
index a82b129bc8099d..dfa96d51830bae 100644
--- a/lldb/test/API/python_api/frame/TestFrames.py
+++ b/lldb/test/API/python_api/frame/TestFrames.py
@@ -73,7 +73,19 @@ def test_get_arg_vals_for_call_stack(self):
gpr_reg_set = lldbutil.get_GPRs(frame)
pc_value = gpr_reg_set.GetChildMemberWithName("pc")
self.assertTrue(pc_value, "We should have a valid PC.")
+# Make sure we can also get this from the "register" property:
+iterator_pc_value = 0
+found_pc = False
+for reg in frame.register:
+if reg.name == "pc":
+found_pc = True
+iterator_pc_value = int(reg.GetValue(), 0)
+break
+
pc_value_int = int(pc_value.GetValue(), 0)
+self.assertTrue(found_pc, "Found the PC value in the register
list")
+self.assertEqual(iterator_pc_value, pc_value_int, "The methods
of finding pc match")
+
# Make sure on arm targets we dont mismatch PC value on the
basis of thumb bit.
# Frame PC will not have thumb bit set in case of a thumb
# instruction as PC.
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB] Add more helper functions to ValueObject class. (PR #87197)
cmtice wrote: I think I've addressed all the review comments for GetValueAsAPSInt, GetValueAsAPFloat, GetValueAsBool, UpdateIntegerValue (not SetValueFromInteger) and GetLoadAddress. I apologize if I missed anything. Please take another look at those functions. I'm still working on fixing the issues with the other functions. :-) https://github.com/llvm/llvm-project/pull/87197 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB] Add more helper functions to ValueObject class. (PR #87197)
https://github.com/cmtice updated
https://github.com/llvm/llvm-project/pull/87197
>From 68cb68d3f93aed6b3479fb305131b99ec599c9d8 Mon Sep 17 00:00:00 2001
From: Caroline Tice
Date: Sun, 31 Mar 2024 10:59:38 -0700
Subject: [PATCH 1/2] [LLDB] Add more helper functions to ValueObject class.
Create additional helper functions for the ValueObject class, for:
- returning the value as an APSInt or APFloat
- additional type casting options
- additional ways to create ValueObjects from various types of data
- dereferencing a ValueObject
These helper functions are needed for implementing the Data Inspection
Language, described in
https://discourse.llvm.org/t/rfc-data-inspection-language/69893
---
lldb/include/lldb/Core/ValueObject.h | 61
lldb/source/Core/ValueObject.cpp | 405 +++
2 files changed, 466 insertions(+)
diff --git a/lldb/include/lldb/Core/ValueObject.h
b/lldb/include/lldb/Core/ValueObject.h
index e7e35e2b2bffc0..0c8dbf384a326c 100644
--- a/lldb/include/lldb/Core/ValueObject.h
+++ b/lldb/include/lldb/Core/ValueObject.h
@@ -441,6 +441,19 @@ class ValueObject {
virtual int64_t GetValueAsSigned(int64_t fail_value, bool *success =
nullptr);
+ llvm::APSInt GetValueAsAPSInt();
+
+ llvm::APFloat GetValueAsFloat();
+
+ bool GetValueAsBool();
+
+ /// Update the value of the current object to be the integer in the 'value'
+ /// parameter.
+ void UpdateIntegerValue(const llvm::APInt &value);
+
+ /// Assign the integer value 'new_val_sp' to the current object.
+ void UpdateIntegerValue(lldb::ValueObjectSP new_val_sp);
+
virtual bool SetValueFromCString(const char *value_str, Status &error);
/// Return the module associated with this value object in case the value is
@@ -618,6 +631,24 @@ class ValueObject {
virtual lldb::ValueObjectSP CastPointerType(const char *name,
lldb::TypeSP &type_sp);
+ /// Return the target load address assocaited with this value object.
+ lldb::addr_t GetLoadAddress();
+
+ lldb::ValueObjectSP CastDerivedToBaseType(CompilerType type,
+const std::vector &idx);
+
+ lldb::ValueObjectSP CastBaseToDerivedType(CompilerType type, uint64_t
offset);
+
+ lldb::ValueObjectSP CastScalarToBasicType(CompilerType type, Status &error);
+
+ lldb::ValueObjectSP CastEnumToBasicType(CompilerType type);
+
+ lldb::ValueObjectSP CastPointerToBasicType(CompilerType type);
+
+ lldb::ValueObjectSP CastIntegerOrEnumToEnumType(CompilerType type);
+
+ lldb::ValueObjectSP CastFloatToEnumType(CompilerType type, Status &error);
+
/// If this object represents a C++ class with a vtable, return an object
/// that represents the virtual function table. If the object isn't a class
/// with a vtable, return a valid ValueObject with the error set correctly.
@@ -668,6 +699,32 @@ class ValueObject {
CreateValueObjectFromData(llvm::StringRef name, const DataExtractor &data,
const ExecutionContext &exe_ctx, CompilerType
type);
+ static lldb::ValueObjectSP
+ CreateValueObjectFromBytes(lldb::TargetSP target_sp, const void *bytes,
+ CompilerType type);
+
+ static lldb::ValueObjectSP CreateValueObjectFromBytes(lldb::TargetSP target,
+const void *bytes,
+lldb::BasicType type);
+
+ static lldb::ValueObjectSP CreateValueObjectFromAPInt(lldb::TargetSP target,
+const llvm::APInt &v,
+CompilerType type);
+
+ static lldb::ValueObjectSP
+ CreateValueObjectFromAPFloat(lldb::TargetSP target, const llvm::APFloat &v,
+ CompilerType type);
+
+ static lldb::ValueObjectSP CreateValueObjectFromPointer(lldb::TargetSP
target,
+ uintptr_t addr,
+ CompilerType type);
+
+ static lldb::ValueObjectSP CreateValueObjectFromBool(lldb::TargetSP target,
+ bool value);
+
+ static lldb::ValueObjectSP CreateValueObjectFromNullptr(lldb::TargetSP
target,
+ CompilerType type);
+
lldb::ValueObjectSP Persist();
/// Returns true if this is a char* or a char[] if it is a char* and
@@ -719,6 +776,10 @@ class ValueObject {
ClearUserVisibleData(eClearUserVisibleDataItemsSummary);
}
+ void SetDerefValobj(ValueObject *deref) { m_deref_valobj = deref; }
+
+ ValueObject *GetDerefValobj() { return m_deref_valobj; }
+
void SetValueFormat(lldb::TypeFormatImplSP format) {
m_type_format_sp = std::move(format);
ClearUserVisibleData(eClearUserVisibleDataItemsValue);
diff --git a/lldb/source/Core/ValueObject.cpp b/lldb/source/Cor
[Lldb-commits] [lldb] [lldb][lldb-dap] Cleanup breakpoint filters. (PR #87550)
@@ -36,9 +36,7 @@ DAP::DAP()
{{"cpp_catch", "C++ Catch", lldb::eLanguageTypeC_plus_plus},
{"cpp_throw", "C++ Throw", lldb::eLanguageTypeC_plus_plus},
{"objc_catch", "Objective-C Catch", lldb::eLanguageTypeObjC},
- {"objc_throw", "Objective-C Throw", lldb::eLanguageTypeObjC},
- {"swift_catch", "Swift Catch", lldb::eLanguageTypeSwift},
- {"swift_throw", "Swift Throw", lldb::eLanguageTypeSwift}}),
+ {"objc_throw", "Objective-C Throw", lldb::eLanguageTypeObjC}}),
jimingham wrote:
ObjC tends to only use exceptions for error reporting, not for message passing,
so a lot of ObjC developers leave this breakpoint on all the time. Having to
wait till the first load event that brings in ObjC would make that tedious.
https://github.com/llvm/llvm-project/pull/87550
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [RFC][LLDB] Telemetry in LLDB (PR #87815)
https://github.com/jh7370 commented: As I think I mentioned in the original RFC, I'm not convinced the core functionality for this belongs in LLDB. In my view, LLDB is a client that should make use of a common telemetry library that can be used by other parts of the wider LLVM toolchain, or indeed other non-LLVM tools. From a point of view of separation of concerns, it also doesn't make sense: LLDB is for debugging, whereas telemetry is a more generic thing that isn't specific to debugging. Certainly, there may be some specific aspects that are tied to LLDB in particular, but I'd expect those to be about the "what" is reported, not the "how" it is reported. As others have mentioned, I think it would be really helpful to have an overview of the design with the different key parts described (by class name ideally), preferably with the aid of a diagram, since a picture is often a clearer way of describing structure than words are. https://github.com/llvm/llvm-project/pull/87815 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [RFC][LLDB] Telemetry in LLDB (PR #87815)
@@ -0,0 +1,237 @@
+#ifndef LLDB_CORE_TELEMETRY_H
+#define LLDB_CORE_TELEMETRY_H
+
+#include
+#include
+#include
+#include
+#include
+
+#include "lldb/Interpreter/CommandReturnObject.h"
+#include "lldb/Utility/StructuredData.h"
+#include "lldb/lldb-forward.h"
+#include "llvm/ADT/StringExtras.h"
+#include "llvm/ADT/StringRef.h"
+
+namespace lldb_private {
+
+using SteadyTimePoint = std::chrono::time_point;
+
+struct TelemetryEventStats {
+ // REQUIRED: Start time of event
+ SteadyTimePoint m_start;
+ // OPTIONAL: End time of event - may be empty if not meaningful.
+ std::optional m_end;
+
+ // TBD: could add some memory stats here too?
+
+ TelemetryEventStats() = default;
+ TelemetryEventStats(SteadyTimePoint start) : m_start(start) {}
+ TelemetryEventStats(SteadyTimePoint start, SteadyTimePoint end)
+ : m_start(start), m_end(end) {}
+
+ std::optional Duration() const {
+if (m_end.has_value())
+ return *m_end - m_start;
+else
+ return std::nullopt;
+ }
+};
+
+struct LoggerConfig {
+ // If true, loggings will be enabled.
+ bool enable_logging;
+
+ // Additional destinations to send the logged entries.
+ // Could be stdout, stderr, or some local paths.
+ // Note: these are destinations are __in addition to__ whatever the default
+ // destination(s) are, as implemented by vendors.
+ std::vector additional_destinations;
+};
+
+// The base class contains the basic set of data.
+// Downstream implementations can add more fields as needed.
+struct BaseTelemetryEntry {
+ // A "session" corresponds to every time lldb starts.
+ // All entries emitted for the same session will have
+ // the same session_uuid
+ std::string session_uuid;
+
+ TelemetryEventStats stats;
jh7370 wrote:
+1: duration-style events are just one kind of event in our downstream
telemetry system. It doesn't make sense for most events to have a duration
though, so we have many other kinds of events (e.g. feature usage events).
https://github.com/llvm/llvm-project/pull/87815
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [RFC][LLDB] Telemetry in LLDB (PR #87815)
https://github.com/jh7370 edited https://github.com/llvm/llvm-project/pull/87815 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [RFC][LLDB] Telemetry in LLDB (PR #87815)
@@ -0,0 +1,237 @@
+#ifndef LLDB_CORE_TELEMETRY_H
+#define LLDB_CORE_TELEMETRY_H
+
+#include
+#include
+#include
+#include
+#include
+
+#include "lldb/Interpreter/CommandReturnObject.h"
+#include "lldb/Utility/StructuredData.h"
+#include "lldb/lldb-forward.h"
+#include "llvm/ADT/StringExtras.h"
+#include "llvm/ADT/StringRef.h"
+
+namespace lldb_private {
+
+using SteadyTimePoint = std::chrono::time_point;
jh7370 wrote:
Speaking from experience: `steady_clock` is only useful for measuring
durations, since it isn't relative to a user's (or indeed any) fixed point in
time - try converting it to a year/month/day etc format and you'll see what I
mean. If you want an actual point in time that can be understood by the
telemetry consumer, you'll need something to act as the base point of time that
the steady times are relative to. In our internal telemetry implementation, our
duration events therefore actually use both steady and system clock time
points, with the reported duration being the difference between two steady time
points, and the system clock time point being to indicate when the event was
triggered.
https://github.com/llvm/llvm-project/pull/87815
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
