[Lldb-commits] [lldb] [lldb][test] Workaround older systems that lack gettid (PR #104831)
https://github.com/hawkinsw closed https://github.com/llvm/llvm-project/pull/104831 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] WIP: [lldb][test] Workaround older systems that lack gettid (PR #104831)
hawkinsw wrote: @petrhosek Just requesting another review because of the change that I made after your feedback! I'm just being cautious. Sorry to bother you! https://github.com/llvm/llvm-project/pull/104831 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] WIP: [lldb][test] Workaround older systems that lack gettid (PR #104831)
https://github.com/hawkinsw updated
https://github.com/llvm/llvm-project/pull/104831
>From 93949029c808e2e5991df2f3c498dcd008367c34 Mon Sep 17 00:00:00 2001
From: Will Hawkins
Date: Mon, 19 Aug 2024 14:43:45 -0400
Subject: [PATCH] [lldb][test] Workaround older systems that lack gettid
Older glibc versions do not have `gettid`. Provide our own `gettid` in these
cases.
Fixes a build failure caused by #104109.
---
lldb/unittests/Process/elf-core/CMakeLists.txt| 11 +++
lldb/unittests/Process/elf-core/ThreadElfCoreTest.cpp | 5 +
2 files changed, 16 insertions(+)
diff --git a/lldb/unittests/Process/elf-core/CMakeLists.txt
b/lldb/unittests/Process/elf-core/CMakeLists.txt
index b852a3ffb863c1..68ab6e0683c182 100644
--- a/lldb/unittests/Process/elf-core/CMakeLists.txt
+++ b/lldb/unittests/Process/elf-core/CMakeLists.txt
@@ -1,3 +1,6 @@
+include(CheckSymbolExists)
+include(CMakePushCheckState)
+
add_lldb_unittest(ProcessElfCoreTests
ThreadElfCoreTest.cpp
@@ -13,3 +16,11 @@ add_lldb_unittest(ProcessElfCoreTests
LINK_COMPONENTS
Support
)
+
+cmake_push_check_state()
+set(CMAKE_REQUIRED_DEFINITIONS -D_GNU_SOURCE)
+check_symbol_exists(gettid "unistd.h" HAVE_GETTID)
+if(HAVE_GETTID)
+ target_compile_definitions(ProcessElfCoreTests PRIVATE HAVE_GETTID)
+endif()
+cmake_pop_check_state()
diff --git a/lldb/unittests/Process/elf-core/ThreadElfCoreTest.cpp
b/lldb/unittests/Process/elf-core/ThreadElfCoreTest.cpp
index ce146f62b0d826..c9879f5d94d538 100644
--- a/lldb/unittests/Process/elf-core/ThreadElfCoreTest.cpp
+++ b/lldb/unittests/Process/elf-core/ThreadElfCoreTest.cpp
@@ -23,6 +23,11 @@
#include
#include
+#ifndef HAVE_GETTID
+#include
+pid_t gettid() { return ((pid_t)syscall(SYS_gettid)); }
+#endif
+
using namespace lldb_private;
namespace {
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] WIP: [lldb][test] Workaround older systems that lack gettid (PR #104831)
hawkinsw wrote: @petrhosek Hope that looks better! https://github.com/llvm/llvm-project/pull/104831 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] WIP: [lldb][test] Workaround older systems that lack gettid (PR #104831)
https://github.com/hawkinsw updated
https://github.com/llvm/llvm-project/pull/104831
>From 264d96482efa889ec0f7329519755033b3ea172c Mon Sep 17 00:00:00 2001
From: Will Hawkins
Date: Mon, 19 Aug 2024 14:43:45 -0400
Subject: [PATCH] [lldb][test] Workaround older systems that lack gettid
Older glibc versions do not have `gettid`. Provide our own `gettid` in these
cases.
Fixes a build failure caused by #104109.
---
lldb/unittests/Process/elf-core/CMakeLists.txt| 11 +++
lldb/unittests/Process/elf-core/ThreadElfCoreTest.cpp | 5 +
2 files changed, 16 insertions(+)
diff --git a/lldb/unittests/Process/elf-core/CMakeLists.txt
b/lldb/unittests/Process/elf-core/CMakeLists.txt
index b852a3ffb863c1..a5c0f0f9f79b22 100644
--- a/lldb/unittests/Process/elf-core/CMakeLists.txt
+++ b/lldb/unittests/Process/elf-core/CMakeLists.txt
@@ -1,3 +1,14 @@
+include(CheckSymbolExists)
+include(CMakePushCheckState)
+
+cmake_push_check_state()
+set(CMAKE_REQUIRED_DEFINITIONS -D_GNU_SOURCE)
+check_symbol_exists(gettid "unistd.h" HAVE_GETTID)
+if(HAVE_GETTID)
+ add_compile_definitions(-DHAVE_GETTID)
+endif()
+cmake_pop_check_state()
+
add_lldb_unittest(ProcessElfCoreTests
ThreadElfCoreTest.cpp
diff --git a/lldb/unittests/Process/elf-core/ThreadElfCoreTest.cpp
b/lldb/unittests/Process/elf-core/ThreadElfCoreTest.cpp
index ce146f62b0d826..c9879f5d94d538 100644
--- a/lldb/unittests/Process/elf-core/ThreadElfCoreTest.cpp
+++ b/lldb/unittests/Process/elf-core/ThreadElfCoreTest.cpp
@@ -23,6 +23,11 @@
#include
#include
+#ifndef HAVE_GETTID
+#include
+pid_t gettid() { return ((pid_t)syscall(SYS_gettid)); }
+#endif
+
using namespace lldb_private;
namespace {
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add Populate Methods for ELFLinuxPrPsInfo and ELFLinuxPrStatus (PR #104109)
hawkinsw wrote: > > > Our bots and sysroot are based on the oldest supported versions of > > > Debian, based on the project's stated minimum requirements. > > > > > > @ilovepi Could you say which of the versions that you are using? That would > > help, I think. > > It's Ubuntu 14.04 which uses glibc 2.19. That's the problem! `gettid` wasn't added to glibc until 2.30. Let me know if the referenced PR helps! https://github.com/llvm/llvm-project/pull/104109 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] WIP: [lldb][test] Workaround older systems that lack gettid (PR #104831)
https://github.com/hawkinsw updated
https://github.com/llvm/llvm-project/pull/104831
>From 76f01132b7667be48967b8d9788f610cf1a539d4 Mon Sep 17 00:00:00 2001
From: Will Hawkins
Date: Mon, 19 Aug 2024 14:43:45 -0400
Subject: [PATCH] WIP: [lldb][test] Workaround older systems that lack gettid
Older glibc versions do not have `gettid`. Provide our own `gettid` in these
cases.
Fixes a build failure caused by #104109.
---
lldb/unittests/Process/elf-core/ThreadElfCoreTest.cpp | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/lldb/unittests/Process/elf-core/ThreadElfCoreTest.cpp
b/lldb/unittests/Process/elf-core/ThreadElfCoreTest.cpp
index ce146f62b0d826..fc952ff42a91fb 100644
--- a/lldb/unittests/Process/elf-core/ThreadElfCoreTest.cpp
+++ b/lldb/unittests/Process/elf-core/ThreadElfCoreTest.cpp
@@ -23,6 +23,10 @@
#include
#include
+#include
+
+pid_t _workaround_gettid() { return ((pid_t)syscall(SYS_gettid)); }
+
using namespace lldb_private;
namespace {
@@ -91,7 +95,7 @@ lldb::TargetSP CreateTarget(lldb::DebuggerSP &debugger_sp,
ArchSpec &arch) {
lldb::ThreadSP CreateThread(lldb::ProcessSP &process_sp) {
lldb::ThreadSP thread_sp =
- std::make_shared(*process_sp.get(), gettid());
+ std::make_shared(*process_sp.get(), _workaround_gettid());
if (thread_sp == nullptr) {
return nullptr;
}
@@ -167,8 +171,8 @@ TEST_F(ElfCoreTest, PopulatePrStatusTest) {
ASSERT_EQ(prstatus_opt->pr_cursig, 0);
ASSERT_EQ(prstatus_opt->pr_sigpend, 0UL);
ASSERT_EQ(prstatus_opt->pr_sighold, 0UL);
- ASSERT_EQ(prstatus_opt->pr_pid, static_cast(gettid()));
+ ASSERT_EQ(prstatus_opt->pr_pid, static_cast(_workaround_gettid()));
ASSERT_EQ(prstatus_opt->pr_ppid, static_cast(getppid()));
ASSERT_EQ(prstatus_opt->pr_pgrp, static_cast(getpgrp()));
- ASSERT_EQ(prstatus_opt->pr_sid, static_cast(getsid(gettid(;
+ ASSERT_EQ(prstatus_opt->pr_sid,
static_cast(getsid(_workaround_gettid(;
}
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] WIP: [lldb][test] Workaround older systems that lack gettid (PR #104831)
hawkinsw wrote: FYI: I understand that the code in this PR is _not_ going to be the final answer. I am just hoping to confirm that it does, actually, fix the problem. If it does, then I will work on a "better" solution. Will https://github.com/llvm/llvm-project/pull/104831 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add Populate Methods for ELFLinuxPrPsInfo and ELFLinuxPrStatus (PR #104109)
hawkinsw wrote: @ilovepi If you can, try https://github.com/llvm/llvm-project/pull/104831. I think that the problem is your builder is running with a version of glibc that does not provide `gettid`. If the hack implemented in that PR fixes the problem, I will work on a nicer fix. https://github.com/llvm/llvm-project/pull/104109 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] WIP: [lldb][test] Workaround older systems that lack gettid (PR #104831)
https://github.com/hawkinsw edited https://github.com/llvm/llvm-project/pull/104831 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] WIP: [lldb][test] Workaround older systems that lack gettid (PR #104831)
https://github.com/hawkinsw created
https://github.com/llvm/llvm-project/pull/104831
Only Linux systems do not have gettid. Provide our own gettid in these cases.
Fixes a build failure caused by #104109.
>From 10bc5a512b56238328b025303345e47708927d6e Mon Sep 17 00:00:00 2001
From: Will Hawkins
Date: Mon, 19 Aug 2024 14:43:45 -0400
Subject: [PATCH] WIP: [lldb][test] Workaround older systems that lack gettid
Only Linux systems do not have gettid. Provide our own gettid in these
cases.
Fixes a build failure caused by #104109.
---
.../unittests/Process/elf-core/ThreadElfCoreTest.cpp | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/lldb/unittests/Process/elf-core/ThreadElfCoreTest.cpp
b/lldb/unittests/Process/elf-core/ThreadElfCoreTest.cpp
index ce146f62b0d826..5cf5f9718252d5 100644
--- a/lldb/unittests/Process/elf-core/ThreadElfCoreTest.cpp
+++ b/lldb/unittests/Process/elf-core/ThreadElfCoreTest.cpp
@@ -23,6 +23,12 @@
#include
#include
+#include
+
+pid_t _workaround_gettid() {
+ return ((pid_t)syscall(SYS_gettid));
+}
+
using namespace lldb_private;
namespace {
@@ -91,7 +97,7 @@ lldb::TargetSP CreateTarget(lldb::DebuggerSP &debugger_sp,
ArchSpec &arch) {
lldb::ThreadSP CreateThread(lldb::ProcessSP &process_sp) {
lldb::ThreadSP thread_sp =
- std::make_shared(*process_sp.get(), gettid());
+ std::make_shared(*process_sp.get(), _workaround_gettid());
if (thread_sp == nullptr) {
return nullptr;
}
@@ -167,8 +173,8 @@ TEST_F(ElfCoreTest, PopulatePrStatusTest) {
ASSERT_EQ(prstatus_opt->pr_cursig, 0);
ASSERT_EQ(prstatus_opt->pr_sigpend, 0UL);
ASSERT_EQ(prstatus_opt->pr_sighold, 0UL);
- ASSERT_EQ(prstatus_opt->pr_pid, static_cast(gettid()));
+ ASSERT_EQ(prstatus_opt->pr_pid, static_cast(_workaround_gettid()));
ASSERT_EQ(prstatus_opt->pr_ppid, static_cast(getppid()));
ASSERT_EQ(prstatus_opt->pr_pgrp, static_cast(getpgrp()));
- ASSERT_EQ(prstatus_opt->pr_sid, static_cast(getsid(gettid(;
+ ASSERT_EQ(prstatus_opt->pr_sid,
static_cast(getsid(_workaround_gettid(;
}
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add Populate Methods for ELFLinuxPrPsInfo and ELFLinuxPrStatus (PR #104109)
hawkinsw wrote: > Our bots and sysroot are based on the oldest supported versions of Debian, > based on the project's stated minimum requirements. @ilovepi Could you say which of the versions that you are using? That would help, I think. https://github.com/llvm/llvm-project/pull/104109 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add Populate Methods for ELFLinuxPrPsInfo and ELFLinuxPrStatus (PR #104109)
hawkinsw wrote: Thanks, @ilovepi ! Again, I'm just trying to help, so I appreciate the backstory. I will keep looking! https://github.com/llvm/llvm-project/pull/104109 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add Populate Methods for ELFLinuxPrPsInfo and ELFLinuxPrStatus (PR #104109)
hawkinsw wrote: Interestingly enough, I just checked at `gettid` _is_ defined in `unistd.h` in Bionic. See [here](https://android.googlesource.com/platform/bionic/+/master/libc/include/unistd.h). Although I am not the original author here, I will definitely take a look at seeing what is wrong! Hope some of this discussion is helpful. https://github.com/llvm/llvm-project/pull/104109 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add Populate Methods for ELFLinuxPrPsInfo and ELFLinuxPrStatus (PR #104109)
hawkinsw wrote: I am _not_ an expert but did a little investigation and wanted to help if I could: It looks like the problem is that `gettid` is defined (at least on Linux systems) only when the `__USE_GNU` macro is defined. From the `man` page: ``` SYNOPSIS #define _GNU_SOURCE #include pid_t gettid(void); ``` It seems like we could fix the break in one of two ways: 1. Move the ```Cmake if (CMAKE_SYSTEM_NAME MATCHES "Linux|Android") add_subdirectory(elf-core) ``` into an if that checks exclusively for `Linux`; or 2. Use a `#ifdef _USE_GNU` in the actual test. Both seem overly aggressive because they would defeat the purpose of the test. I did find that there seems to be a platform-independent means of getting the thread id in `packages/Python/lldbsuite/test/make/thread.h` -- we could repurpose that implementation to use in this test rather than calling `gettid` directly. If that is something worth exploring, just let me know! I would be more than glad to help! https://github.com/llvm/llvm-project/pull/104109 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add options to "statistics dump" to control what sections are dumped (PR #95075)
@@ -131,11 +131,48 @@ struct ConstStringStats {
};
struct StatisticsOptions {
- bool summary_only = false;
- bool load_all_debug_info = false;
- bool include_targets = true;
- bool include_modules = true;
- bool include_transcript = true;
+public:
+ void SetSummaryOnly(bool value) { m_summary_only = value; }
+ bool GetSummaryOnly() const { return m_summary_only.value_or(false); }
+
+ void SetLoadAllDebugInfo(bool value) { m_load_all_debug_info = value; }
+ bool GetLoadAllDebugInfo() const {
+return m_load_all_debug_info.value_or(false);
+ }
+
+ void SetIncludeTargets(bool value) { m_include_targets = value; }
+ bool GetIncludeTargets() const {
+if (m_include_targets.has_value())
+ return m_include_targets.value();
+// `m_include_targets` has no value set, so return a value base on
hawkinsw wrote:
```suggestion
// `m_include_targets` has no value set, so return a value based on
```
https://github.com/llvm/llvm-project/pull/95075
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add options to "statistics dump" to control what sections are dumped (PR #95075)
https://github.com/hawkinsw edited https://github.com/llvm/llvm-project/pull/95075 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add options to "statistics dump" to control what sections are dumped (PR #95075)
https://github.com/hawkinsw commented: Thank you for doing this work! I hope that these little bits help! https://github.com/llvm/llvm-project/pull/95075 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add options to "statistics dump" to control what sections are dumped (PR #95075)
@@ -131,11 +131,48 @@ struct ConstStringStats {
};
struct StatisticsOptions {
- bool summary_only = false;
- bool load_all_debug_info = false;
- bool include_targets = true;
- bool include_modules = true;
- bool include_transcript = true;
+public:
+ void SetSummaryOnly(bool value) { m_summary_only = value; }
+ bool GetSummaryOnly() const { return m_summary_only.value_or(false); }
+
+ void SetLoadAllDebugInfo(bool value) { m_load_all_debug_info = value; }
+ bool GetLoadAllDebugInfo() const {
+return m_load_all_debug_info.value_or(false);
+ }
+
+ void SetIncludeTargets(bool value) { m_include_targets = value; }
+ bool GetIncludeTargets() const {
+if (m_include_targets.has_value())
+ return m_include_targets.value();
+// `m_include_targets` has no value set, so return a value base on
+// `m_summary_only`
+return !GetSummaryOnly();
+ }
+
+ void SetIncludeModules(bool value) { m_include_modules = value; }
+ bool GetIncludeModules() const {
+if (m_include_modules.has_value())
+ return m_include_modules.value();
+// `m_include_modules` has no value set, so return a value base on
+// `m_summary_only`
+return !GetSummaryOnly();
+ }
+
+ void SetIncludeTranscript(bool value) { m_include_transcript = value; }
+ bool GetIncludeTranscript() const {
+if (m_include_transcript.has_value())
+ return m_include_transcript.value();
+// `m_include_transcript` has no value set, so return a value base on
hawkinsw wrote:
```suggestion
// `m_include_transcript` has no value set, so return a value based on
```
https://github.com/llvm/llvm-project/pull/95075
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add options to "statistics dump" to control what sections are dumped (PR #95075)
@@ -131,11 +131,48 @@ struct ConstStringStats {
};
struct StatisticsOptions {
- bool summary_only = false;
- bool load_all_debug_info = false;
- bool include_targets = true;
- bool include_modules = true;
- bool include_transcript = true;
+public:
+ void SetSummaryOnly(bool value) { m_summary_only = value; }
+ bool GetSummaryOnly() const { return m_summary_only.value_or(false); }
+
+ void SetLoadAllDebugInfo(bool value) { m_load_all_debug_info = value; }
+ bool GetLoadAllDebugInfo() const {
+return m_load_all_debug_info.value_or(false);
+ }
+
+ void SetIncludeTargets(bool value) { m_include_targets = value; }
+ bool GetIncludeTargets() const {
+if (m_include_targets.has_value())
+ return m_include_targets.value();
+// `m_include_targets` has no value set, so return a value base on
+// `m_summary_only`
+return !GetSummaryOnly();
+ }
+
+ void SetIncludeModules(bool value) { m_include_modules = value; }
+ bool GetIncludeModules() const {
+if (m_include_modules.has_value())
+ return m_include_modules.value();
+// `m_include_modules` has no value set, so return a value base on
hawkinsw wrote:
```suggestion
// `m_include_modules` has no value set, so return a value based on
```
https://github.com/llvm/llvm-project/pull/95075
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Adds additional fields to ProcessInfo (PR #91544)
hawkinsw wrote: > > Sorry for the nits! I am not smart enough to contribute on the technical > > merits, so I am trying to find some way to help! > > Ehhh grammar is not where I shine. I rolled them up Not at all! I thought the comments were really excellent and helpful! I just wanted to help if I could! https://github.com/llvm/llvm-project/pull/91544 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Adds additional fields to ProcessInfo (PR #91544)
@@ -70,6 +71,12 @@ struct StatFields {
long unsigned stime;
long cutime;
long cstime;
+ // in proc_pid_stat(5) this field is specified as priority
+ // but documented as realtime priority. To keep with the adopted
+ // nomenclature in ProcessInstanceInfo we adopt the documented
+ // naming here
hawkinsw wrote:
```suggestion
// naming here.
```
https://github.com/llvm/llvm-project/pull/91544
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Adds additional fields to ProcessInfo (PR #91544)
@@ -70,6 +71,12 @@ struct StatFields {
long unsigned stime;
long cutime;
long cstime;
+ // in proc_pid_stat(5) this field is specified as priority
hawkinsw wrote:
```suggestion
// In proc_pid_stat(5) this field is specified as priority
```
https://github.com/llvm/llvm-project/pull/91544
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Adds additional fields to ProcessInfo (PR #91544)
@@ -115,13 +124,19 @@ static bool GetStatusInfo(::pid_t Pid, ProcessInstanceInfo &ProcessInfo, return ts; }; + // priority (nice) values run from 19 to -20 inclusive (in linux). In the + // prpsinfo struct pr_nice is a char hawkinsw wrote: ```suggestion // prpsinfo struct pr_nice is a char. ``` https://github.com/llvm/llvm-project/pull/91544 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Adds additional fields to ProcessInfo (PR #91544)
@@ -70,6 +71,12 @@ struct StatFields {
long unsigned stime;
long cutime;
long cstime;
+ // in proc_pid_stat(5) this field is specified as priority
+ // but documented as realtime priority. To keep with the adopted
+ // nomenclature in ProcessInstanceInfo we adopt the documented
hawkinsw wrote:
```suggestion
// nomenclature in ProcessInstanceInfo, we adopt the documented
```
https://github.com/llvm/llvm-project/pull/91544
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Adds additional fields to ProcessInfo (PR #91544)
@@ -115,13 +124,19 @@ static bool GetStatusInfo(::pid_t Pid, ProcessInstanceInfo &ProcessInfo, return ts; }; + // priority (nice) values run from 19 to -20 inclusive (in linux). In the hawkinsw wrote: ```suggestion // Priority (nice) values run from 19 to -20 inclusive (in Linux). In the ``` https://github.com/llvm/llvm-project/pull/91544 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Adds additional fields to ProcessInfo (PR #91544)
@@ -86,4 +89,22 @@ TEST_F(HostTest, GetProcessInfo) {
ProcessInstanceInfo::timespec next_user_time = Info.GetUserTime();
ASSERT_TRUE(user_time.tv_sec <= next_user_time.tv_sec ||
user_time.tv_usec <= next_user_time.tv_usec);
+
+ struct rlimit rlim;
+ EXPECT_EQ(getrlimit(RLIMIT_NICE, &rlim), 0);
+ // getpriority can return -1 so we zero errno first
+ errno = 0;
+ int prio = getpriority(PRIO_PROCESS, PRIO_PROCESS);
+ ASSERT_TRUE((prio < 0 && errno == 0) || prio >= 0);
+ ASSERT_EQ(Info.GetPriorityValue(), prio);
+ // If we can't raise our nice level then this test can't be performed
hawkinsw wrote:
```suggestion
// If we can't raise our nice level then this test can't be performed.
```
https://github.com/llvm/llvm-project/pull/91544
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Adds additional fields to ProcessInfo (PR #91544)
https://github.com/hawkinsw commented: Sorry for the nits! I am not smart enough to contribute on the technical merits, so I am trying to find some way to help! https://github.com/llvm/llvm-project/pull/91544 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Adds additional fields to ProcessInfo (PR #91544)
https://github.com/hawkinsw edited https://github.com/llvm/llvm-project/pull/91544 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][Docs] Convert platform packets doc to Markdown (PR #89913)
@@ -0,0 +1,482 @@ +# LLDB Platform Packets +Here is a brief overview of the packets that an lldb platform server +needs to implement for the lldb testsuite to be run on a remote +target device/system. + +These are almost all lldb extensions to the gdb-remote serial +protocol. Many of the `vFile:` packets are also described in the "Host +I/O Packets" detailed in the gdb-remote protocol documentation, +although the lldb platform extensions include packets that are not +defined there (`vFile:size:`, `vFile:mode:`, `vFile:symlink`, `vFile:chmod:`). + +Most importantly, the flags that lldb passes to `vFile:open:` are +incompatible with the flags that gdb specifies. + +## QStartNoAckMode + +### Brief + +A request to stop sending ACK packets for each properly formatted packet. + +### Example + +A platform session will typically start like this: +``` +receive: +$QStartNoAckMode#b0 +send:+ <-- ACKing the properly formatted QStartNoAckMode packet +send:$OK#9a +receive: + <-- Our OK packet getting ACKed +``` + +ACK mode is now disabled. + +## qHostInfo + +### Brief + +Describe the hardware and OS of the target system + +### Example + +``` +receive: qHostInfo +send: cputype:16777228;cpusubtype:1;ostype:ios;watchpoint_exceptions_received:before;os_version:12.1;vendor:apple;default_packet_timeout:5; +``` + +All numbers are base 10, `os_version` is a string that will be parsed as major.minor.patch. + +## qModuleInfo + +### Brief + +Get information for a module by given module path and architecture. + +The response is: +* `(uuid|md5):...;triple:...;file_offset:...;file_size...;` or +* `EXX` - for any errors + +### Example + +``` +receive: qModuleInfo:2f62696e2f6c73; +``` + +## qGetWorkingDir + +### Brief + +Get the current working directory of the platform stub in +ASCII hex encoding. + +### Example + +``` +receive: qGetWorkingDir +send: 2f4170706c65496e7465726e616c2f6c6c64622f73657474696e67732f342f5465737453657474696e67732e746573745f646973617373656d626c65725f73657474696e6773 +``` + +## QSetWorkingDir + +### Brief + +Set the current working directory of the platform stub in +ASCII hex encoding. + +### Example + +``` +receive: QSetWorkingDir:2f4170706c65496e7465726e616c2f6c6c64622f73657474696e67732f342f5465737453657474696e67732e746573745f646973617373656d626c65725f73657474696e6773 +send:OK +``` + +## qPlatform_mkdir + +### Brief + +Create a directory on the target system. + +### Example + +``` +receive: qPlatform_mkdir:01fd,2f746d702f6131 +send:F0 +``` + +request packet has the fields: + 1. mode bits in base 16 + 2. file path in ascii-hex encoding + +response is F followed by the return value of the `mkdir()` call, +base 16 encoded. + +## qPlatform_shell + +### Brief + +Run a shell command on the target system, return the output. + +### Example + +``` +receive: qPlatform_shell:6c73202f746d702f,000a +send:F,0,0, +``` + +request packet has the fields: + 1. shell command ascii-hex encoded + 2. timeout + 3. working directory ascii-hex encoded (optional) + +Response is `F` followed by the return value of the command (base 16), +followed by another number, followed by the output of the command +in binary-escaped-data encoding. + +## qLaunchGDBServer + +### Brief + +Start a gdbserver process (`gdbserver`, `debugserver`, `lldb-server`) +on the target system. + +### Example + +``` +receive: qLaunchGDBServer;host:; +send:pid:1337;port:43001; +``` + +Request packet hostname field is not ascii-hex encoded. Hostnames +don't have `$` or `#` characters in them. + +Response to the packet is the pid of the newly launched gdbserver, +and the port it is listening for a connection on. + +When the testsuite is running, lldb may use the pid to kill off a +debugserver that doesn't seem to be responding, etc. + +## qKillSpawnedProcess + +### Brief + +Kill a process running on the target system. + +### Example + +``` +receive: qKillSpawnedProcess:1337 +send:OK +``` +The request packet has the process ID in base 10. + +## qProcessInfoPID: + +### Brief + +Gather information about a process running on the target + +### Example + +``` +receive: qProcessInfoPID:71964 +send:pid:71964;name:612e6f7574; +``` + +The request packet has the pid encoded in base 10. + +The reply has semicolon-separated `name:value` fields, two are +shown here. `pid` is base 10 encoded. `name` is ascii hex encoded. +lldb-server can reply with many additional fields, but this is probably +enough for the testsuite. + +## qfProcessInfo + +### Brief + +Search the process table for processes matching criteria, +respond with them in multiple packets. + +### Example + +``` +receive: qfProcessInfo:name_match:equals;name:6e6f70726f6365737365786973747377697468746869736e616d65; +send:pid:3500;name:612e6f7574; +``` + +The request packet has a criteria to search for, followed by +a specific name. + +| Key | Value | Description +| | - | --- +| `name` |
[Lldb-commits] [lldb] [lldb][Docs] Convert platform packets doc to Markdown (PR #89913)
@@ -0,0 +1,482 @@ +# LLDB Platform Packets +Here is a brief overview of the packets that an lldb platform server +needs to implement for the lldb testsuite to be run on a remote +target device/system. + +These are almost all lldb extensions to the gdb-remote serial +protocol. Many of the `vFile:` packets are also described in the "Host +I/O Packets" detailed in the gdb-remote protocol documentation, +although the lldb platform extensions include packets that are not +defined there (`vFile:size:`, `vFile:mode:`, `vFile:symlink`, `vFile:chmod:`). + +Most importantly, the flags that lldb passes to `vFile:open:` are +incompatible with the flags that gdb specifies. + +## QStartNoAckMode + +### Brief + +A request to stop sending ACK packets for each properly formatted packet. + +### Example + +A platform session will typically start like this: +``` +receive: +$QStartNoAckMode#b0 +send:+ <-- ACKing the properly formatted QStartNoAckMode packet +send:$OK#9a +receive: + <-- Our OK packet getting ACKed +``` + +ACK mode is now disabled. + +## qHostInfo + +### Brief + +Describe the hardware and OS of the target system + +### Example + +``` +receive: qHostInfo +send: cputype:16777228;cpusubtype:1;ostype:ios;watchpoint_exceptions_received:before;os_version:12.1;vendor:apple;default_packet_timeout:5; +``` + +All numbers are base 10, `os_version` is a string that will be parsed as major.minor.patch. + +## qModuleInfo + +### Brief + +Get information for a module by given module path and architecture. + +The response is: +* `(uuid|md5):...;triple:...;file_offset:...;file_size...;` or +* `EXX` - for any errors + +### Example + +``` +receive: qModuleInfo:2f62696e2f6c73; +``` + +## qGetWorkingDir + +### Brief + +Get the current working directory of the platform stub in +ASCII hex encoding. + +### Example + +``` +receive: qGetWorkingDir +send: 2f4170706c65496e7465726e616c2f6c6c64622f73657474696e67732f342f5465737453657474696e67732e746573745f646973617373656d626c65725f73657474696e6773 +``` + +## QSetWorkingDir + +### Brief + +Set the current working directory of the platform stub in +ASCII hex encoding. + +### Example + +``` +receive: QSetWorkingDir:2f4170706c65496e7465726e616c2f6c6c64622f73657474696e67732f342f5465737453657474696e67732e746573745f646973617373656d626c65725f73657474696e6773 +send:OK +``` + +## qPlatform_mkdir + +### Brief + +Create a directory on the target system. + +### Example + +``` +receive: qPlatform_mkdir:01fd,2f746d702f6131 +send:F0 +``` + +request packet has the fields: + 1. mode bits in base 16 + 2. file path in ascii-hex encoding + +response is F followed by the return value of the `mkdir()` call, +base 16 encoded. + +## qPlatform_shell + +### Brief + +Run a shell command on the target system, return the output. + +### Example + +``` +receive: qPlatform_shell:6c73202f746d702f,000a +send:F,0,0, +``` + +request packet has the fields: + 1. shell command ascii-hex encoded + 2. timeout + 3. working directory ascii-hex encoded (optional) + +Response is `F` followed by the return value of the command (base 16), +followed by another number, followed by the output of the command +in binary-escaped-data encoding. + +## qLaunchGDBServer + +### Brief + +Start a gdbserver process (`gdbserver`, `debugserver`, `lldb-server`) +on the target system. + +### Example + +``` +receive: qLaunchGDBServer;host:; +send:pid:1337;port:43001; +``` + +Request packet hostname field is not ascii-hex encoded. Hostnames +don't have `$` or `#` characters in them. + +Response to the packet is the pid of the newly launched gdbserver, +and the port it is listening for a connection on. + +When the testsuite is running, lldb may use the pid to kill off a +debugserver that doesn't seem to be responding, etc. + +## qKillSpawnedProcess + +### Brief + +Kill a process running on the target system. + +### Example + +``` +receive: qKillSpawnedProcess:1337 +send:OK +``` +The request packet has the process ID in base 10. + +## qProcessInfoPID: + +### Brief + +Gather information about a process running on the target + +### Example + +``` +receive: qProcessInfoPID:71964 +send:pid:71964;name:612e6f7574; +``` + +The request packet has the pid encoded in base 10. + +The reply has semicolon-separated `name:value` fields, two are +shown here. `pid` is base 10 encoded. `name` is ascii hex encoded. +lldb-server can reply with many additional fields, but this is probably +enough for the testsuite. + +## qfProcessInfo + +### Brief + +Search the process table for processes matching criteria, +respond with them in multiple packets. + +### Example + +``` +receive: qfProcessInfo:name_match:equals;name:6e6f70726f6365737365786973747377697468746869736e616d65; +send:pid:3500;name:612e6f7574; +``` + +The request packet has a criteria to search for, followed by +a specific name. + +| Key | Value | Description +| | - | --- +| `name` |
[Lldb-commits] [lldb] [lldb][Docs] Convert platform packets doc to Markdown (PR #89913)
@@ -0,0 +1,482 @@ +# LLDB Platform Packets +Here is a brief overview of the packets that an lldb platform server +needs to implement for the lldb testsuite to be run on a remote +target device/system. + +These are almost all lldb extensions to the gdb-remote serial +protocol. Many of the `vFile:` packets are also described in the "Host +I/O Packets" detailed in the gdb-remote protocol documentation, +although the lldb platform extensions include packets that are not +defined there (`vFile:size:`, `vFile:mode:`, `vFile:symlink`, `vFile:chmod:`). + +Most importantly, the flags that lldb passes to `vFile:open:` are +incompatible with the flags that gdb specifies. + +## QStartNoAckMode + +### Brief + +A request to stop sending ACK packets for each properly formatted packet. + +### Example + +A platform session will typically start like this: +``` +receive: +$QStartNoAckMode#b0 +send:+ <-- ACKing the properly formatted QStartNoAckMode packet +send:$OK#9a +receive: + <-- Our OK packet getting ACKed +``` + +ACK mode is now disabled. + +## qHostInfo + +### Brief + +Describe the hardware and OS of the target system + +### Example + +``` +receive: qHostInfo +send: cputype:16777228;cpusubtype:1;ostype:ios;watchpoint_exceptions_received:before;os_version:12.1;vendor:apple;default_packet_timeout:5; +``` + +All numbers are base 10, `os_version` is a string that will be parsed as major.minor.patch. + +## qModuleInfo + +### Brief + +Get information for a module by given module path and architecture. + +The response is: +* `(uuid|md5):...;triple:...;file_offset:...;file_size...;` or +* `EXX` - for any errors + +### Example + +``` +receive: qModuleInfo:2f62696e2f6c73; +``` + +## qGetWorkingDir + +### Brief + +Get the current working directory of the platform stub in +ASCII hex encoding. + +### Example + +``` +receive: qGetWorkingDir +send: 2f4170706c65496e7465726e616c2f6c6c64622f73657474696e67732f342f5465737453657474696e67732e746573745f646973617373656d626c65725f73657474696e6773 +``` + +## QSetWorkingDir + +### Brief + +Set the current working directory of the platform stub in +ASCII hex encoding. + +### Example + +``` +receive: QSetWorkingDir:2f4170706c65496e7465726e616c2f6c6c64622f73657474696e67732f342f5465737453657474696e67732e746573745f646973617373656d626c65725f73657474696e6773 +send:OK +``` + +## qPlatform_mkdir + +### Brief + +Create a directory on the target system. + +### Example + +``` +receive: qPlatform_mkdir:01fd,2f746d702f6131 +send:F0 +``` + +request packet has the fields: + 1. mode bits in base 16 + 2. file path in ascii-hex encoding + +response is F followed by the return value of the `mkdir()` call, +base 16 encoded. + +## qPlatform_shell + +### Brief + +Run a shell command on the target system, return the output. + +### Example + +``` +receive: qPlatform_shell:6c73202f746d702f,000a +send:F,0,0, +``` + +request packet has the fields: + 1. shell command ascii-hex encoded + 2. timeout + 3. working directory ascii-hex encoded (optional) + +Response is `F` followed by the return value of the command (base 16), +followed by another number, followed by the output of the command +in binary-escaped-data encoding. + +## qLaunchGDBServer + +### Brief + +Start a gdbserver process (`gdbserver`, `debugserver`, `lldb-server`) +on the target system. + +### Example + +``` +receive: qLaunchGDBServer;host:; +send:pid:1337;port:43001; +``` + +Request packet hostname field is not ascii-hex encoded. Hostnames +don't have `$` or `#` characters in them. + +Response to the packet is the pid of the newly launched gdbserver, +and the port it is listening for a connection on. + +When the testsuite is running, lldb may use the pid to kill off a +debugserver that doesn't seem to be responding, etc. + +## qKillSpawnedProcess + +### Brief + +Kill a process running on the target system. + +### Example + +``` +receive: qKillSpawnedProcess:1337 +send:OK +``` +The request packet has the process ID in base 10. + +## qProcessInfoPID: + +### Brief + +Gather information about a process running on the target + +### Example + +``` +receive: qProcessInfoPID:71964 +send:pid:71964;name:612e6f7574; +``` + +The request packet has the pid encoded in base 10. + +The reply has semicolon-separated `name:value` fields, two are +shown here. `pid` is base 10 encoded. `name` is ascii hex encoded. +lldb-server can reply with many additional fields, but this is probably +enough for the testsuite. + +## qfProcessInfo + +### Brief + +Search the process table for processes matching criteria, +respond with them in multiple packets. + +### Example + +``` +receive: qfProcessInfo:name_match:equals;name:6e6f70726f6365737365786973747377697468746869736e616d65; +send:pid:3500;name:612e6f7574; +``` + +The request packet has a criteria to search for, followed by +a specific name. + +| Key | Value | Description +| | - | --- +| `name` |
[Lldb-commits] [lldb] [lldb][Docs] Convert platform packets doc to Markdown (PR #89913)
@@ -0,0 +1,482 @@ +# LLDB Platform Packets +Here is a brief overview of the packets that an lldb platform server +needs to implement for the lldb testsuite to be run on a remote +target device/system. + +These are almost all lldb extensions to the gdb-remote serial +protocol. Many of the `vFile:` packets are also described in the "Host +I/O Packets" detailed in the gdb-remote protocol documentation, +although the lldb platform extensions include packets that are not +defined there (`vFile:size:`, `vFile:mode:`, `vFile:symlink`, `vFile:chmod:`). + +Most importantly, the flags that lldb passes to `vFile:open:` are +incompatible with the flags that gdb specifies. + +## QStartNoAckMode + +### Brief + +A request to stop sending ACK packets for each properly formatted packet. + +### Example + +A platform session will typically start like this: +``` +receive: +$QStartNoAckMode#b0 +send:+ <-- ACKing the properly formatted QStartNoAckMode packet +send:$OK#9a +receive: + <-- Our OK packet getting ACKed +``` + +ACK mode is now disabled. + +## qHostInfo + +### Brief + +Describe the hardware and OS of the target system + +### Example + +``` +receive: qHostInfo +send: cputype:16777228;cpusubtype:1;ostype:ios;watchpoint_exceptions_received:before;os_version:12.1;vendor:apple;default_packet_timeout:5; +``` + +All numbers are base 10, `os_version` is a string that will be parsed as major.minor.patch. + +## qModuleInfo + +### Brief + +Get information for a module by given module path and architecture. + +The response is: +* `(uuid|md5):...;triple:...;file_offset:...;file_size...;` or +* `EXX` - for any errors + +### Example + +``` +receive: qModuleInfo:2f62696e2f6c73; +``` + +## qGetWorkingDir + +### Brief + +Get the current working directory of the platform stub in +ASCII hex encoding. + +### Example + +``` +receive: qGetWorkingDir +send: 2f4170706c65496e7465726e616c2f6c6c64622f73657474696e67732f342f5465737453657474696e67732e746573745f646973617373656d626c65725f73657474696e6773 +``` + +## QSetWorkingDir + +### Brief + +Set the current working directory of the platform stub in +ASCII hex encoding. + +### Example + +``` +receive: QSetWorkingDir:2f4170706c65496e7465726e616c2f6c6c64622f73657474696e67732f342f5465737453657474696e67732e746573745f646973617373656d626c65725f73657474696e6773 +send:OK +``` + +## qPlatform_mkdir + +### Brief + +Create a directory on the target system. + +### Example + +``` +receive: qPlatform_mkdir:01fd,2f746d702f6131 +send:F0 +``` + +request packet has the fields: + 1. mode bits in base 16 + 2. file path in ascii-hex encoding + +response is F followed by the return value of the `mkdir()` call, +base 16 encoded. + +## qPlatform_shell + +### Brief + +Run a shell command on the target system, return the output. + +### Example + +``` +receive: qPlatform_shell:6c73202f746d702f,000a +send:F,0,0, +``` + +request packet has the fields: + 1. shell command ascii-hex encoded + 2. timeout + 3. working directory ascii-hex encoded (optional) + +Response is `F` followed by the return value of the command (base 16), +followed by another number, followed by the output of the command +in binary-escaped-data encoding. + +## qLaunchGDBServer + +### Brief + +Start a gdbserver process (`gdbserver`, `debugserver`, `lldb-server`) +on the target system. + +### Example + +``` +receive: qLaunchGDBServer;host:; +send:pid:1337;port:43001; +``` + +Request packet hostname field is not ascii-hex encoded. Hostnames +don't have `$` or `#` characters in them. + +Response to the packet is the pid of the newly launched gdbserver, +and the port it is listening for a connection on. + +When the testsuite is running, lldb may use the pid to kill off a +debugserver that doesn't seem to be responding, etc. + +## qKillSpawnedProcess + +### Brief + +Kill a process running on the target system. + +### Example + +``` +receive: qKillSpawnedProcess:1337 +send:OK +``` +The request packet has the process ID in base 10. + +## qProcessInfoPID: + +### Brief + +Gather information about a process running on the target + +### Example + +``` +receive: qProcessInfoPID:71964 +send:pid:71964;name:612e6f7574; +``` + +The request packet has the pid encoded in base 10. + +The reply has semicolon-separated `name:value` fields, two are +shown here. `pid` is base 10 encoded. `name` is ascii hex encoded. +lldb-server can reply with many additional fields, but this is probably +enough for the testsuite. + +## qfProcessInfo + +### Brief + +Search the process table for processes matching criteria, +respond with them in multiple packets. + +### Example + +``` +receive: qfProcessInfo:name_match:equals;name:6e6f70726f6365737365786973747377697468746869736e616d65; +send:pid:3500;name:612e6f7574; +``` + +The request packet has a criteria to search for, followed by +a specific name. + +| Key | Value | Description +| | - | --- +| `name` |
[Lldb-commits] [lldb] [lldb][Docs] Convert platform packets doc to Markdown (PR #89913)
@@ -0,0 +1,482 @@ +# LLDB Platform Packets +Here is a brief overview of the packets that an lldb platform server +needs to implement for the lldb testsuite to be run on a remote +target device/system. + +These are almost all lldb extensions to the gdb-remote serial +protocol. Many of the `vFile:` packets are also described in the "Host +I/O Packets" detailed in the gdb-remote protocol documentation, +although the lldb platform extensions include packets that are not +defined there (`vFile:size:`, `vFile:mode:`, `vFile:symlink`, `vFile:chmod:`). + +Most importantly, the flags that lldb passes to `vFile:open:` are +incompatible with the flags that gdb specifies. + +## QStartNoAckMode + +### Brief + +A request to stop sending ACK packets for each properly formatted packet. + +### Example + +A platform session will typically start like this: +``` +receive: +$QStartNoAckMode#b0 +send:+ <-- ACKing the properly formatted QStartNoAckMode packet +send:$OK#9a +receive: + <-- Our OK packet getting ACKed +``` + +ACK mode is now disabled. + +## qHostInfo + +### Brief + +Describe the hardware and OS of the target system + +### Example + +``` +receive: qHostInfo +send: cputype:16777228;cpusubtype:1;ostype:ios;watchpoint_exceptions_received:before;os_version:12.1;vendor:apple;default_packet_timeout:5; +``` + +All numbers are base 10, `os_version` is a string that will be parsed as major.minor.patch. + +## qModuleInfo + +### Brief + +Get information for a module by given module path and architecture. + +The response is: +* `(uuid|md5):...;triple:...;file_offset:...;file_size...;` or +* `EXX` - for any errors + +### Example + +``` +receive: qModuleInfo:2f62696e2f6c73; +``` + +## qGetWorkingDir + +### Brief + +Get the current working directory of the platform stub in +ASCII hex encoding. + +### Example + +``` +receive: qGetWorkingDir +send: 2f4170706c65496e7465726e616c2f6c6c64622f73657474696e67732f342f5465737453657474696e67732e746573745f646973617373656d626c65725f73657474696e6773 +``` + +## QSetWorkingDir + +### Brief + +Set the current working directory of the platform stub in +ASCII hex encoding. + +### Example + +``` +receive: QSetWorkingDir:2f4170706c65496e7465726e616c2f6c6c64622f73657474696e67732f342f5465737453657474696e67732e746573745f646973617373656d626c65725f73657474696e6773 +send:OK +``` + +## qPlatform_mkdir + +### Brief + +Create a directory on the target system. + +### Example + +``` +receive: qPlatform_mkdir:01fd,2f746d702f6131 +send:F0 +``` + +request packet has the fields: + 1. mode bits in base 16 + 2. file path in ascii-hex encoding + +response is F followed by the return value of the `mkdir()` call, +base 16 encoded. + +## qPlatform_shell + +### Brief + +Run a shell command on the target system, return the output. + +### Example + +``` +receive: qPlatform_shell:6c73202f746d702f,000a +send:F,0,0, +``` + +request packet has the fields: + 1. shell command ascii-hex encoded + 2. timeout + 3. working directory ascii-hex encoded (optional) + +Response is `F` followed by the return value of the command (base 16), +followed by another number, followed by the output of the command +in binary-escaped-data encoding. + +## qLaunchGDBServer + +### Brief + +Start a gdbserver process (`gdbserver`, `debugserver`, `lldb-server`) +on the target system. + +### Example + +``` +receive: qLaunchGDBServer;host:; +send:pid:1337;port:43001; +``` + +Request packet hostname field is not ascii-hex encoded. Hostnames +don't have `$` or `#` characters in them. + +Response to the packet is the pid of the newly launched gdbserver, +and the port it is listening for a connection on. + +When the testsuite is running, lldb may use the pid to kill off a +debugserver that doesn't seem to be responding, etc. + +## qKillSpawnedProcess + +### Brief + +Kill a process running on the target system. + +### Example + +``` +receive: qKillSpawnedProcess:1337 +send:OK +``` +The request packet has the process ID in base 10. + +## qProcessInfoPID: + +### Brief + +Gather information about a process running on the target hawkinsw wrote: ```suggestion Gather information about a process running on the target. ``` https://github.com/llvm/llvm-project/pull/89913 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][Docs] Convert platform packets doc to Markdown (PR #89913)
@@ -0,0 +1,482 @@ +# LLDB Platform Packets +Here is a brief overview of the packets that an lldb platform server +needs to implement for the lldb testsuite to be run on a remote +target device/system. + +These are almost all lldb extensions to the gdb-remote serial +protocol. Many of the `vFile:` packets are also described in the "Host +I/O Packets" detailed in the gdb-remote protocol documentation, +although the lldb platform extensions include packets that are not +defined there (`vFile:size:`, `vFile:mode:`, `vFile:symlink`, `vFile:chmod:`). + +Most importantly, the flags that lldb passes to `vFile:open:` are +incompatible with the flags that gdb specifies. + +## QStartNoAckMode + +### Brief + +A request to stop sending ACK packets for each properly formatted packet. + +### Example + +A platform session will typically start like this: +``` +receive: +$QStartNoAckMode#b0 +send:+ <-- ACKing the properly formatted QStartNoAckMode packet +send:$OK#9a +receive: + <-- Our OK packet getting ACKed +``` + +ACK mode is now disabled. + +## qHostInfo + +### Brief + +Describe the hardware and OS of the target system + +### Example + +``` +receive: qHostInfo +send: cputype:16777228;cpusubtype:1;ostype:ios;watchpoint_exceptions_received:before;os_version:12.1;vendor:apple;default_packet_timeout:5; +``` + +All numbers are base 10, `os_version` is a string that will be parsed as major.minor.patch. + +## qModuleInfo + +### Brief + +Get information for a module by given module path and architecture. + +The response is: +* `(uuid|md5):...;triple:...;file_offset:...;file_size...;` or +* `EXX` - for any errors + +### Example + +``` +receive: qModuleInfo:2f62696e2f6c73; +``` + +## qGetWorkingDir + +### Brief + +Get the current working directory of the platform stub in +ASCII hex encoding. + +### Example + +``` +receive: qGetWorkingDir +send: 2f4170706c65496e7465726e616c2f6c6c64622f73657474696e67732f342f5465737453657474696e67732e746573745f646973617373656d626c65725f73657474696e6773 +``` + +## QSetWorkingDir + +### Brief + +Set the current working directory of the platform stub in +ASCII hex encoding. + +### Example + +``` +receive: QSetWorkingDir:2f4170706c65496e7465726e616c2f6c6c64622f73657474696e67732f342f5465737453657474696e67732e746573745f646973617373656d626c65725f73657474696e6773 +send:OK +``` + +## qPlatform_mkdir + +### Brief + +Create a directory on the target system. + +### Example + +``` +receive: qPlatform_mkdir:01fd,2f746d702f6131 +send:F0 +``` + +request packet has the fields: + 1. mode bits in base 16 + 2. file path in ascii-hex encoding + +response is F followed by the return value of the `mkdir()` call, +base 16 encoded. + +## qPlatform_shell + +### Brief + +Run a shell command on the target system, return the output. + +### Example + +``` +receive: qPlatform_shell:6c73202f746d702f,000a +send:F,0,0, +``` + +request packet has the fields: + 1. shell command ascii-hex encoded + 2. timeout + 3. working directory ascii-hex encoded (optional) + +Response is `F` followed by the return value of the command (base 16), +followed by another number, followed by the output of the command +in binary-escaped-data encoding. + +## qLaunchGDBServer + +### Brief + +Start a gdbserver process (`gdbserver`, `debugserver`, `lldb-server`) +on the target system. + +### Example + +``` +receive: qLaunchGDBServer;host:; +send:pid:1337;port:43001; +``` + +Request packet hostname field is not ascii-hex encoded. Hostnames +don't have `$` or `#` characters in them. + +Response to the packet is the pid of the newly launched gdbserver, +and the port it is listening for a connection on. + +When the testsuite is running, lldb may use the pid to kill off a +debugserver that doesn't seem to be responding, etc. + +## qKillSpawnedProcess + +### Brief + +Kill a process running on the target system. + +### Example + +``` +receive: qKillSpawnedProcess:1337 +send:OK +``` +The request packet has the process ID in base 10. + +## qProcessInfoPID: + +### Brief + +Gather information about a process running on the target + +### Example + +``` +receive: qProcessInfoPID:71964 +send:pid:71964;name:612e6f7574; +``` + +The request packet has the pid encoded in base 10. + +The reply has semicolon-separated `name:value` fields, two are +shown here. `pid` is base 10 encoded. `name` is ascii hex encoded. +lldb-server can reply with many additional fields, but this is probably +enough for the testsuite. + +## qfProcessInfo + +### Brief + +Search the process table for processes matching criteria, +respond with them in multiple packets. + +### Example + +``` +receive: qfProcessInfo:name_match:equals;name:6e6f70726f6365737365786973747377697468746869736e616d65; +send:pid:3500;name:612e6f7574; +``` + +The request packet has a criteria to search for, followed by +a specific name. + +| Key | Value | Description +| | - | --- +| `name` |
[Lldb-commits] [lldb] [lldb][Docs] Convert platform packets doc to Markdown (PR #89913)
@@ -0,0 +1,482 @@ +# LLDB Platform Packets +Here is a brief overview of the packets that an lldb platform server +needs to implement for the lldb testsuite to be run on a remote +target device/system. + +These are almost all lldb extensions to the gdb-remote serial +protocol. Many of the `vFile:` packets are also described in the "Host +I/O Packets" detailed in the gdb-remote protocol documentation, +although the lldb platform extensions include packets that are not +defined there (`vFile:size:`, `vFile:mode:`, `vFile:symlink`, `vFile:chmod:`). + +Most importantly, the flags that lldb passes to `vFile:open:` are +incompatible with the flags that gdb specifies. + +## QStartNoAckMode + +### Brief + +A request to stop sending ACK packets for each properly formatted packet. + +### Example + +A platform session will typically start like this: +``` +receive: +$QStartNoAckMode#b0 +send:+ <-- ACKing the properly formatted QStartNoAckMode packet +send:$OK#9a +receive: + <-- Our OK packet getting ACKed +``` + +ACK mode is now disabled. + +## qHostInfo + +### Brief + +Describe the hardware and OS of the target system + +### Example + +``` +receive: qHostInfo +send: cputype:16777228;cpusubtype:1;ostype:ios;watchpoint_exceptions_received:before;os_version:12.1;vendor:apple;default_packet_timeout:5; +``` + +All numbers are base 10, `os_version` is a string that will be parsed as major.minor.patch. + +## qModuleInfo + +### Brief + +Get information for a module by given module path and architecture. + +The response is: +* `(uuid|md5):...;triple:...;file_offset:...;file_size...;` or +* `EXX` - for any errors + +### Example + +``` +receive: qModuleInfo:2f62696e2f6c73; +``` + +## qGetWorkingDir + +### Brief + +Get the current working directory of the platform stub in +ASCII hex encoding. + +### Example + +``` +receive: qGetWorkingDir +send: 2f4170706c65496e7465726e616c2f6c6c64622f73657474696e67732f342f5465737453657474696e67732e746573745f646973617373656d626c65725f73657474696e6773 +``` + +## QSetWorkingDir + +### Brief + +Set the current working directory of the platform stub in +ASCII hex encoding. + +### Example + +``` +receive: QSetWorkingDir:2f4170706c65496e7465726e616c2f6c6c64622f73657474696e67732f342f5465737453657474696e67732e746573745f646973617373656d626c65725f73657474696e6773 +send:OK +``` + +## qPlatform_mkdir + +### Brief + +Create a directory on the target system. + +### Example + +``` +receive: qPlatform_mkdir:01fd,2f746d702f6131 +send:F0 +``` + +request packet has the fields: + 1. mode bits in base 16 + 2. file path in ascii-hex encoding + +response is F followed by the return value of the `mkdir()` call, +base 16 encoded. + +## qPlatform_shell + +### Brief + +Run a shell command on the target system, return the output. + +### Example + +``` +receive: qPlatform_shell:6c73202f746d702f,000a +send:F,0,0, +``` + +request packet has the fields: + 1. shell command ascii-hex encoded + 2. timeout + 3. working directory ascii-hex encoded (optional) hawkinsw wrote: ```suggestion 3. working directory in ASCII hex encoding (optional) ``` https://github.com/llvm/llvm-project/pull/89913 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][Docs] Convert platform packets doc to Markdown (PR #89913)
@@ -0,0 +1,482 @@ +# LLDB Platform Packets +Here is a brief overview of the packets that an lldb platform server +needs to implement for the lldb testsuite to be run on a remote +target device/system. + +These are almost all lldb extensions to the gdb-remote serial +protocol. Many of the `vFile:` packets are also described in the "Host +I/O Packets" detailed in the gdb-remote protocol documentation, +although the lldb platform extensions include packets that are not +defined there (`vFile:size:`, `vFile:mode:`, `vFile:symlink`, `vFile:chmod:`). + +Most importantly, the flags that lldb passes to `vFile:open:` are +incompatible with the flags that gdb specifies. + +## QStartNoAckMode + +### Brief + +A request to stop sending ACK packets for each properly formatted packet. + +### Example + +A platform session will typically start like this: +``` +receive: +$QStartNoAckMode#b0 +send:+ <-- ACKing the properly formatted QStartNoAckMode packet +send:$OK#9a +receive: + <-- Our OK packet getting ACKed +``` + +ACK mode is now disabled. + +## qHostInfo + +### Brief + +Describe the hardware and OS of the target system + +### Example + +``` +receive: qHostInfo +send: cputype:16777228;cpusubtype:1;ostype:ios;watchpoint_exceptions_received:before;os_version:12.1;vendor:apple;default_packet_timeout:5; +``` + +All numbers are base 10, `os_version` is a string that will be parsed as major.minor.patch. + +## qModuleInfo + +### Brief + +Get information for a module by given module path and architecture. + +The response is: +* `(uuid|md5):...;triple:...;file_offset:...;file_size...;` or +* `EXX` - for any errors + +### Example + +``` +receive: qModuleInfo:2f62696e2f6c73; +``` + +## qGetWorkingDir + +### Brief + +Get the current working directory of the platform stub in +ASCII hex encoding. + +### Example + +``` +receive: qGetWorkingDir +send: 2f4170706c65496e7465726e616c2f6c6c64622f73657474696e67732f342f5465737453657474696e67732e746573745f646973617373656d626c65725f73657474696e6773 +``` + +## QSetWorkingDir + +### Brief + +Set the current working directory of the platform stub in +ASCII hex encoding. + +### Example + +``` +receive: QSetWorkingDir:2f4170706c65496e7465726e616c2f6c6c64622f73657474696e67732f342f5465737453657474696e67732e746573745f646973617373656d626c65725f73657474696e6773 +send:OK +``` + +## qPlatform_mkdir + +### Brief + +Create a directory on the target system. + +### Example + +``` +receive: qPlatform_mkdir:01fd,2f746d702f6131 +send:F0 +``` + +request packet has the fields: + 1. mode bits in base 16 + 2. file path in ascii-hex encoding + +response is F followed by the return value of the `mkdir()` call, +base 16 encoded. + +## qPlatform_shell + +### Brief + +Run a shell command on the target system, return the output. + +### Example + +``` +receive: qPlatform_shell:6c73202f746d702f,000a +send:F,0,0, +``` + +request packet has the fields: + 1. shell command ascii-hex encoded hawkinsw wrote: ```suggestion 1. shell command in ASCII hex encoding ``` https://github.com/llvm/llvm-project/pull/89913 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][Docs] Convert platform packets doc to Markdown (PR #89913)
@@ -0,0 +1,482 @@ +# LLDB Platform Packets +Here is a brief overview of the packets that an lldb platform server +needs to implement for the lldb testsuite to be run on a remote +target device/system. + +These are almost all lldb extensions to the gdb-remote serial +protocol. Many of the `vFile:` packets are also described in the "Host +I/O Packets" detailed in the gdb-remote protocol documentation, +although the lldb platform extensions include packets that are not +defined there (`vFile:size:`, `vFile:mode:`, `vFile:symlink`, `vFile:chmod:`). + +Most importantly, the flags that lldb passes to `vFile:open:` are +incompatible with the flags that gdb specifies. + +## QStartNoAckMode + +### Brief + +A request to stop sending ACK packets for each properly formatted packet. + +### Example + +A platform session will typically start like this: +``` +receive: +$QStartNoAckMode#b0 +send:+ <-- ACKing the properly formatted QStartNoAckMode packet +send:$OK#9a +receive: + <-- Our OK packet getting ACKed +``` + +ACK mode is now disabled. + +## qHostInfo + +### Brief + +Describe the hardware and OS of the target system + +### Example + +``` +receive: qHostInfo +send: cputype:16777228;cpusubtype:1;ostype:ios;watchpoint_exceptions_received:before;os_version:12.1;vendor:apple;default_packet_timeout:5; +``` + +All numbers are base 10, `os_version` is a string that will be parsed as major.minor.patch. + +## qModuleInfo + +### Brief + +Get information for a module by given module path and architecture. + +The response is: +* `(uuid|md5):...;triple:...;file_offset:...;file_size...;` or +* `EXX` - for any errors + +### Example + +``` +receive: qModuleInfo:2f62696e2f6c73; +``` + +## qGetWorkingDir + +### Brief + +Get the current working directory of the platform stub in +ASCII hex encoding. + +### Example + +``` +receive: qGetWorkingDir +send: 2f4170706c65496e7465726e616c2f6c6c64622f73657474696e67732f342f5465737453657474696e67732e746573745f646973617373656d626c65725f73657474696e6773 +``` + +## QSetWorkingDir + +### Brief + +Set the current working directory of the platform stub in +ASCII hex encoding. + +### Example + +``` +receive: QSetWorkingDir:2f4170706c65496e7465726e616c2f6c6c64622f73657474696e67732f342f5465737453657474696e67732e746573745f646973617373656d626c65725f73657474696e6773 +send:OK +``` + +## qPlatform_mkdir + +### Brief + +Create a directory on the target system. + +### Example + +``` +receive: qPlatform_mkdir:01fd,2f746d702f6131 +send:F0 +``` + +request packet has the fields: + 1. mode bits in base 16 + 2. file path in ascii-hex encoding hawkinsw wrote: ```suggestion 2. file path in ASCII hex encoding ``` (for consistency) https://github.com/llvm/llvm-project/pull/89913 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][Docs] Convert platform packets doc to Markdown (PR #89913)
@@ -0,0 +1,482 @@ +# LLDB Platform Packets +Here is a brief overview of the packets that an lldb platform server +needs to implement for the lldb testsuite to be run on a remote +target device/system. + +These are almost all lldb extensions to the gdb-remote serial +protocol. Many of the `vFile:` packets are also described in the "Host +I/O Packets" detailed in the gdb-remote protocol documentation, +although the lldb platform extensions include packets that are not +defined there (`vFile:size:`, `vFile:mode:`, `vFile:symlink`, `vFile:chmod:`). + +Most importantly, the flags that lldb passes to `vFile:open:` are +incompatible with the flags that gdb specifies. + +## QStartNoAckMode + +### Brief + +A request to stop sending ACK packets for each properly formatted packet. + +### Example + +A platform session will typically start like this: +``` +receive: +$QStartNoAckMode#b0 +send:+ <-- ACKing the properly formatted QStartNoAckMode packet +send:$OK#9a +receive: + <-- Our OK packet getting ACKed +``` + +ACK mode is now disabled. + +## qHostInfo + +### Brief + +Describe the hardware and OS of the target system + +### Example + +``` +receive: qHostInfo +send: cputype:16777228;cpusubtype:1;ostype:ios;watchpoint_exceptions_received:before;os_version:12.1;vendor:apple;default_packet_timeout:5; +``` + +All numbers are base 10, `os_version` is a string that will be parsed as major.minor.patch. + +## qModuleInfo + +### Brief + +Get information for a module by given module path and architecture. + +The response is: +* `(uuid|md5):...;triple:...;file_offset:...;file_size...;` or +* `EXX` - for any errors + +### Example + +``` +receive: qModuleInfo:2f62696e2f6c73; +``` + +## qGetWorkingDir + +### Brief + +Get the current working directory of the platform stub in +ASCII hex encoding. + +### Example + +``` +receive: qGetWorkingDir +send: 2f4170706c65496e7465726e616c2f6c6c64622f73657474696e67732f342f5465737453657474696e67732e746573745f646973617373656d626c65725f73657474696e6773 +``` + +## QSetWorkingDir + +### Brief + +Set the current working directory of the platform stub in +ASCII hex encoding. + +### Example + +``` +receive: QSetWorkingDir:2f4170706c65496e7465726e616c2f6c6c64622f73657474696e67732f342f5465737453657474696e67732e746573745f646973617373656d626c65725f73657474696e6773 +send:OK +``` + +## qPlatform_mkdir + +### Brief + +Create a directory on the target system. + +### Example + +``` +receive: qPlatform_mkdir:01fd,2f746d702f6131 +send:F0 +``` + +request packet has the fields: + 1. mode bits in base 16 + 2. file path in ascii-hex encoding + +response is F followed by the return value of the `mkdir()` call, +base 16 encoded. + +## qPlatform_shell + +### Brief + +Run a shell command on the target system, return the output. + +### Example + +``` +receive: qPlatform_shell:6c73202f746d702f,000a +send:F,0,0, +``` + +request packet has the fields: + 1. shell command ascii-hex encoded + 2. timeout + 3. working directory ascii-hex encoded (optional) + +Response is `F` followed by the return value of the command (base 16), +followed by another number, followed by the output of the command +in binary-escaped-data encoding. + +## qLaunchGDBServer + +### Brief + +Start a gdbserver process (`gdbserver`, `debugserver`, `lldb-server`) +on the target system. + +### Example + +``` +receive: qLaunchGDBServer;host:; +send:pid:1337;port:43001; +``` + +Request packet hostname field is not ascii-hex encoded. Hostnames +don't have `$` or `#` characters in them. + +Response to the packet is the pid of the newly launched gdbserver, +and the port it is listening for a connection on. + +When the testsuite is running, lldb may use the pid to kill off a +debugserver that doesn't seem to be responding, etc. + +## qKillSpawnedProcess + +### Brief + +Kill a process running on the target system. + +### Example + +``` +receive: qKillSpawnedProcess:1337 +send:OK +``` +The request packet has the process ID in base 10. + +## qProcessInfoPID: + +### Brief + +Gather information about a process running on the target + +### Example + +``` +receive: qProcessInfoPID:71964 +send:pid:71964;name:612e6f7574; +``` + +The request packet has the pid encoded in base 10. + +The reply has semicolon-separated `name:value` fields, two are +shown here. `pid` is base 10 encoded. `name` is ascii hex encoded. +lldb-server can reply with many additional fields, but this is probably +enough for the testsuite. + +## qfProcessInfo + +### Brief + +Search the process table for processes matching criteria, +respond with them in multiple packets. + +### Example + +``` +receive: qfProcessInfo:name_match:equals;name:6e6f70726f6365737365786973747377697468746869736e616d65; +send:pid:3500;name:612e6f7574; +``` + +The request packet has a criteria to search for, followed by +a specific name. + +| Key | Value | Description +| | - | --- +| `name` |
[Lldb-commits] [lldb] [lldb][Docs] Convert platform packets doc to Markdown (PR #89913)
@@ -0,0 +1,482 @@ +# LLDB Platform Packets +Here is a brief overview of the packets that an lldb platform server +needs to implement for the lldb testsuite to be run on a remote +target device/system. + +These are almost all lldb extensions to the gdb-remote serial +protocol. Many of the `vFile:` packets are also described in the "Host +I/O Packets" detailed in the gdb-remote protocol documentation, +although the lldb platform extensions include packets that are not +defined there (`vFile:size:`, `vFile:mode:`, `vFile:symlink`, `vFile:chmod:`). + +Most importantly, the flags that lldb passes to `vFile:open:` are +incompatible with the flags that gdb specifies. + +## QStartNoAckMode + +### Brief + +A request to stop sending ACK packets for each properly formatted packet. + +### Example + +A platform session will typically start like this: +``` +receive: +$QStartNoAckMode#b0 +send:+ <-- ACKing the properly formatted QStartNoAckMode packet +send:$OK#9a +receive: + <-- Our OK packet getting ACKed +``` + +ACK mode is now disabled. + +## qHostInfo + +### Brief + +Describe the hardware and OS of the target system + +### Example + +``` +receive: qHostInfo +send: cputype:16777228;cpusubtype:1;ostype:ios;watchpoint_exceptions_received:before;os_version:12.1;vendor:apple;default_packet_timeout:5; +``` + +All numbers are base 10, `os_version` is a string that will be parsed as major.minor.patch. + +## qModuleInfo + +### Brief + +Get information for a module by given module path and architecture. + +The response is: +* `(uuid|md5):...;triple:...;file_offset:...;file_size...;` or +* `EXX` - for any errors + +### Example + +``` +receive: qModuleInfo:2f62696e2f6c73; +``` + +## qGetWorkingDir + +### Brief + +Get the current working directory of the platform stub in +ASCII hex encoding. + +### Example + +``` +receive: qGetWorkingDir +send: 2f4170706c65496e7465726e616c2f6c6c64622f73657474696e67732f342f5465737453657474696e67732e746573745f646973617373656d626c65725f73657474696e6773 +``` + +## QSetWorkingDir + +### Brief + +Set the current working directory of the platform stub in +ASCII hex encoding. + +### Example + +``` +receive: QSetWorkingDir:2f4170706c65496e7465726e616c2f6c6c64622f73657474696e67732f342f5465737453657474696e67732e746573745f646973617373656d626c65725f73657474696e6773 +send:OK +``` + +## qPlatform_mkdir + +### Brief + +Create a directory on the target system. + +### Example + +``` +receive: qPlatform_mkdir:01fd,2f746d702f6131 +send:F0 +``` + +request packet has the fields: + 1. mode bits in base 16 + 2. file path in ascii-hex encoding + +response is F followed by the return value of the `mkdir()` call, +base 16 encoded. + +## qPlatform_shell + +### Brief + +Run a shell command on the target system, return the output. + +### Example + +``` +receive: qPlatform_shell:6c73202f746d702f,000a +send:F,0,0, +``` + +request packet has the fields: + 1. shell command ascii-hex encoded + 2. timeout + 3. working directory ascii-hex encoded (optional) + +Response is `F` followed by the return value of the command (base 16), +followed by another number, followed by the output of the command +in binary-escaped-data encoding. + +## qLaunchGDBServer + +### Brief + +Start a gdbserver process (`gdbserver`, `debugserver`, `lldb-server`) +on the target system. + +### Example + +``` +receive: qLaunchGDBServer;host:; +send:pid:1337;port:43001; +``` + +Request packet hostname field is not ascii-hex encoded. Hostnames +don't have `$` or `#` characters in them. + +Response to the packet is the pid of the newly launched gdbserver, +and the port it is listening for a connection on. + +When the testsuite is running, lldb may use the pid to kill off a +debugserver that doesn't seem to be responding, etc. + +## qKillSpawnedProcess + +### Brief + +Kill a process running on the target system. + +### Example + +``` +receive: qKillSpawnedProcess:1337 +send:OK +``` +The request packet has the process ID in base 10. + +## qProcessInfoPID: + +### Brief + +Gather information about a process running on the target + +### Example + +``` +receive: qProcessInfoPID:71964 +send:pid:71964;name:612e6f7574; +``` + +The request packet has the pid encoded in base 10. + +The reply has semicolon-separated `name:value` fields, two are +shown here. `pid` is base 10 encoded. `name` is ascii hex encoded. +lldb-server can reply with many additional fields, but this is probably +enough for the testsuite. + +## qfProcessInfo + +### Brief + +Search the process table for processes matching criteria, +respond with them in multiple packets. + +### Example + +``` +receive: qfProcessInfo:name_match:equals;name:6e6f70726f6365737365786973747377697468746869736e616d65; +send:pid:3500;name:612e6f7574; +``` + +The request packet has a criteria to search for, followed by +a specific name. + +| Key | Value | Description +| | - | --- +| `name` |
[Lldb-commits] [lldb] [lldb][Docs] Convert platform packets doc to Markdown (PR #89913)
@@ -0,0 +1,482 @@ +# LLDB Platform Packets +Here is a brief overview of the packets that an lldb platform server +needs to implement for the lldb testsuite to be run on a remote +target device/system. + +These are almost all lldb extensions to the gdb-remote serial +protocol. Many of the `vFile:` packets are also described in the "Host +I/O Packets" detailed in the gdb-remote protocol documentation, +although the lldb platform extensions include packets that are not +defined there (`vFile:size:`, `vFile:mode:`, `vFile:symlink`, `vFile:chmod:`). + +Most importantly, the flags that lldb passes to `vFile:open:` are +incompatible with the flags that gdb specifies. + +## QStartNoAckMode + +### Brief + +A request to stop sending ACK packets for each properly formatted packet. + +### Example + +A platform session will typically start like this: +``` +receive: +$QStartNoAckMode#b0 +send:+ <-- ACKing the properly formatted QStartNoAckMode packet +send:$OK#9a +receive: + <-- Our OK packet getting ACKed +``` + +ACK mode is now disabled. + +## qHostInfo + +### Brief + +Describe the hardware and OS of the target system + +### Example + +``` +receive: qHostInfo +send: cputype:16777228;cpusubtype:1;ostype:ios;watchpoint_exceptions_received:before;os_version:12.1;vendor:apple;default_packet_timeout:5; +``` + +All numbers are base 10, `os_version` is a string that will be parsed as major.minor.patch. + +## qModuleInfo + +### Brief + +Get information for a module by given module path and architecture. + +The response is: +* `(uuid|md5):...;triple:...;file_offset:...;file_size...;` or +* `EXX` - for any errors + +### Example + +``` +receive: qModuleInfo:2f62696e2f6c73; +``` + +## qGetWorkingDir + +### Brief + +Get the current working directory of the platform stub in +ASCII hex encoding. + +### Example + +``` +receive: qGetWorkingDir +send: 2f4170706c65496e7465726e616c2f6c6c64622f73657474696e67732f342f5465737453657474696e67732e746573745f646973617373656d626c65725f73657474696e6773 +``` + +## QSetWorkingDir + +### Brief + +Set the current working directory of the platform stub in +ASCII hex encoding. + +### Example + +``` +receive: QSetWorkingDir:2f4170706c65496e7465726e616c2f6c6c64622f73657474696e67732f342f5465737453657474696e67732e746573745f646973617373656d626c65725f73657474696e6773 +send:OK +``` + +## qPlatform_mkdir + +### Brief + +Create a directory on the target system. + +### Example + +``` +receive: qPlatform_mkdir:01fd,2f746d702f6131 +send:F0 +``` + +request packet has the fields: + 1. mode bits in base 16 + 2. file path in ascii-hex encoding + +response is F followed by the return value of the `mkdir()` call, +base 16 encoded. + +## qPlatform_shell + +### Brief + +Run a shell command on the target system, return the output. + +### Example + +``` +receive: qPlatform_shell:6c73202f746d702f,000a +send:F,0,0, +``` + +request packet has the fields: + 1. shell command ascii-hex encoded + 2. timeout + 3. working directory ascii-hex encoded (optional) + +Response is `F` followed by the return value of the command (base 16), +followed by another number, followed by the output of the command +in binary-escaped-data encoding. + +## qLaunchGDBServer + +### Brief + +Start a gdbserver process (`gdbserver`, `debugserver`, `lldb-server`) +on the target system. + +### Example + +``` +receive: qLaunchGDBServer;host:; +send:pid:1337;port:43001; +``` + +Request packet hostname field is not ascii-hex encoded. Hostnames hawkinsw wrote: ```suggestion Request packet hostname field is not ASCII hex encoded. Hostnames ``` https://github.com/llvm/llvm-project/pull/89913 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][Docs] Convert platform packets doc to Markdown (PR #89913)
https://github.com/hawkinsw edited https://github.com/llvm/llvm-project/pull/89913 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][Docs] Convert platform packets doc to Markdown (PR #89913)
https://github.com/hawkinsw commented: I hope that these little fixes are helpful! I think that the documentation is really thorough and helpful! https://github.com/llvm/llvm-project/pull/89913 ___ 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 vFile:exists and vFile:MD5 (PR #89357)
https://github.com/hawkinsw commented: I hate when I can only contribute nits, but I wanted to try to be helpful! https://github.com/llvm/llvm-project/pull/89357 ___ 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 vFile:exists and vFile:MD5 (PR #89357)
@@ -429,7 +429,43 @@ incompatible with the flags that gdb specifies. // // Response is F, followed by the number of bytes written (base 16) +//-- +// vFile:MD5: +// +// BRIEF +// Generate an MD5 hash of the file at the given path. +// +// EXAMPLE +// +// receive: vFile:MD5:2f746d702f61 +// send (success): F, +// send (failure): F,x +// +// request packet contains the ASCII hex encoded filename +// +// If the hash succeeded, the response is "F," followed by the low 64 +// bits of the result, then the high 64 bits of the result. Both are hex hawkinsw wrote: ```suggestion // bits of the result, and finally the high 64 bits of the result. Both are in hex format ``` https://github.com/llvm/llvm-project/pull/89357 ___ 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 vFile:exists and vFile:MD5 (PR #89357)
https://github.com/hawkinsw edited https://github.com/llvm/llvm-project/pull/89357 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] DebugInfoD issues, take 2 (PR #86812)
hawkinsw wrote: > The previous diff (and it's subsequent fix) were reverted as the tests didn't > work properly on the AArch64 & ARM LLDB buildbots. I made a couple more minor > changes to tests (from @clayborg's feedback) and disabled them for non > Linux-x86(_64) builds, as I don't have the ability do anything about an ARM64 > Linux failure. If I had to guess, I'd say the toolchain on the buildbots > isn't respecting the `-Wl,--build-id` flag. Maybe, one day, when I have a > Linux AArch64 system I'll dig in to it. > I have such a system and have dug into the DebugInfoD "space" recently and would be more than willing (eager, even) to help! If you are on the Discord server, we can message and find a way to collaborate (I am hawkinsw). https://github.com/llvm/llvm-project/pull/86812 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add SBProcess methods for get/set/use address masks (PR #83095)
hawkinsw wrote: > Thanks for the second round of feedback @hawkinsw . Let me try to read the > Doxygen docs a little more closely tonight and see if the references I threw > in there might actually do what I hoped they would. I briefly looked at the > Doxygen docs to see the Grouping feature and got a little overwhelmed and > wasn't sure what the expected formatting would be. Not a problem at all! Just trying to help!! Will https://github.com/llvm/llvm-project/pull/83095 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add SBProcess methods for get/set/use address masks (PR #83095)
@@ -407,6 +407,117 @@ class LLDB_API SBProcess {
/// the process isn't loaded from a core file.
lldb::SBFileSpec GetCoreFile();
+ /// \{
+ /// \group Mask Address Methods
+ ///
+ /// \a type
+ /// All of the methods in this group take \a type argument
+ /// which is an AddressMaskType enum value.
+ /// There can be different address masks for code addresses and
+ /// data addresses, this argument can select which to get/set,
+ /// or to use when clearing non-addressable bits from an address.
+ /// On AArch32 code with arm+thumb code, where instructions start
+ /// on even addresses, the 0th bit may be used to indicate that
+ /// a function is thumb code. On such a target, the eAddressMaskTypeCode
+ /// may clear the 0th bit from an address to get the actual address.
+ ///
+ /// \a addr_range
+ /// Many of the methods in this group take an \a addr_range argument
+ /// which is an AddressMaskRange enum value.
+ /// Needing to specify the address range is highly unusual, and the
+ /// default argument can be used in nearly all circumstances.
+ /// On some architectures like AArch64, it is possible to have
+ /// different page table setups for low and high memory, so different
+ /// numbers of bits relevant to addressing. It is possible to have
+ /// a program running in one half of memory and accessing the other
+ /// as heap, so we need to maintain two different sets of address masks
+ /// to debug this correctly.
+
+ /// Get the current address mask that will be applied to addresses
+ /// before reading from memory.
+ ///
+ /// \param[in] type
+ /// See \ref Mask Address Methods descripton of this argument.
+ /// eAddressMaskTypeAny is often a suitable value when code and
+ /// data masks are the same on a given target.
+ ///
+ /// \param[in] addr_range
+ /// See \ref Mask Address Methods descripton of this argument.
+ /// This will default to eAddressMaskRangeLow which is the
+ /// only set of masks used normally.
+ ///
+ /// \return
+ /// The address mask currently in use. Bits which are not used
+ /// for addressing will be set to 1 in the mask.
+ lldb::addr_t GetAddressMask(
+ lldb::AddressMaskType type,
+ lldb::AddressMaskRange addr_range = lldb::eAddressMaskRangeLow);
+
+ /// Set the current address mask that can be applied to addresses
+ /// before reading from memory.
+ ///
+ /// \param[in] type
+ /// See \ref Mask Address Methods descripton of this argument.
+ /// eAddressMaskTypeAll is often a suitable value when the
+ /// same mask is being set for both code and data.
+ ///
+ /// \param[in] mask
+ /// The address mask to set. Bits which are not used for addressing
+ /// should be set to 1 in the mask.
+ ///
+ /// \param[in] addr_range
+ /// See \ref Mask Address Methods descripton of this argument.
hawkinsw wrote:
```suggestion
/// See \ref Mask Address Methods description of this argument.
```
https://github.com/llvm/llvm-project/pull/83095
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add SBProcess methods for get/set/use address masks (PR #83095)
@@ -407,6 +407,117 @@ class LLDB_API SBProcess {
/// the process isn't loaded from a core file.
lldb::SBFileSpec GetCoreFile();
+ /// \{
+ /// \group Mask Address Methods
+ ///
+ /// \a type
+ /// All of the methods in this group take \a type argument
+ /// which is an AddressMaskType enum value.
+ /// There can be different address masks for code addresses and
+ /// data addresses, this argument can select which to get/set,
+ /// or to use when clearing non-addressable bits from an address.
+ /// On AArch32 code with arm+thumb code, where instructions start
+ /// on even addresses, the 0th bit may be used to indicate that
+ /// a function is thumb code. On such a target, the eAddressMaskTypeCode
+ /// may clear the 0th bit from an address to get the actual address.
+ ///
+ /// \a addr_range
+ /// Many of the methods in this group take an \a addr_range argument
+ /// which is an AddressMaskRange enum value.
+ /// Needing to specify the address range is highly unusual, and the
+ /// default argument can be used in nearly all circumstances.
+ /// On some architectures like AArch64, it is possible to have
+ /// different page table setups for low and high memory, so different
+ /// numbers of bits relevant to addressing. It is possible to have
+ /// a program running in one half of memory and accessing the other
+ /// as heap, so we need to maintain two different sets of address masks
+ /// to debug this correctly.
+
+ /// Get the current address mask that will be applied to addresses
+ /// before reading from memory.
+ ///
+ /// \param[in] type
+ /// See \ref Mask Address Methods descripton of this argument.
+ /// eAddressMaskTypeAny is often a suitable value when code and
+ /// data masks are the same on a given target.
+ ///
+ /// \param[in] addr_range
+ /// See \ref Mask Address Methods descripton of this argument.
+ /// This will default to eAddressMaskRangeLow which is the
+ /// only set of masks used normally.
+ ///
+ /// \return
+ /// The address mask currently in use. Bits which are not used
+ /// for addressing will be set to 1 in the mask.
+ lldb::addr_t GetAddressMask(
+ lldb::AddressMaskType type,
+ lldb::AddressMaskRange addr_range = lldb::eAddressMaskRangeLow);
+
+ /// Set the current address mask that can be applied to addresses
+ /// before reading from memory.
+ ///
+ /// \param[in] type
+ /// See \ref Mask Address Methods descripton of this argument.
+ /// eAddressMaskTypeAll is often a suitable value when the
+ /// same mask is being set for both code and data.
+ ///
+ /// \param[in] mask
+ /// The address mask to set. Bits which are not used for addressing
+ /// should be set to 1 in the mask.
+ ///
+ /// \param[in] addr_range
+ /// See \ref Mask Address Methods descripton of this argument.
+ /// This will default to eAddressMaskRangeLow which is the
+ /// only set of masks used normally.
+ void SetAddressMask(
+ lldb::AddressMaskType type, lldb::addr_t mask,
+ lldb::AddressMaskRange addr_range = lldb::eAddressMaskRangeLow);
+
+ /// Set the number of bits used for addressing in this Process.
+ ///
+ /// In some environments, the number of bits that are used for addressing
+ /// is the natural representation instead of a mask, but lldb
+ /// internally represents this as a mask. This method calculates
+ /// the addressing mask that lldb uses that number of addressable bits.
+ ///
+ /// \param[in] type
+ /// See \ref Mask Address Methods descripton of this argument.
+ /// eAddressMaskTypeAll is often a suitable value when the
+ /// same mask is being set for both code and data.
+ ///
+ /// \param[in] num_bits
+ /// Number of bits that are used for addressing.
+ /// A value of 42 indicates that the low 42 bits are relevant for
+ /// addressing, and that higher order bits may be used for various
hawkinsw wrote:
```suggestion
/// addressing, and that higher-order bits may be used for various
```
https://github.com/llvm/llvm-project/pull/83095
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add SBProcess methods for get/set/use address masks (PR #83095)
@@ -407,6 +407,117 @@ class LLDB_API SBProcess {
/// the process isn't loaded from a core file.
lldb::SBFileSpec GetCoreFile();
+ /// \{
+ /// \group Mask Address Methods
+ ///
+ /// \a type
+ /// All of the methods in this group take \a type argument
+ /// which is an AddressMaskType enum value.
+ /// There can be different address masks for code addresses and
+ /// data addresses, this argument can select which to get/set,
+ /// or to use when clearing non-addressable bits from an address.
+ /// On AArch32 code with arm+thumb code, where instructions start
+ /// on even addresses, the 0th bit may be used to indicate that
+ /// a function is thumb code. On such a target, the eAddressMaskTypeCode
+ /// may clear the 0th bit from an address to get the actual address.
+ ///
+ /// \a addr_range
+ /// Many of the methods in this group take an \a addr_range argument
+ /// which is an AddressMaskRange enum value.
+ /// Needing to specify the address range is highly unusual, and the
+ /// default argument can be used in nearly all circumstances.
+ /// On some architectures like AArch64, it is possible to have
+ /// different page table setups for low and high memory, so different
+ /// numbers of bits relevant to addressing. It is possible to have
+ /// a program running in one half of memory and accessing the other
+ /// as heap, so we need to maintain two different sets of address masks
+ /// to debug this correctly.
+
+ /// Get the current address mask that will be applied to addresses
+ /// before reading from memory.
+ ///
+ /// \param[in] type
+ /// See \ref Mask Address Methods descripton of this argument.
+ /// eAddressMaskTypeAny is often a suitable value when code and
+ /// data masks are the same on a given target.
+ ///
+ /// \param[in] addr_range
+ /// See \ref Mask Address Methods descripton of this argument.
+ /// This will default to eAddressMaskRangeLow which is the
+ /// only set of masks used normally.
+ ///
+ /// \return
+ /// The address mask currently in use. Bits which are not used
+ /// for addressing will be set to 1 in the mask.
+ lldb::addr_t GetAddressMask(
+ lldb::AddressMaskType type,
+ lldb::AddressMaskRange addr_range = lldb::eAddressMaskRangeLow);
+
+ /// Set the current address mask that can be applied to addresses
+ /// before reading from memory.
+ ///
+ /// \param[in] type
+ /// See \ref Mask Address Methods descripton of this argument.
+ /// eAddressMaskTypeAll is often a suitable value when the
+ /// same mask is being set for both code and data.
+ ///
+ /// \param[in] mask
+ /// The address mask to set. Bits which are not used for addressing
+ /// should be set to 1 in the mask.
+ ///
+ /// \param[in] addr_range
+ /// See \ref Mask Address Methods descripton of this argument.
+ /// This will default to eAddressMaskRangeLow which is the
+ /// only set of masks used normally.
+ void SetAddressMask(
+ lldb::AddressMaskType type, lldb::addr_t mask,
+ lldb::AddressMaskRange addr_range = lldb::eAddressMaskRangeLow);
+
+ /// Set the number of bits used for addressing in this Process.
+ ///
+ /// In some environments, the number of bits that are used for addressing
+ /// is the natural representation instead of a mask, but lldb
+ /// internally represents this as a mask. This method calculates
+ /// the addressing mask that lldb uses that number of addressable bits.
+ ///
+ /// \param[in] type
+ /// See \ref Mask Address Methods descripton of this argument.
hawkinsw wrote:
```suggestion
/// See \ref Mask Address Methods description of this argument.
```
https://github.com/llvm/llvm-project/pull/83095
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add SBProcess methods for get/set/use address masks (PR #83095)
@@ -407,6 +407,117 @@ class LLDB_API SBProcess {
/// the process isn't loaded from a core file.
lldb::SBFileSpec GetCoreFile();
+ /// \{
+ /// \group Mask Address Methods
+ ///
+ /// \a type
+ /// All of the methods in this group take \a type argument
+ /// which is an AddressMaskType enum value.
+ /// There can be different address masks for code addresses and
+ /// data addresses, this argument can select which to get/set,
+ /// or to use when clearing non-addressable bits from an address.
+ /// On AArch32 code with arm+thumb code, where instructions start
+ /// on even addresses, the 0th bit may be used to indicate that
+ /// a function is thumb code. On such a target, the eAddressMaskTypeCode
+ /// may clear the 0th bit from an address to get the actual address.
+ ///
+ /// \a addr_range
+ /// Many of the methods in this group take an \a addr_range argument
+ /// which is an AddressMaskRange enum value.
+ /// Needing to specify the address range is highly unusual, and the
+ /// default argument can be used in nearly all circumstances.
+ /// On some architectures like AArch64, it is possible to have
+ /// different page table setups for low and high memory, so different
+ /// numbers of bits relevant to addressing. It is possible to have
+ /// a program running in one half of memory and accessing the other
+ /// as heap, so we need to maintain two different sets of address masks
+ /// to debug this correctly.
+
+ /// Get the current address mask that will be applied to addresses
+ /// before reading from memory.
+ ///
+ /// \param[in] type
+ /// See \ref Mask Address Methods descripton of this argument.
+ /// eAddressMaskTypeAny is often a suitable value when code and
+ /// data masks are the same on a given target.
+ ///
+ /// \param[in] addr_range
+ /// See \ref Mask Address Methods descripton of this argument.
+ /// This will default to eAddressMaskRangeLow which is the
+ /// only set of masks used normally.
+ ///
+ /// \return
+ /// The address mask currently in use. Bits which are not used
+ /// for addressing will be set to 1 in the mask.
+ lldb::addr_t GetAddressMask(
+ lldb::AddressMaskType type,
+ lldb::AddressMaskRange addr_range = lldb::eAddressMaskRangeLow);
+
+ /// Set the current address mask that can be applied to addresses
+ /// before reading from memory.
+ ///
+ /// \param[in] type
+ /// See \ref Mask Address Methods descripton of this argument.
+ /// eAddressMaskTypeAll is often a suitable value when the
+ /// same mask is being set for both code and data.
+ ///
+ /// \param[in] mask
+ /// The address mask to set. Bits which are not used for addressing
+ /// should be set to 1 in the mask.
+ ///
+ /// \param[in] addr_range
+ /// See \ref Mask Address Methods descripton of this argument.
+ /// This will default to eAddressMaskRangeLow which is the
+ /// only set of masks used normally.
+ void SetAddressMask(
+ lldb::AddressMaskType type, lldb::addr_t mask,
+ lldb::AddressMaskRange addr_range = lldb::eAddressMaskRangeLow);
+
+ /// Set the number of bits used for addressing in this Process.
+ ///
+ /// In some environments, the number of bits that are used for addressing
+ /// is the natural representation instead of a mask, but lldb
+ /// internally represents this as a mask. This method calculates
+ /// the addressing mask that lldb uses that number of addressable bits.
+ ///
+ /// \param[in] type
+ /// See \ref Mask Address Methods descripton of this argument.
+ /// eAddressMaskTypeAll is often a suitable value when the
+ /// same mask is being set for both code and data.
+ ///
+ /// \param[in] num_bits
+ /// Number of bits that are used for addressing.
+ /// A value of 42 indicates that the low 42 bits are relevant for
+ /// addressing, and that higher order bits may be used for various
+ /// metadata like pointer authentication, Type Byte Ignore, etc.
+ ///
+ /// \param[in] addr_range
+ /// See \ref Mask Address Methods descripton of this argument.
hawkinsw wrote:
```suggestion
/// See \ref Mask Address Methods description of this argument.
```
https://github.com/llvm/llvm-project/pull/83095
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add SBProcess methods for get/set/use address masks (PR #83095)
@@ -407,6 +407,117 @@ class LLDB_API SBProcess {
/// the process isn't loaded from a core file.
lldb::SBFileSpec GetCoreFile();
+ /// \{
+ /// \group Mask Address Methods
+ ///
+ /// \a type
+ /// All of the methods in this group take \a type argument
+ /// which is an AddressMaskType enum value.
+ /// There can be different address masks for code addresses and
+ /// data addresses, this argument can select which to get/set,
+ /// or to use when clearing non-addressable bits from an address.
+ /// On AArch32 code with arm+thumb code, where instructions start
+ /// on even addresses, the 0th bit may be used to indicate that
+ /// a function is thumb code. On such a target, the eAddressMaskTypeCode
+ /// may clear the 0th bit from an address to get the actual address.
+ ///
+ /// \a addr_range
+ /// Many of the methods in this group take an \a addr_range argument
+ /// which is an AddressMaskRange enum value.
+ /// Needing to specify the address range is highly unusual, and the
+ /// default argument can be used in nearly all circumstances.
+ /// On some architectures like AArch64, it is possible to have
+ /// different page table setups for low and high memory, so different
+ /// numbers of bits relevant to addressing. It is possible to have
+ /// a program running in one half of memory and accessing the other
+ /// as heap, so we need to maintain two different sets of address masks
+ /// to debug this correctly.
+
+ /// Get the current address mask that will be applied to addresses
+ /// before reading from memory.
+ ///
+ /// \param[in] type
+ /// See \ref Mask Address Methods descripton of this argument.
+ /// eAddressMaskTypeAny is often a suitable value when code and
+ /// data masks are the same on a given target.
+ ///
+ /// \param[in] addr_range
+ /// See \ref Mask Address Methods descripton of this argument.
hawkinsw wrote:
```suggestion
/// See \ref Mask Address Methods description of this argument.
```
https://github.com/llvm/llvm-project/pull/83095
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add SBProcess methods for get/set/use address masks (PR #83095)
@@ -407,6 +407,117 @@ class LLDB_API SBProcess {
/// the process isn't loaded from a core file.
lldb::SBFileSpec GetCoreFile();
+ /// \{
+ /// \group Mask Address Methods
+ ///
+ /// \a type
+ /// All of the methods in this group take \a type argument
+ /// which is an AddressMaskType enum value.
hawkinsw wrote:
Can our Doxygen system make a reference to the documentation for these named
constants? Just a question.
https://github.com/llvm/llvm-project/pull/83095
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add SBProcess methods for get/set/use address masks (PR #83095)
@@ -407,6 +407,117 @@ class LLDB_API SBProcess {
/// the process isn't loaded from a core file.
lldb::SBFileSpec GetCoreFile();
+ /// \{
+ /// \group Mask Address Methods
+ ///
+ /// \a type
+ /// All of the methods in this group take \a type argument
+ /// which is an AddressMaskType enum value.
+ /// There can be different address masks for code addresses and
+ /// data addresses, this argument can select which to get/set,
+ /// or to use when clearing non-addressable bits from an address.
+ /// On AArch32 code with arm+thumb code, where instructions start
+ /// on even addresses, the 0th bit may be used to indicate that
+ /// a function is thumb code. On such a target, the eAddressMaskTypeCode
+ /// may clear the 0th bit from an address to get the actual address.
+ ///
+ /// \a addr_range
+ /// Many of the methods in this group take an \a addr_range argument
+ /// which is an AddressMaskRange enum value.
+ /// Needing to specify the address range is highly unusual, and the
+ /// default argument can be used in nearly all circumstances.
+ /// On some architectures like AArch64, it is possible to have
+ /// different page table setups for low and high memory, so different
+ /// numbers of bits relevant to addressing. It is possible to have
+ /// a program running in one half of memory and accessing the other
+ /// as heap, so we need to maintain two different sets of address masks
+ /// to debug this correctly.
+
+ /// Get the current address mask that will be applied to addresses
+ /// before reading from memory.
+ ///
+ /// \param[in] type
+ /// See \ref Mask Address Methods descripton of this argument.
+ /// eAddressMaskTypeAny is often a suitable value when code and
+ /// data masks are the same on a given target.
+ ///
+ /// \param[in] addr_range
+ /// See \ref Mask Address Methods descripton of this argument.
+ /// This will default to eAddressMaskRangeLow which is the
+ /// only set of masks used normally.
+ ///
+ /// \return
+ /// The address mask currently in use. Bits which are not used
+ /// for addressing will be set to 1 in the mask.
+ lldb::addr_t GetAddressMask(
+ lldb::AddressMaskType type,
+ lldb::AddressMaskRange addr_range = lldb::eAddressMaskRangeLow);
+
+ /// Set the current address mask that can be applied to addresses
+ /// before reading from memory.
+ ///
+ /// \param[in] type
+ /// See \ref Mask Address Methods descripton of this argument.
+ /// eAddressMaskTypeAll is often a suitable value when the
+ /// same mask is being set for both code and data.
+ ///
+ /// \param[in] mask
+ /// The address mask to set. Bits which are not used for addressing
+ /// should be set to 1 in the mask.
+ ///
+ /// \param[in] addr_range
+ /// See \ref Mask Address Methods descripton of this argument.
+ /// This will default to eAddressMaskRangeLow which is the
+ /// only set of masks used normally.
+ void SetAddressMask(
+ lldb::AddressMaskType type, lldb::addr_t mask,
+ lldb::AddressMaskRange addr_range = lldb::eAddressMaskRangeLow);
+
+ /// Set the number of bits used for addressing in this Process.
+ ///
+ /// In some environments, the number of bits that are used for addressing
+ /// is the natural representation instead of a mask, but lldb
+ /// internally represents this as a mask. This method calculates
+ /// the addressing mask that lldb uses that number of addressable bits.
+ ///
+ /// \param[in] type
+ /// See \ref Mask Address Methods descripton of this argument.
+ /// eAddressMaskTypeAll is often a suitable value when the
+ /// same mask is being set for both code and data.
+ ///
+ /// \param[in] num_bits
+ /// Number of bits that are used for addressing.
+ /// A value of 42 indicates that the low 42 bits are relevant for
hawkinsw wrote:
```suggestion
/// For example, a value of 42 indicates that the low 42 bits are
relevant for
```
https://github.com/llvm/llvm-project/pull/83095
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add SBProcess methods for get/set/use address masks (PR #83095)
@@ -407,6 +407,117 @@ class LLDB_API SBProcess {
/// the process isn't loaded from a core file.
lldb::SBFileSpec GetCoreFile();
+ /// \{
+ /// \group Mask Address Methods
+ ///
+ /// \a type
+ /// All of the methods in this group take \a type argument
+ /// which is an AddressMaskType enum value.
+ /// There can be different address masks for code addresses and
+ /// data addresses, this argument can select which to get/set,
+ /// or to use when clearing non-addressable bits from an address.
+ /// On AArch32 code with arm+thumb code, where instructions start
+ /// on even addresses, the 0th bit may be used to indicate that
+ /// a function is thumb code. On such a target, the eAddressMaskTypeCode
+ /// may clear the 0th bit from an address to get the actual address.
+ ///
+ /// \a addr_range
+ /// Many of the methods in this group take an \a addr_range argument
+ /// which is an AddressMaskRange enum value.
+ /// Needing to specify the address range is highly unusual, and the
+ /// default argument can be used in nearly all circumstances.
+ /// On some architectures like AArch64, it is possible to have
+ /// different page table setups for low and high memory, so different
+ /// numbers of bits relevant to addressing. It is possible to have
+ /// a program running in one half of memory and accessing the other
+ /// as heap, so we need to maintain two different sets of address masks
+ /// to debug this correctly.
+
+ /// Get the current address mask that will be applied to addresses
+ /// before reading from memory.
+ ///
+ /// \param[in] type
+ /// See \ref Mask Address Methods descripton of this argument.
+ /// eAddressMaskTypeAny is often a suitable value when code and
+ /// data masks are the same on a given target.
+ ///
+ /// \param[in] addr_range
+ /// See \ref Mask Address Methods descripton of this argument.
+ /// This will default to eAddressMaskRangeLow which is the
+ /// only set of masks used normally.
+ ///
+ /// \return
+ /// The address mask currently in use. Bits which are not used
+ /// for addressing will be set to 1 in the mask.
+ lldb::addr_t GetAddressMask(
+ lldb::AddressMaskType type,
+ lldb::AddressMaskRange addr_range = lldb::eAddressMaskRangeLow);
+
+ /// Set the current address mask that can be applied to addresses
+ /// before reading from memory.
+ ///
+ /// \param[in] type
+ /// See \ref Mask Address Methods descripton of this argument.
+ /// eAddressMaskTypeAll is often a suitable value when the
+ /// same mask is being set for both code and data.
+ ///
+ /// \param[in] mask
+ /// The address mask to set. Bits which are not used for addressing
+ /// should be set to 1 in the mask.
+ ///
+ /// \param[in] addr_range
+ /// See \ref Mask Address Methods descripton of this argument.
+ /// This will default to eAddressMaskRangeLow which is the
+ /// only set of masks used normally.
+ void SetAddressMask(
+ lldb::AddressMaskType type, lldb::addr_t mask,
+ lldb::AddressMaskRange addr_range = lldb::eAddressMaskRangeLow);
+
+ /// Set the number of bits used for addressing in this Process.
+ ///
+ /// In some environments, the number of bits that are used for addressing
+ /// is the natural representation instead of a mask, but lldb
+ /// internally represents this as a mask. This method calculates
+ /// the addressing mask that lldb uses that number of addressable bits.
+ ///
+ /// \param[in] type
+ /// See \ref Mask Address Methods descripton of this argument.
+ /// eAddressMaskTypeAll is often a suitable value when the
+ /// same mask is being set for both code and data.
+ ///
+ /// \param[in] num_bits
+ /// Number of bits that are used for addressing.
+ /// A value of 42 indicates that the low 42 bits are relevant for
+ /// addressing, and that higher order bits may be used for various
+ /// metadata like pointer authentication, Type Byte Ignore, etc.
+ ///
+ /// \param[in] addr_range
+ /// See \ref Mask Address Methods descripton of this argument.
+ /// This will default to eAddressMaskRangeLow which is the
+ /// only set of masks used normally.
+ void
+ SetAddressableBits(AddressMaskType type, uint32_t num_bits,
+ AddressMaskRange addr_range = lldb::eAddressMaskRangeLow);
+
+ /// Clear the non-addressable bits of an \a addr value and return a
+ /// virtual address in memory.
+ ///
+ /// Bits that are not used in addressing may be used for other purposes;
+ /// pointer authentication, or metadata in the top byte, or the 0th bit
+ /// of armv7 code addresses to indicate arm/thumb are common examples.
+ ///
+ /// \param[in] addr
+ /// The address that should be cleared of non-addressable bits.
+ ///
+ /// \param[in] type
+ /// See \ref Mask Address Methods descripton of this argument.
hawkin
[Lldb-commits] [lldb] [lldb] Add SBProcess methods for get/set/use address masks (PR #83095)
@@ -407,6 +407,117 @@ class LLDB_API SBProcess {
/// the process isn't loaded from a core file.
lldb::SBFileSpec GetCoreFile();
+ /// \{
+ /// \group Mask Address Methods
+ ///
+ /// \a type
+ /// All of the methods in this group take \a type argument
+ /// which is an AddressMaskType enum value.
+ /// There can be different address masks for code addresses and
+ /// data addresses, this argument can select which to get/set,
+ /// or to use when clearing non-addressable bits from an address.
+ /// On AArch32 code with arm+thumb code, where instructions start
+ /// on even addresses, the 0th bit may be used to indicate that
+ /// a function is thumb code. On such a target, the eAddressMaskTypeCode
+ /// may clear the 0th bit from an address to get the actual address.
+ ///
+ /// \a addr_range
+ /// Many of the methods in this group take an \a addr_range argument
+ /// which is an AddressMaskRange enum value.
+ /// Needing to specify the address range is highly unusual, and the
+ /// default argument can be used in nearly all circumstances.
+ /// On some architectures like AArch64, it is possible to have
+ /// different page table setups for low and high memory, so different
+ /// numbers of bits relevant to addressing. It is possible to have
+ /// a program running in one half of memory and accessing the other
+ /// as heap, so we need to maintain two different sets of address masks
+ /// to debug this correctly.
+
+ /// Get the current address mask that will be applied to addresses
+ /// before reading from memory.
+ ///
+ /// \param[in] type
+ /// See \ref Mask Address Methods descripton of this argument.
+ /// eAddressMaskTypeAny is often a suitable value when code and
+ /// data masks are the same on a given target.
+ ///
+ /// \param[in] addr_range
+ /// See \ref Mask Address Methods descripton of this argument.
+ /// This will default to eAddressMaskRangeLow which is the
+ /// only set of masks used normally.
+ ///
+ /// \return
+ /// The address mask currently in use. Bits which are not used
+ /// for addressing will be set to 1 in the mask.
+ lldb::addr_t GetAddressMask(
+ lldb::AddressMaskType type,
+ lldb::AddressMaskRange addr_range = lldb::eAddressMaskRangeLow);
+
+ /// Set the current address mask that can be applied to addresses
+ /// before reading from memory.
+ ///
+ /// \param[in] type
+ /// See \ref Mask Address Methods descripton of this argument.
hawkinsw wrote:
```suggestion
/// See \ref Mask Address Methods description of this argument.
```
https://github.com/llvm/llvm-project/pull/83095
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add SBProcess methods for get/set/use address masks (PR #83095)
@@ -407,6 +407,117 @@ class LLDB_API SBProcess {
/// the process isn't loaded from a core file.
lldb::SBFileSpec GetCoreFile();
+ /// \{
+ /// \group Mask Address Methods
+ ///
+ /// \a type
+ /// All of the methods in this group take \a type argument
+ /// which is an AddressMaskType enum value.
+ /// There can be different address masks for code addresses and
+ /// data addresses, this argument can select which to get/set,
+ /// or to use when clearing non-addressable bits from an address.
+ /// On AArch32 code with arm+thumb code, where instructions start
+ /// on even addresses, the 0th bit may be used to indicate that
+ /// a function is thumb code. On such a target, the eAddressMaskTypeCode
+ /// may clear the 0th bit from an address to get the actual address.
+ ///
+ /// \a addr_range
+ /// Many of the methods in this group take an \a addr_range argument
+ /// which is an AddressMaskRange enum value.
+ /// Needing to specify the address range is highly unusual, and the
+ /// default argument can be used in nearly all circumstances.
+ /// On some architectures like AArch64, it is possible to have
hawkinsw wrote:
```suggestion
/// On some architectures (e.g., AArch64), it is possible to have
```
https://github.com/llvm/llvm-project/pull/83095
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add SBProcess methods for get/set/use address masks (PR #83095)
@@ -407,6 +407,117 @@ class LLDB_API SBProcess {
/// the process isn't loaded from a core file.
lldb::SBFileSpec GetCoreFile();
+ /// \{
+ /// \group Mask Address Methods
+ ///
+ /// \a type
+ /// All of the methods in this group take \a type argument
+ /// which is an AddressMaskType enum value.
+ /// There can be different address masks for code addresses and
+ /// data addresses, this argument can select which to get/set,
+ /// or to use when clearing non-addressable bits from an address.
+ /// On AArch32 code with arm+thumb code, where instructions start
+ /// on even addresses, the 0th bit may be used to indicate that
+ /// a function is thumb code. On such a target, the eAddressMaskTypeCode
+ /// may clear the 0th bit from an address to get the actual address.
+ ///
+ /// \a addr_range
+ /// Many of the methods in this group take an \a addr_range argument
+ /// which is an AddressMaskRange enum value.
+ /// Needing to specify the address range is highly unusual, and the
+ /// default argument can be used in nearly all circumstances.
+ /// On some architectures like AArch64, it is possible to have
+ /// different page table setups for low and high memory, so different
+ /// numbers of bits relevant to addressing. It is possible to have
+ /// a program running in one half of memory and accessing the other
+ /// as heap, so we need to maintain two different sets of address masks
+ /// to debug this correctly.
+
+ /// Get the current address mask that will be applied to addresses
+ /// before reading from memory.
+ ///
+ /// \param[in] type
+ /// See \ref Mask Address Methods descripton of this argument.
hawkinsw wrote:
```suggestion
/// See \ref Mask Address Methods description of this argument.
```
https://github.com/llvm/llvm-project/pull/83095
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add SBProcess methods for get/set/use address masks (PR #83095)
https://github.com/hawkinsw commented: As I said before, I really appreciate you doing such in-depth documentation. I hope these little suggestions help! https://github.com/llvm/llvm-project/pull/83095 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add SBProcess methods for get/set/use address masks (PR #83095)
@@ -407,6 +407,117 @@ class LLDB_API SBProcess {
/// the process isn't loaded from a core file.
lldb::SBFileSpec GetCoreFile();
+ /// \{
+ /// \group Mask Address Methods
+ ///
+ /// \a type
+ /// All of the methods in this group take \a type argument
+ /// which is an AddressMaskType enum value.
+ /// There can be different address masks for code addresses and
+ /// data addresses, this argument can select which to get/set,
+ /// or to use when clearing non-addressable bits from an address.
+ /// On AArch32 code with arm+thumb code, where instructions start
+ /// on even addresses, the 0th bit may be used to indicate that
+ /// a function is thumb code. On such a target, the eAddressMaskTypeCode
+ /// may clear the 0th bit from an address to get the actual address.
+ ///
+ /// \a addr_range
+ /// Many of the methods in this group take an \a addr_range argument
+ /// which is an AddressMaskRange enum value.
+ /// Needing to specify the address range is highly unusual, and the
+ /// default argument can be used in nearly all circumstances.
+ /// On some architectures like AArch64, it is possible to have
+ /// different page table setups for low and high memory, so different
+ /// numbers of bits relevant to addressing. It is possible to have
+ /// a program running in one half of memory and accessing the other
+ /// as heap, so we need to maintain two different sets of address masks
+ /// to debug this correctly.
+
+ /// Get the current address mask that will be applied to addresses
+ /// before reading from memory.
+ ///
+ /// \param[in] type
+ /// See \ref Mask Address Methods descripton of this argument.
+ /// eAddressMaskTypeAny is often a suitable value when code and
+ /// data masks are the same on a given target.
+ ///
+ /// \param[in] addr_range
+ /// See \ref Mask Address Methods descripton of this argument.
+ /// This will default to eAddressMaskRangeLow which is the
+ /// only set of masks used normally.
+ ///
+ /// \return
+ /// The address mask currently in use. Bits which are not used
+ /// for addressing will be set to 1 in the mask.
+ lldb::addr_t GetAddressMask(
+ lldb::AddressMaskType type,
+ lldb::AddressMaskRange addr_range = lldb::eAddressMaskRangeLow);
+
+ /// Set the current address mask that can be applied to addresses
+ /// before reading from memory.
+ ///
+ /// \param[in] type
+ /// See \ref Mask Address Methods descripton of this argument.
+ /// eAddressMaskTypeAll is often a suitable value when the
+ /// same mask is being set for both code and data.
+ ///
+ /// \param[in] mask
+ /// The address mask to set. Bits which are not used for addressing
+ /// should be set to 1 in the mask.
+ ///
+ /// \param[in] addr_range
+ /// See \ref Mask Address Methods descripton of this argument.
+ /// This will default to eAddressMaskRangeLow which is the
+ /// only set of masks used normally.
+ void SetAddressMask(
+ lldb::AddressMaskType type, lldb::addr_t mask,
+ lldb::AddressMaskRange addr_range = lldb::eAddressMaskRangeLow);
+
+ /// Set the number of bits used for addressing in this Process.
+ ///
+ /// In some environments, the number of bits that are used for addressing
+ /// is the natural representation instead of a mask, but lldb
+ /// internally represents this as a mask. This method calculates
+ /// the addressing mask that lldb uses that number of addressable bits.
hawkinsw wrote:
I am not 100% sure what you are attempting to convey here (and it may be
perfectly correct), but I am having a hard time parsing this sentence.
https://github.com/llvm/llvm-project/pull/83095
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add SBProcess methods for get/set/use address masks (PR #83095)
https://github.com/hawkinsw edited https://github.com/llvm/llvm-project/pull/83095 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add SBProcess methods for get/set/use address masks (PR #83095)
@@ -407,6 +407,129 @@ class LLDB_API SBProcess {
/// the process isn't loaded from a core file.
lldb::SBFileSpec GetCoreFile();
+ /// Get the current address mask that can be applied to addresses
+ /// before reading from memory.
+ ///
+ /// \param[in] type
+ /// lldb may have different address masks for code and data
+ /// addresses. Either can be requested, or most commonly,
+ /// eAddressMaskTypeAny can be requested and the least specific
+ /// mask will be fetched. e.g. on a target where instructions
+ /// are word aligned, the Code mask might clear the low 2 bits.
+ ///
+ /// \param[in] addr_range
+ /// Specify whether the address mask for high or low address spaces
+ /// is requested.
+ /// It is highly unusual to have different address masks in high
+ /// or low memory, and by default the eAddressMaskRangeLow is the
+ /// only one used for both types of addresses, the default value for
+ /// this argument is the correct one.
+ ///
+ /// On some architectures like AArch64, it is possible to have
+ /// different page table setups for low and high memory, so different
+ /// numbers of bits relevant to addressing, and it is possible to have
+ /// a program running in one half of memory and accessing the other
+ /// as heap, etc. In that case the eAddressMaskRangeLow and
hawkinsw wrote:
```suggestion
/// as heap, etc. In that case, the eAddressMaskRangeLow and
```
https://github.com/llvm/llvm-project/pull/83095
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add SBProcess methods for get/set/use address masks (PR #83095)
https://github.com/hawkinsw edited https://github.com/llvm/llvm-project/pull/83095 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add SBProcess methods for get/set/use address masks (PR #83095)
@@ -407,6 +407,129 @@ class LLDB_API SBProcess {
/// the process isn't loaded from a core file.
lldb::SBFileSpec GetCoreFile();
+ /// Get the current address mask that can be applied to addresses
+ /// before reading from memory.
+ ///
+ /// \param[in] type
+ /// lldb may have different address masks for code and data
+ /// addresses. Either can be requested, or most commonly,
+ /// eAddressMaskTypeAny can be requested and the least specific
+ /// mask will be fetched. e.g. on a target where instructions
+ /// are word aligned, the Code mask might clear the low 2 bits.
hawkinsw wrote:
```suggestion
/// are word aligned, the code mask might clear the low 2 bits.
```
https://github.com/llvm/llvm-project/pull/83095
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add SBProcess methods for get/set/use address masks (PR #83095)
https://github.com/hawkinsw commented: I really appreciate the thorough documentation you wrote for these new functions. Because there is so much overlap in the documentation between the functions, could we refactor it somehow (not sure how?) so that any future change could be more easily tracked? Just a question. Again, I appreciate your thorough documentation! Will https://github.com/llvm/llvm-project/pull/83095 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Use PyBytes and PyByteArray in Python Data Objects unittest (PR #82098)
hawkinsw wrote: > Use a Python Bytes and ByteArray object instead of Integers for > TestOwnedReferences and TestBorrowedReferences. These two tests were failing > when building against Python 3.12 because these Integer objects had a > refcount of 4294967296 (-1). I didn't dig into it, but I suspect the Python > runtime has adopted an optimization to decrease refcounting traffic for these > simple objects. Perhaps related to ... https://github.com/python/cpython/pull/30872/files#diff-1a6e70e2beeecad88840c67284ac4d54a36998029244771fcc820e801390726a I was curious and investigated. Whether that is the *exact* change, it seems to confirm your hypothesis that there is special refcounting code for certain types of Python objects. Would you agree with that? I hope that helps! https://github.com/llvm/llvm-project/pull/82098 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Support statistics dump summary only mode (PR #80745)
@@ -74,7 +75,7 @@ json::Value ModuleStats::ToJSON() const {
if (!symfile_modules.empty()) {
json::Array symfile_ids;
-for (const auto symfile_id: symfile_modules)
+for (const auto symfile_id : symfile_modules)
hawkinsw wrote:
Is this just a whitespace change?
https://github.com/llvm/llvm-project/pull/80745
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Support statistics dump summary only mode (PR #80745)
@@ -100,60 +101,91 @@ llvm::json::Value ConstStringStats::ToJSON() const {
return obj;
}
-json::Value TargetStats::ToJSON(Target &target) {
- CollectStats(target);
+json::Value TargetStats::ToJSON(Target &target, bool summary_only) {
+ json::Object target_metrics_json;
+ ProcessSP process_sp = target.GetProcessSP();
+ if (!summary_only) {
+CollectStats(target);
- json::Array json_module_uuid_array;
- for (auto module_identifier : m_module_identifiers)
-json_module_uuid_array.emplace_back(module_identifier);
+json::Array json_module_uuid_array;
+for (auto module_identifier : m_module_identifiers)
+ json_module_uuid_array.emplace_back(module_identifier);
- json::Object target_metrics_json{
- {m_expr_eval.name, m_expr_eval.ToJSON()},
- {m_frame_var.name, m_frame_var.ToJSON()},
- {"moduleIdentifiers", std::move(json_module_uuid_array)}};
+target_metrics_json.try_emplace(m_expr_eval.name, m_expr_eval.ToJSON());
+target_metrics_json.try_emplace(m_frame_var.name, m_frame_var.ToJSON());
+target_metrics_json.try_emplace("moduleIdentifiers",
+std::move(json_module_uuid_array));
- if (m_launch_or_attach_time && m_first_private_stop_time) {
-double elapsed_time =
-elapsed(*m_launch_or_attach_time, *m_first_private_stop_time);
-target_metrics_json.try_emplace("launchOrAttachTime", elapsed_time);
- }
- if (m_launch_or_attach_time && m_first_public_stop_time) {
-double elapsed_time =
-elapsed(*m_launch_or_attach_time, *m_first_public_stop_time);
-target_metrics_json.try_emplace("firstStopTime", elapsed_time);
+if (m_launch_or_attach_time && m_first_private_stop_time) {
+ double elapsed_time =
+ elapsed(*m_launch_or_attach_time, *m_first_private_stop_time);
+ target_metrics_json.try_emplace("launchOrAttachTime", elapsed_time);
+}
+if (m_launch_or_attach_time && m_first_public_stop_time) {
+ double elapsed_time =
+ elapsed(*m_launch_or_attach_time, *m_first_public_stop_time);
+ target_metrics_json.try_emplace("firstStopTime", elapsed_time);
+}
+target_metrics_json.try_emplace("targetCreateTime",
+m_create_time.get().count());
+
+json::Array breakpoints_array;
+double totalBreakpointResolveTime = 0.0;
+// Rport both the normal breakpoint list and the internal breakpoint list.
hawkinsw wrote:
```suggestion
// Report both the normal breakpoint list and the internal breakpoint list.
```
https://github.com/llvm/llvm-project/pull/80745
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Support statistics dump summary only mode (PR #80745)
@@ -186,6 +186,10 @@ class SymbolFileDWARF : public SymbolFileCommon {
GetMangledNamesForFunction(const std::string &scope_qualified_name,
std::vector &mangled_names) override;
+ // Return total currently loaded debug info
hawkinsw wrote:
```suggestion
// Return total currently loaded debug info.
```
https://github.com/llvm/llvm-project/pull/80745
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Support statistics dump summary only mode (PR #80745)
@@ -1412,4 +1412,7 @@ let Command = "trace schema" in {
let Command = "statistics dump" in {
def statistics_dump_all: Option<"all-targets", "a">, Group<1>,
Desc<"Include statistics for all targets.">;
+ def statistics_dump_summary: Option<"summary", "s">, Group<1>,
+Desc<"Dump only high level summary statistics."
+ "Exclude targets, modules, breakpoints etc.. details.">;
hawkinsw wrote:
```suggestion
"Exclude targets, modules, breakpoints etc... details.">;
```
https://github.com/llvm/llvm-project/pull/80745
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Support statistics dump summary only mode (PR #80745)
@@ -1412,4 +1412,7 @@ let Command = "trace schema" in {
let Command = "statistics dump" in {
def statistics_dump_all: Option<"all-targets", "a">, Group<1>,
Desc<"Include statistics for all targets.">;
+ def statistics_dump_summary: Option<"summary", "s">, Group<1>,
+Desc<"Dump only high level summary statistics."
hawkinsw wrote:
```suggestion
Desc<"Dump only high-level summary statistics."
```
https://github.com/llvm/llvm-project/pull/80745
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Support statistics dump summary only mode (PR #80745)
https://github.com/hawkinsw commented: Thank you for doing this! I hope that these little nits are helpful! https://github.com/llvm/llvm-project/pull/80745 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Support statistics dump summary only mode (PR #80745)
https://github.com/hawkinsw edited https://github.com/llvm/llvm-project/pull/80745 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Clean up PlatformDarwinKernel::GetSharedModule, document (PR #78652)
https://github.com/hawkinsw edited https://github.com/llvm/llvm-project/pull/78652 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Clean up PlatformDarwinKernel::GetSharedModule, document (PR #78652)
@@ -836,36 +834,18 @@ Status PlatformDarwinKernel::GetSharedModuleKernel(
module_sp.reset(new Module(kern_spec));
if (module_sp && module_sp->GetObjectFile() &&
module_sp->MatchesModuleSpec(kern_spec)) {
-// module_sp is an actual kernel binary we want to add.
-if (process) {
- const bool notify = false;
- process->GetTarget().GetImages().AppendIfNeeded(module_sp, notify);
- error.Clear();
- return error;
-} else {
- error = ModuleList::GetSharedModule(kern_spec, module_sp, nullptr,
- nullptr, nullptr);
- if (module_sp && module_sp->GetObjectFile() &&
- module_sp->GetObjectFile()->GetType() !=
- ObjectFile::Type::eTypeCoreFile) {
-return error;
- }
- module_sp.reset();
-}
+if (did_create_ptr)
+ *did_create_ptr = true;
+return {};
}
}
}
// Give the generic methods, including possibly calling into DebugSymbols
// framework on macOS systems, a chance.
- error = PlatformDarwin::GetSharedModule(module_spec, process, module_sp,
- module_search_paths_ptr, old_modules,
- did_create_ptr);
- if (error.Success() && module_sp.get()) {
-return error;
- }
-
- return error;
+ return PlatformDarwin::GetSharedModule(module_spec, process, module_sp,
hawkinsw wrote:
Sorry to follow up again, @jasonmolenda, but I think that putting an assert at
the top of `PlatformDarwin::GetSharedModule` might have exposed the curiosity
that I am thinking about ...
Let's say that we are on the last iteration of this loop:
```C++
// First try all kernel binaries that have a dSYM next to them
for (auto possible_kernel : m_kernel_binaries_with_dsyms) {
if (FileSystem::Instance().Exists(possible_kernel)) {
ModuleSpec kern_spec(possible_kernel);
kern_spec.GetUUID() = module_spec.GetUUID();
module_sp.reset(new Module(kern_spec));
```
`module_sp` is `reset` to point to a pointer to a new instantiation of a
`Module`. Further, assume that
```C++
(module_sp && module_sp->GetObjectFile() &&
module_sp->MatchesModuleSpec(kern_spec))
```
is not true. That means that we fall out of that loop and `module_sp` still
points to an instance of a `Module`. We proceed to the next loop and, for the
sake of argument, let's say that `objfile_names` contains 0 entries for every
`possible_kernel_dsym`. Effectively, then, there will be no iterations of that
second loop.
As a result, control will pass to `PlatformDarwin::GetSharedModule` with
`module_sp` pointing to a leftover instance of a `Module` from the last
iteration of the first loop. And, if you had an assertion that `module_sp` does
not point to anything instead of a reset as the first operation in
`PlatformDarwin::GetSharedModule` then it would certainly fail.
It seems like it should be that we reset `module_sp` before doing "the next"
iteration on both of the loops in the function. I am sorry if it seems like I
am being hard headed. I am just trying to understand and help!
Thank you for your time!!
https://github.com/llvm/llvm-project/pull/78652
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Clean up PlatformDarwinKernel::GetSharedModule, document (PR #78652)
@@ -836,36 +834,18 @@ Status PlatformDarwinKernel::GetSharedModuleKernel(
module_sp.reset(new Module(kern_spec));
if (module_sp && module_sp->GetObjectFile() &&
module_sp->MatchesModuleSpec(kern_spec)) {
-// module_sp is an actual kernel binary we want to add.
-if (process) {
- const bool notify = false;
- process->GetTarget().GetImages().AppendIfNeeded(module_sp, notify);
- error.Clear();
- return error;
-} else {
- error = ModuleList::GetSharedModule(kern_spec, module_sp, nullptr,
- nullptr, nullptr);
- if (module_sp && module_sp->GetObjectFile() &&
- module_sp->GetObjectFile()->GetType() !=
- ObjectFile::Type::eTypeCoreFile) {
-return error;
- }
- module_sp.reset();
-}
+if (did_create_ptr)
+ *did_create_ptr = true;
+return {};
}
}
}
// Give the generic methods, including possibly calling into DebugSymbols
// framework on macOS systems, a chance.
- error = PlatformDarwin::GetSharedModule(module_spec, process, module_sp,
- module_search_paths_ptr, old_modules,
- did_create_ptr);
- if (error.Success() && module_sp.get()) {
-return error;
- }
-
- return error;
+ return PlatformDarwin::GetSharedModule(module_spec, process, module_sp,
hawkinsw wrote:
Of course! Now that I looked at the signature and saw that `module_sp` is
passed by reference, we assume that it will go out of the caller's scope (or
the caller's, caller's scope ...) at some point and the "leaked" instance of
`Module` would be cleaned up then!
Thank you for the explanation.
It just seemed odd to have that contain a pointer at all at that point in the
code because the point of calling `PlatformDarwin::GetSharedModule` is that a
valid one was not found. I.e., if the condition on lines 805/806 was false, it
seemed to me that "A Module that matches the ModuleSpec" was *not* actually
found and so `module_sp` should have been reset before either falling out of
the loop or going to the next iteration.
Thank you again for the explanation!
https://github.com/llvm/llvm-project/pull/78652
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Clean up PlatformDarwinKernel::GetSharedModule, document (PR #78652)
@@ -836,36 +834,18 @@ Status PlatformDarwinKernel::GetSharedModuleKernel(
module_sp.reset(new Module(kern_spec));
if (module_sp && module_sp->GetObjectFile() &&
module_sp->MatchesModuleSpec(kern_spec)) {
-// module_sp is an actual kernel binary we want to add.
-if (process) {
- const bool notify = false;
- process->GetTarget().GetImages().AppendIfNeeded(module_sp, notify);
- error.Clear();
- return error;
-} else {
- error = ModuleList::GetSharedModule(kern_spec, module_sp, nullptr,
- nullptr, nullptr);
- if (module_sp && module_sp->GetObjectFile() &&
- module_sp->GetObjectFile()->GetType() !=
- ObjectFile::Type::eTypeCoreFile) {
-return error;
- }
- module_sp.reset();
-}
+if (did_create_ptr)
+ *did_create_ptr = true;
+return {};
}
}
}
// Give the generic methods, including possibly calling into DebugSymbols
// framework on macOS systems, a chance.
- error = PlatformDarwin::GetSharedModule(module_spec, process, module_sp,
- module_search_paths_ptr, old_modules,
- did_create_ptr);
- if (error.Success() && module_sp.get()) {
-return error;
- }
-
- return error;
+ return PlatformDarwin::GetSharedModule(module_spec, process, module_sp,
hawkinsw wrote:
I am *sure* that this is a dumb question, so forgive me ...
It seems like we can end up here with a "useless" pointer to an instance of
`Module` in `module_sp`. Fortunately, the first thing that
`PlatformDarwin::GetSharedModule` does is to reset that pointer which means
that there is no leak. However, would it make sense to do a `reset` before
calling just in case the code in that function changes in the future?
Again, I apologize if this is a stupid question!
https://github.com/llvm/llvm-project/pull/78652
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Make only one function that needs to be implemented when searching for types (PR #74786)
@@ -45,6 +66,286 @@ struct CompilerContext {
bool contextMatches(llvm::ArrayRef context_chain,
llvm::ArrayRef pattern);
+FLAGS_ENUM(TypeQueryOptions){
+e_none = 0u,
+/// If set TypeQuery::m_context contains an exact context that must match
+/// the full context. If not set TypeQuery::m_context can contain a partial
+/// type match where the full context isn't fully specified.
+e_exact_match = (1u << 0),
+/// If set, TypeQuery::m_context is a clang module compiler context. If not
+/// set TypeQuery::m_context is normal type lookup context.
+e_module_search = (1u << 1),
+/// When true, the find types call should stop the query as soon as a
single
+/// matching type is found. When false, the type query should find all
+/// matching types.
+e_find_one = (1u << 2),
+};
+LLDB_MARK_AS_BITMASK_ENUM(TypeQueryOptions)
+
+/// A class that contains all state required for type lookups.
+///
+/// Using a TypeQuery class for matching types simplifies the internal APIs we
+/// need to implement type lookups in LLDB. Type lookups can fully specify the
+/// exact typename by filling out a complete or partial CompilerContext array.
+/// This allows for powerful searches and also allows the SymbolFile classes to
+/// use the m_context array to lookup types by basename, then eliminate
+/// potential matches without having to resolve types into each TypeSystem.
This
+/// makes type lookups vastly more efficient and allows the SymbolFile objects
+/// to stop looking up types when the type matching is complete, like if we are
+/// looking for only a single type in our search.
+class TypeQuery {
+public:
+ TypeQuery() = delete;
+
+ /// Construct a type match object using a fully or partially qualified name.
+ ///
+ /// The specified \a type_name will be chopped up and the m_context will be
+ /// populated by separating the string by looking for "::". We do this
because
+ /// symbol files have indexes that contain only the type's basename. This
also
+ /// allows symbol files to efficiently not realize types that don't match the
+ /// specified context. Example of \a type_name values that can be specified
+ /// include:
+ /// "foo": Look for any type whose basename matches "foo".
+ /// If \a exact_match is true, then the type can't be contained in any
+ /// declaration context like a namespace, class, or other containing
+ /// scope.
+ /// If \a exact match is false, then we will find all matches including
+ /// ones that are contained in other declaration contexts, including top
+ /// level types.
+ /// "foo::bar": Look for any type whose basename matches "bar" but make
sure
+ /// its parent declaration context is any named declaration context
+ /// (namespace, class, struct, etc) whose name matches "foo".
+ /// If \a exact_match is true, then the "foo" declaration context must
+ /// appear at the source file level or inside of a function.
+ /// If \a exact match is false, then the "foo" declaration context can
+ /// be contained in any other declaration contexts.
+ /// "class foo": Only match types that are classes whose basename matches
+ /// "foo".
+ /// "struct foo": Only match types that are structures whose basename
+ /// matches "foo".
+ /// "class foo::bar": Only match types that are classes whose basename
+ /// matches "bar" and that are contained in any named declaration context
+ /// named "foo".
+ ///
+ /// \param[in] type_name
+ /// A fully or partially qualified type name. This name will be parsed and
hawkinsw wrote:
```suggestion
/// A fully- or partially-qualified type name. This name will be parsed and
```
https://github.com/llvm/llvm-project/pull/74786
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Make only one function that needs to be implemented when searching for types (PR #74786)
@@ -45,6 +66,286 @@ struct CompilerContext {
bool contextMatches(llvm::ArrayRef context_chain,
llvm::ArrayRef pattern);
+FLAGS_ENUM(TypeQueryOptions){
+e_none = 0u,
+/// If set TypeQuery::m_context contains an exact context that must match
+/// the full context. If not set TypeQuery::m_context can contain a partial
+/// type match where the full context isn't fully specified.
+e_exact_match = (1u << 0),
+/// If set, TypeQuery::m_context is a clang module compiler context. If not
+/// set TypeQuery::m_context is normal type lookup context.
+e_module_search = (1u << 1),
+/// When true, the find types call should stop the query as soon as a
single
+/// matching type is found. When false, the type query should find all
+/// matching types.
+e_find_one = (1u << 2),
+};
+LLDB_MARK_AS_BITMASK_ENUM(TypeQueryOptions)
+
+/// A class that contains all state required for type lookups.
+///
+/// Using a TypeQuery class for matching types simplifies the internal APIs we
+/// need to implement type lookups in LLDB. Type lookups can fully specify the
+/// exact typename by filling out a complete or partial CompilerContext array.
+/// This allows for powerful searches and also allows the SymbolFile classes to
+/// use the m_context array to lookup types by basename, then eliminate
+/// potential matches without having to resolve types into each TypeSystem.
This
+/// makes type lookups vastly more efficient and allows the SymbolFile objects
+/// to stop looking up types when the type matching is complete, like if we are
+/// looking for only a single type in our search.
+class TypeQuery {
+public:
+ TypeQuery() = delete;
+
+ /// Construct a type match object using a fully or partially qualified name.
+ ///
+ /// The specified \a type_name will be chopped up and the m_context will be
+ /// populated by separating the string by looking for "::". We do this
because
+ /// symbol files have indexes that contain only the type's basename. This
also
+ /// allows symbol files to efficiently not realize types that don't match the
+ /// specified context. Example of \a type_name values that can be specified
+ /// include:
+ /// "foo": Look for any type whose basename matches "foo".
+ /// If \a exact_match is true, then the type can't be contained in any
+ /// declaration context like a namespace, class, or other containing
+ /// scope.
+ /// If \a exact match is false, then we will find all matches including
+ /// ones that are contained in other declaration contexts, including top
+ /// level types.
+ /// "foo::bar": Look for any type whose basename matches "bar" but make
sure
+ /// its parent declaration context is any named declaration context
+ /// (namespace, class, struct, etc) whose name matches "foo".
+ /// If \a exact_match is true, then the "foo" declaration context must
+ /// appear at the source file level or inside of a function.
+ /// If \a exact match is false, then the "foo" declaration context can
+ /// be contained in any other declaration contexts.
+ /// "class foo": Only match types that are classes whose basename matches
+ /// "foo".
+ /// "struct foo": Only match types that are structures whose basename
+ /// matches "foo".
+ /// "class foo::bar": Only match types that are classes whose basename
+ /// matches "bar" and that are contained in any named declaration context
+ /// named "foo".
+ ///
+ /// \param[in] type_name
+ /// A fully or partially qualified type name. This name will be parsed and
+ /// broken up and the m_context will be populated with the various parts of
+ /// the name. This typename can be prefixed with "struct ", "class ",
+ /// "union", "enum " or "typedef " before the actual type name to limit the
+ /// results of the types that match. The declaration context can be
+ /// specified with the "::" string. like "a::b::my_type".
hawkinsw wrote:
```suggestion
/// specified with the "::" string. For example, "a::b::my_type".
```
https://github.com/llvm/llvm-project/pull/74786
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Make only one function that needs to be implemented when searching for types (PR #74786)
@@ -45,6 +66,286 @@ struct CompilerContext {
bool contextMatches(llvm::ArrayRef context_chain,
llvm::ArrayRef pattern);
+FLAGS_ENUM(TypeQueryOptions){
+e_none = 0u,
+/// If set TypeQuery::m_context contains an exact context that must match
+/// the full context. If not set TypeQuery::m_context can contain a partial
+/// type match where the full context isn't fully specified.
+e_exact_match = (1u << 0),
+/// If set, TypeQuery::m_context is a clang module compiler context. If not
+/// set TypeQuery::m_context is normal type lookup context.
+e_module_search = (1u << 1),
+/// When true, the find types call should stop the query as soon as a
single
+/// matching type is found. When false, the type query should find all
+/// matching types.
+e_find_one = (1u << 2),
+};
+LLDB_MARK_AS_BITMASK_ENUM(TypeQueryOptions)
+
+/// A class that contains all state required for type lookups.
+///
+/// Using a TypeQuery class for matching types simplifies the internal APIs we
+/// need to implement type lookups in LLDB. Type lookups can fully specify the
+/// exact typename by filling out a complete or partial CompilerContext array.
+/// This allows for powerful searches and also allows the SymbolFile classes to
+/// use the m_context array to lookup types by basename, then eliminate
+/// potential matches without having to resolve types into each TypeSystem.
This
+/// makes type lookups vastly more efficient and allows the SymbolFile objects
+/// to stop looking up types when the type matching is complete, like if we are
+/// looking for only a single type in our search.
+class TypeQuery {
+public:
+ TypeQuery() = delete;
+
+ /// Construct a type match object using a fully or partially qualified name.
+ ///
+ /// The specified \a type_name will be chopped up and the m_context will be
+ /// populated by separating the string by looking for "::". We do this
because
+ /// symbol files have indexes that contain only the type's basename. This
also
+ /// allows symbol files to efficiently not realize types that don't match the
+ /// specified context. Example of \a type_name values that can be specified
+ /// include:
+ /// "foo": Look for any type whose basename matches "foo".
+ /// If \a exact_match is true, then the type can't be contained in any
+ /// declaration context like a namespace, class, or other containing
+ /// scope.
+ /// If \a exact match is false, then we will find all matches including
+ /// ones that are contained in other declaration contexts, including top
+ /// level types.
+ /// "foo::bar": Look for any type whose basename matches "bar" but make
sure
+ /// its parent declaration context is any named declaration context
+ /// (namespace, class, struct, etc) whose name matches "foo".
+ /// If \a exact_match is true, then the "foo" declaration context must
+ /// appear at the source file level or inside of a function.
+ /// If \a exact match is false, then the "foo" declaration context can
+ /// be contained in any other declaration contexts.
+ /// "class foo": Only match types that are classes whose basename matches
+ /// "foo".
+ /// "struct foo": Only match types that are structures whose basename
+ /// matches "foo".
+ /// "class foo::bar": Only match types that are classes whose basename
+ /// matches "bar" and that are contained in any named declaration context
+ /// named "foo".
+ ///
+ /// \param[in] type_name
+ /// A fully or partially qualified type name. This name will be parsed and
+ /// broken up and the m_context will be populated with the various parts of
+ /// the name. This typename can be prefixed with "struct ", "class ",
+ /// "union", "enum " or "typedef " before the actual type name to limit the
+ /// results of the types that match. The declaration context can be
+ /// specified with the "::" string. like "a::b::my_type".
+ ///
+ /// \param[in] options A set of boolean enumeration flags from the
+ /// TypeQueryOptions enumerations. \see TypeQueryOptions.
+ TypeQuery(llvm::StringRef name, TypeQueryOptions options = e_none);
+
+ /// Construct a type match object that matches a type basename that exists
+ /// in the specified declaration context.
+ ///
+ /// This allows the m_context to be first populated using a declaration
+ /// context to exactly identify the containing declaration context of a type.
+ /// This can be used when you have a forward declaration to a type and you
+ /// need to search for its complete type.
+ ///
+ /// \param[in] decl_ctx
+ /// A declaration context object that comes from a TypeSystem plug-in. This
+ /// object will be asked to full the array of CompilerContext objects
hawkinsw wrote:
Seems like we are missing a word here.
https://github.com/llvm/llvm-project/pull/74786
___
[Lldb-commits] [lldb] Make only one function that needs to be implemented when searching for types (PR #74786)
https://github.com/hawkinsw commented: Thank you for the great work. I really appreciate the excellent documentation that you wrote. I am not well versed enough in the code to comment on the implementation, but your comments were so good that I intuitively understood the point of the new classes. I hope that some of these suggestions are helpful. Again, these are suggestions and you should not feel like you are under any obligation to accept them. Thanks for the great work! https://github.com/llvm/llvm-project/pull/74786 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Make only one function that needs to be implemented when searching for types (PR #74786)
@@ -45,6 +66,286 @@ struct CompilerContext {
bool contextMatches(llvm::ArrayRef context_chain,
llvm::ArrayRef pattern);
+FLAGS_ENUM(TypeQueryOptions){
+e_none = 0u,
+/// If set TypeQuery::m_context contains an exact context that must match
+/// the full context. If not set TypeQuery::m_context can contain a partial
hawkinsw wrote:
```suggestion
/// the full context. If not set, TypeQuery::m_context can contain a partial
```
https://github.com/llvm/llvm-project/pull/74786
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Make only one function that needs to be implemented when searching for types (PR #74786)
@@ -56,6 +57,13 @@ class CompilerDeclContext {
return m_type_system != nullptr && m_opaque_decl_ctx != nullptr;
}
+ /// Populate a valid compiler context from the current decl context.
+ ///
+ /// \returns A valid vector of CompilerContext entries that describes
+ /// this declaration context. The first entry in the vector is the parent of
+ /// the subsequent entry, so the top most entry is the global namespace.
hawkinsw wrote:
```suggestion
/// the subsequent entry, so the topmost entry is the global namespace.
```
https://github.com/llvm/llvm-project/pull/74786
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Make only one function that needs to be implemented when searching for types (PR #74786)
@@ -45,6 +66,286 @@ struct CompilerContext {
bool contextMatches(llvm::ArrayRef context_chain,
llvm::ArrayRef pattern);
+FLAGS_ENUM(TypeQueryOptions){
+e_none = 0u,
+/// If set TypeQuery::m_context contains an exact context that must match
+/// the full context. If not set TypeQuery::m_context can contain a partial
+/// type match where the full context isn't fully specified.
+e_exact_match = (1u << 0),
+/// If set, TypeQuery::m_context is a clang module compiler context. If not
+/// set TypeQuery::m_context is normal type lookup context.
+e_module_search = (1u << 1),
+/// When true, the find types call should stop the query as soon as a
single
+/// matching type is found. When false, the type query should find all
+/// matching types.
+e_find_one = (1u << 2),
+};
+LLDB_MARK_AS_BITMASK_ENUM(TypeQueryOptions)
+
+/// A class that contains all state required for type lookups.
+///
+/// Using a TypeQuery class for matching types simplifies the internal APIs we
+/// need to implement type lookups in LLDB. Type lookups can fully specify the
+/// exact typename by filling out a complete or partial CompilerContext array.
+/// This allows for powerful searches and also allows the SymbolFile classes to
+/// use the m_context array to lookup types by basename, then eliminate
+/// potential matches without having to resolve types into each TypeSystem.
This
+/// makes type lookups vastly more efficient and allows the SymbolFile objects
+/// to stop looking up types when the type matching is complete, like if we are
+/// looking for only a single type in our search.
+class TypeQuery {
+public:
+ TypeQuery() = delete;
+
+ /// Construct a type match object using a fully or partially qualified name.
+ ///
+ /// The specified \a type_name will be chopped up and the m_context will be
+ /// populated by separating the string by looking for "::". We do this
because
+ /// symbol files have indexes that contain only the type's basename. This
also
+ /// allows symbol files to efficiently not realize types that don't match the
+ /// specified context. Example of \a type_name values that can be specified
+ /// include:
+ /// "foo": Look for any type whose basename matches "foo".
+ /// If \a exact_match is true, then the type can't be contained in any
+ /// declaration context like a namespace, class, or other containing
+ /// scope.
+ /// If \a exact match is false, then we will find all matches including
+ /// ones that are contained in other declaration contexts, including top
+ /// level types.
+ /// "foo::bar": Look for any type whose basename matches "bar" but make
sure
+ /// its parent declaration context is any named declaration context
+ /// (namespace, class, struct, etc) whose name matches "foo".
+ /// If \a exact_match is true, then the "foo" declaration context must
+ /// appear at the source file level or inside of a function.
+ /// If \a exact match is false, then the "foo" declaration context can
+ /// be contained in any other declaration contexts.
+ /// "class foo": Only match types that are classes whose basename matches
+ /// "foo".
+ /// "struct foo": Only match types that are structures whose basename
+ /// matches "foo".
+ /// "class foo::bar": Only match types that are classes whose basename
+ /// matches "bar" and that are contained in any named declaration context
+ /// named "foo".
+ ///
+ /// \param[in] type_name
+ /// A fully or partially qualified type name. This name will be parsed and
+ /// broken up and the m_context will be populated with the various parts of
+ /// the name. This typename can be prefixed with "struct ", "class ",
+ /// "union", "enum " or "typedef " before the actual type name to limit the
+ /// results of the types that match. The declaration context can be
+ /// specified with the "::" string. like "a::b::my_type".
+ ///
+ /// \param[in] options A set of boolean enumeration flags from the
+ /// TypeQueryOptions enumerations. \see TypeQueryOptions.
+ TypeQuery(llvm::StringRef name, TypeQueryOptions options = e_none);
+
+ /// Construct a type match object that matches a type basename that exists
hawkinsw wrote:
```suggestion
/// Construct a type-match object that matches a type basename that exists
```
https://github.com/llvm/llvm-project/pull/74786
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Make only one function that needs to be implemented when searching for types (PR #74786)
@@ -45,6 +66,286 @@ struct CompilerContext {
bool contextMatches(llvm::ArrayRef context_chain,
llvm::ArrayRef pattern);
+FLAGS_ENUM(TypeQueryOptions){
+e_none = 0u,
+/// If set TypeQuery::m_context contains an exact context that must match
+/// the full context. If not set TypeQuery::m_context can contain a partial
+/// type match where the full context isn't fully specified.
+e_exact_match = (1u << 0),
+/// If set, TypeQuery::m_context is a clang module compiler context. If not
+/// set TypeQuery::m_context is normal type lookup context.
+e_module_search = (1u << 1),
+/// When true, the find types call should stop the query as soon as a
single
+/// matching type is found. When false, the type query should find all
+/// matching types.
+e_find_one = (1u << 2),
+};
+LLDB_MARK_AS_BITMASK_ENUM(TypeQueryOptions)
+
+/// A class that contains all state required for type lookups.
+///
+/// Using a TypeQuery class for matching types simplifies the internal APIs we
+/// need to implement type lookups in LLDB. Type lookups can fully specify the
+/// exact typename by filling out a complete or partial CompilerContext array.
+/// This allows for powerful searches and also allows the SymbolFile classes to
+/// use the m_context array to lookup types by basename, then eliminate
+/// potential matches without having to resolve types into each TypeSystem.
This
+/// makes type lookups vastly more efficient and allows the SymbolFile objects
+/// to stop looking up types when the type matching is complete, like if we are
+/// looking for only a single type in our search.
+class TypeQuery {
+public:
+ TypeQuery() = delete;
+
+ /// Construct a type match object using a fully or partially qualified name.
+ ///
+ /// The specified \a type_name will be chopped up and the m_context will be
+ /// populated by separating the string by looking for "::". We do this
because
+ /// symbol files have indexes that contain only the type's basename. This
also
+ /// allows symbol files to efficiently not realize types that don't match the
+ /// specified context. Example of \a type_name values that can be specified
+ /// include:
+ /// "foo": Look for any type whose basename matches "foo".
+ /// If \a exact_match is true, then the type can't be contained in any
+ /// declaration context like a namespace, class, or other containing
+ /// scope.
+ /// If \a exact match is false, then we will find all matches including
+ /// ones that are contained in other declaration contexts, including top
+ /// level types.
+ /// "foo::bar": Look for any type whose basename matches "bar" but make
sure
+ /// its parent declaration context is any named declaration context
+ /// (namespace, class, struct, etc) whose name matches "foo".
+ /// If \a exact_match is true, then the "foo" declaration context must
+ /// appear at the source file level or inside of a function.
+ /// If \a exact match is false, then the "foo" declaration context can
+ /// be contained in any other declaration contexts.
+ /// "class foo": Only match types that are classes whose basename matches
+ /// "foo".
+ /// "struct foo": Only match types that are structures whose basename
+ /// matches "foo".
+ /// "class foo::bar": Only match types that are classes whose basename
+ /// matches "bar" and that are contained in any named declaration context
+ /// named "foo".
+ ///
+ /// \param[in] type_name
+ /// A fully or partially qualified type name. This name will be parsed and
+ /// broken up and the m_context will be populated with the various parts of
+ /// the name. This typename can be prefixed with "struct ", "class ",
+ /// "union", "enum " or "typedef " before the actual type name to limit the
+ /// results of the types that match. The declaration context can be
+ /// specified with the "::" string. like "a::b::my_type".
+ ///
+ /// \param[in] options A set of boolean enumeration flags from the
+ /// TypeQueryOptions enumerations. \see TypeQueryOptions.
+ TypeQuery(llvm::StringRef name, TypeQueryOptions options = e_none);
+
+ /// Construct a type match object that matches a type basename that exists
+ /// in the specified declaration context.
+ ///
+ /// This allows the m_context to be first populated using a declaration
+ /// context to exactly identify the containing declaration context of a type.
+ /// This can be used when you have a forward declaration to a type and you
+ /// need to search for its complete type.
+ ///
+ /// \param[in] decl_ctx
+ /// A declaration context object that comes from a TypeSystem plug-in. This
+ /// object will be asked to full the array of CompilerContext objects
+ /// by adding the top most declaration context first into the array and
then
+ /// adding any containing declaration contexts.
+ ///
+ /// \param[
[Lldb-commits] [lldb] Make only one function that needs to be implemented when searching for types (PR #74786)
@@ -415,70 +415,19 @@ class Module : public std::enable_shared_from_this, void FindGlobalVariables(const RegularExpression ®ex, size_t max_matches, VariableList &variable_list); - /// Find types by name. - /// - /// Type lookups in modules go through the SymbolFile. The SymbolFile needs to - /// be able to lookup types by basename and not the fully qualified typename. - /// This allows the type accelerator tables to stay small, even with heavily - /// templatized C++. The type search will then narrow down the search - /// results. If "exact_match" is true, then the type search will only match - /// exact type name matches. If "exact_match" is false, the type will match - /// as long as the base typename matches and as long as any immediate - /// containing namespaces/class scopes that are specified match. So to - /// search for a type "d" in "b::c", the name "b::c::d" can be specified and - /// it will match any class/namespace "b" which contains a class/namespace - /// "c" which contains type "d". We do this to allow users to not always - /// have to specify complete scoping on all expressions, but it also allows - /// for exact matching when required. - /// - /// \param[in] type_name - /// The name of the type we are looking for that is a fully - /// or partially qualified type name. - /// - /// \param[in] exact_match - /// If \b true, \a type_name is fully qualified and must match - /// exactly. If \b false, \a type_name is a partially qualified - /// name where the leading namespaces or classes can be - /// omitted to make finding types that a user may type - /// easier. - /// - /// \param[out] types - /// A type list gets populated with any matches. + /// Find types using a type matching object that contains all search + /// parameters. /// - void - FindTypes(ConstString type_name, bool exact_match, size_t max_matches, -llvm::DenseSet &searched_symbol_files, -TypeList &types); - - /// Find types by name. - /// - /// This behaves like the other FindTypes method but allows to - /// specify a DeclContext and a language for the type being searched - /// for. - /// - /// \param searched_symbol_files - /// Prevents one file from being visited multiple times. - void - FindTypes(llvm::ArrayRef pattern, LanguageSet languages, -llvm::DenseSet &searched_symbol_files, -TypeMap &types); - - lldb::TypeSP FindFirstType(const SymbolContext &sc, ConstString type_name, - bool exact_match); - - /// Find types by name that are in a namespace. This function is used by the - /// expression parser when searches need to happen in an exact namespace - /// scope. + /// \see lldb_private::TypeQuery /// - /// \param[in] type_name - /// The name of a type within a namespace that should not include - /// any qualifying namespaces (just a type basename). + /// \param[in] query + /// A type matching object that contains all of the details of the type hawkinsw wrote: ```suggestion /// A type-matching object that contains all of the details of the type ``` https://github.com/llvm/llvm-project/pull/74786 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Make only one function that needs to be implemented when searching for types (PR #74786)
@@ -45,6 +66,286 @@ struct CompilerContext {
bool contextMatches(llvm::ArrayRef context_chain,
llvm::ArrayRef pattern);
+FLAGS_ENUM(TypeQueryOptions){
+e_none = 0u,
+/// If set TypeQuery::m_context contains an exact context that must match
hawkinsw wrote:
```suggestion
/// If set, TypeQuery::m_context contains an exact context that must match
```
https://github.com/llvm/llvm-project/pull/74786
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Make only one function that needs to be implemented when searching for types (PR #74786)
@@ -301,21 +301,20 @@ class SymbolFile : public PluginInterface {
bool include_inlines, SymbolContextList &sc_list);
virtual void FindFunctions(const RegularExpression ®ex,
bool include_inlines, SymbolContextList &sc_list);
- virtual void
- FindTypes(ConstString name, const CompilerDeclContext &parent_decl_ctx,
-uint32_t max_matches,
-llvm::DenseSet &searched_symbol_files,
-TypeMap &types);
-
- /// Find types specified by a CompilerContextPattern.
- /// \param languages
- /// Only return results in these languages.
- /// \param searched_symbol_files
- /// Prevents one file from being visited multiple times.
- virtual void
- FindTypes(llvm::ArrayRef pattern, LanguageSet languages,
-llvm::DenseSet &searched_symbol_files,
-TypeMap &types);
+
+ /// Find types using a type matching object that contains all search
hawkinsw wrote:
```suggestion
/// Find types using a type-matching object that contains all search
```
https://github.com/llvm/llvm-project/pull/74786
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Make only one function that needs to be implemented when searching for types (PR #74786)
@@ -84,6 +84,13 @@ class CompilerDecl {
// based argument index
CompilerType GetFunctionArgumentType(size_t arg_idx) const;
+ /// Populate a valid compiler context from the current declaration.
+ ///
+ /// \returns A valid vector of CompilerContext entries that describes
+ /// this declaration. The first entry in the vector is the parent of
+ /// the subsequent entry, so the top most entry is the global namespace.
hawkinsw wrote:
```suggestion
/// the subsequent entry, so the topmost entry is the global namespace.
```
https://github.com/llvm/llvm-project/pull/74786
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Make only one function that needs to be implemented when searching for types (PR #74786)
@@ -340,26 +340,22 @@ class ModuleList {
lldb::SymbolType symbol_type,
SymbolContextList &sc_list) const;
- /// Find types by name.
+ /// Find types using a type matching object that contains all search
+ /// parameters.
///
/// \param[in] search_first
/// If non-null, this module will be searched before any other
/// modules.
///
- /// \param[in] name
- /// The name of the type we are looking for.
- ///
- /// \param[in] max_matches
- /// Allow the number of matches to be limited to \a
- /// max_matches. Specify UINT32_MAX to get all possible matches.
- ///
- /// \param[out] types
- /// A type list gets populated with any matches.
+ /// \param[in] query
+ /// A type matching object that contains all of the details of the type
hawkinsw wrote:
```suggestion
/// A type-matching object that contains all of the details of the type
```
https://github.com/llvm/llvm-project/pull/74786
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Make only one function that needs to be implemented when searching for types (PR #74786)
https://github.com/hawkinsw edited https://github.com/llvm/llvm-project/pull/74786 ___ 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 CompilerType class (second try). (PR #73472)
@@ -436,8 +482,8 @@ class CompilerType {
ExecutionContextScope *exe_scope);
/// Dump to stdout.
- void DumpTypeDescription(lldb::DescriptionLevel level =
- lldb::eDescriptionLevelFull) const;
hawkinsw wrote:
It's ugly, but there *is* this:
```C++
// clang-format off
...
// clang-format on
```
I am sure that you knew that and were asking for a nicer workaround. I, too,
would be interested in learning such a trick, if it existed.
https://github.com/llvm/llvm-project/pull/73472
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Add the ability to define a Python based command that uses CommandObjectParsed (PR #70734)
hawkinsw wrote: @jimingham Looks like great work -- I hope my few comments were helpful! https://github.com/llvm/llvm-project/pull/70734 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Add the ability to define a Python based command that uses CommandObjectParsed (PR #70734)
@@ -0,0 +1,315 @@
+"""
+This module implements a couple of utility classes to make writing
+lldb parsed commands more Pythonic.
+The way to use it is to make a class for you command that inherits from
ParsedCommandBase.
+That will make an LLDBOVParser which you will use for your
+option definition, and to fetch option values for the current invocation
+of your command. Access to the OV parser is through:
+
+ParsedCommandBase.get_parser()
+
+Next, implement setup_command_definition in your new command class, and call:
+
+ self.get_parser().add_option
+
+to add all your options. The order doesn't matter for options, lldb will sort
them
+alphabetically for you when it prints help.
+
+Similarly you can define the arguments with:
+
+ self.get_parser.add_argument
+
+at present, lldb doesn't do as much work as it should verifying arguments, it
pretty
+much only checks that commands that take no arguments don't get passed
arguments.
+
+Then implement the execute function for your command as:
+
+def __call__(self, debugger, args_array, exe_ctx, result):
+
+The arguments will be in a python array as strings.
+
+You can access the option values using varname you passed in when defining the
option.
+If you need to know whether a given option was set by the user or not, you can
retrieve
+the option definition array with:
+
+ self.get_options_definition()
+
+look up your element by varname and check the "_value_set" element.
+
+There are example commands in the lldb testsuite at:
+
+llvm-project/lldb/test/API/commands/command/script/add/test_commands.py
+
+FIXME: I should make a convenient wrapper for that.
+"""
+import inspect
+import lldb
+import sys
+
+class LLDBOVParser:
+def __init__(self):
+self.options_array = []
+self.args_array = []
+
+# Some methods to translate common value types. Should return a
+# tuple of the value and an error value (True => error) if the
+# type can't be converted.
+# FIXME: Need a way to push the conversion error string back to lldb.
+@staticmethod
+def to_bool(in_value):
+error = True
+value = False
+low_in = in_value.lower()
+if low_in == "yes" or low_in == "true" or low_in == "1":
+value = True
+error = False
+
+if not value and low_in == "no" or low_in == "false" or low_in == "0":
+value = False
+error = False
+
+return (value, error)
+
+@staticmethod
+def to_int(in_value):
+#FIXME: Not doing errors yet...
+return (int(in_value), False)
+
+def to_unsigned(in_value):
+# FIXME: find an unsigned converter...
+# And handle errors.
+return (int(in_value), False)
+
+translators = {
+lldb.eArgTypeBoolean : to_bool,
+lldb.eArgTypeBreakpointID : to_unsigned,
+lldb.eArgTypeByteSize : to_unsigned,
+lldb.eArgTypeCount : to_unsigned,
+lldb.eArgTypeFrameIndex : to_unsigned,
+lldb.eArgTypeIndex : to_unsigned,
+lldb.eArgTypeLineNum : to_unsigned,
+lldb.eArgTypeNumLines : to_unsigned,
+lldb.eArgTypeNumberPerLine : to_unsigned,
+lldb.eArgTypeOffset : to_int,
+lldb.eArgTypeThreadIndex : to_unsigned,
+lldb.eArgTypeUnsignedInteger : to_unsigned,
+lldb.eArgTypeWatchpointID : to_unsigned,
+lldb.eArgTypeColumnNum : to_unsigned,
+lldb.eArgTypeRecognizerID : to_unsigned,
+lldb.eArgTypeTargetID : to_unsigned,
+lldb.eArgTypeStopHookID : to_unsigned
+}
+
+@classmethod
+def translate_value(cls, value_type, value):
+error = False
+try:
+return cls.translators[value_type](value)
+except KeyError:
+# If we don't have a translator, return the string value.
+return (value, False)
+
+# FIXME: would this be better done on the C++ side?
+# The common completers are missing some useful ones.
+# For instance there really should be a common Type completer
+# And an "lldb command name" completer.
+completion_table = {
+lldb.eArgTypeAddressOrExpression : lldb.eVariablePathCompletion,
+lldb.eArgTypeArchitecture : lldb.eArchitectureCompletion,
+lldb.eArgTypeBreakpointID : lldb.eBreakpointCompletion,
+lldb.eArgTypeBreakpointIDRange : lldb.eBreakpointCompletion,
+lldb.eArgTypeBreakpointName : lldb.eBreakpointNameCompletion,
+lldb.eArgTypeClassName : lldb.eSymbolCompletion,
+lldb.eArgTypeDirectoryName : lldb.eDiskDirectoryCompletion,
+lldb.eArgTypeExpression : lldb.eVariablePathCompletion,
+lldb.eArgTypeExpressionPath : lldb.eVariablePathCompletion,
+lldb.eArgTypeFilename : lldb.eDiskFileCompletion,
+lldb.eArgTypeFrameIndex : lldb.eFrameIndexCompletion,
+lldb.eArgTypeFunctionName : lldb.eSymbolCompletion,
+lldb.eArgTypeFunctionOrSymbol : lldb.eSymbolCompletion,
[Lldb-commits] [lldb] Add the ability to define a Python based command that uses CommandObjectParsed (PR #70734)
@@ -0,0 +1,315 @@
+"""
+This module implements a couple of utility classes to make writing
+lldb parsed commands more Pythonic.
+The way to use it is to make a class for you command that inherits from
ParsedCommandBase.
+That will make an LLDBOVParser which you will use for your
+option definition, and to fetch option values for the current invocation
+of your command. Access to the OV parser is through:
+
+ParsedCommandBase.get_parser()
+
+Next, implement setup_command_definition in your new command class, and call:
+
+ self.get_parser().add_option
+
+to add all your options. The order doesn't matter for options, lldb will sort
them
+alphabetically for you when it prints help.
+
+Similarly you can define the arguments with:
+
+ self.get_parser.add_argument
+
+at present, lldb doesn't do as much work as it should verifying arguments, it
pretty
+much only checks that commands that take no arguments don't get passed
arguments.
+
+Then implement the execute function for your command as:
+
+def __call__(self, debugger, args_array, exe_ctx, result):
+
+The arguments will be in a python array as strings.
+
+You can access the option values using varname you passed in when defining the
option.
+If you need to know whether a given option was set by the user or not, you can
retrieve
+the option definition array with:
+
+ self.get_options_definition()
+
+look up your element by varname and check the "_value_set" element.
+
+There are example commands in the lldb testsuite at:
+
+llvm-project/lldb/test/API/commands/command/script/add/test_commands.py
+
+FIXME: I should make a convenient wrapper for that.
+"""
+import inspect
+import lldb
+import sys
+
+class LLDBOVParser:
+def __init__(self):
+self.options_array = []
+self.args_array = []
+
+# Some methods to translate common value types. Should return a
+# tuple of the value and an error value (True => error) if the
+# type can't be converted.
+# FIXME: Need a way to push the conversion error string back to lldb.
+@staticmethod
+def to_bool(in_value):
+error = True
+value = False
+low_in = in_value.lower()
+if low_in == "yes" or low_in == "true" or low_in == "1":
+value = True
+error = False
+
+if not value and low_in == "no" or low_in == "false" or low_in == "0":
+value = False
+error = False
+
+return (value, error)
+
+@staticmethod
+def to_int(in_value):
+#FIXME: Not doing errors yet...
+return (int(in_value), False)
+
+def to_unsigned(in_value):
+# FIXME: find an unsigned converter...
+# And handle errors.
+return (int(in_value), False)
+
+translators = {
+lldb.eArgTypeBoolean : to_bool,
+lldb.eArgTypeBreakpointID : to_unsigned,
+lldb.eArgTypeByteSize : to_unsigned,
+lldb.eArgTypeCount : to_unsigned,
+lldb.eArgTypeFrameIndex : to_unsigned,
+lldb.eArgTypeIndex : to_unsigned,
+lldb.eArgTypeLineNum : to_unsigned,
+lldb.eArgTypeNumLines : to_unsigned,
+lldb.eArgTypeNumberPerLine : to_unsigned,
+lldb.eArgTypeOffset : to_int,
+lldb.eArgTypeThreadIndex : to_unsigned,
+lldb.eArgTypeUnsignedInteger : to_unsigned,
+lldb.eArgTypeWatchpointID : to_unsigned,
+lldb.eArgTypeColumnNum : to_unsigned,
+lldb.eArgTypeRecognizerID : to_unsigned,
+lldb.eArgTypeTargetID : to_unsigned,
+lldb.eArgTypeStopHookID : to_unsigned
+}
+
+@classmethod
+def translate_value(cls, value_type, value):
+error = False
+try:
+return cls.translators[value_type](value)
+except KeyError:
+# If we don't have a translator, return the string value.
+return (value, False)
+
+# FIXME: would this be better done on the C++ side?
+# The common completers are missing some useful ones.
+# For instance there really should be a common Type completer
+# And an "lldb command name" completer.
+completion_table = {
+lldb.eArgTypeAddressOrExpression : lldb.eVariablePathCompletion,
+lldb.eArgTypeArchitecture : lldb.eArchitectureCompletion,
+lldb.eArgTypeBreakpointID : lldb.eBreakpointCompletion,
+lldb.eArgTypeBreakpointIDRange : lldb.eBreakpointCompletion,
+lldb.eArgTypeBreakpointName : lldb.eBreakpointNameCompletion,
+lldb.eArgTypeClassName : lldb.eSymbolCompletion,
+lldb.eArgTypeDirectoryName : lldb.eDiskDirectoryCompletion,
+lldb.eArgTypeExpression : lldb.eVariablePathCompletion,
+lldb.eArgTypeExpressionPath : lldb.eVariablePathCompletion,
+lldb.eArgTypeFilename : lldb.eDiskFileCompletion,
+lldb.eArgTypeFrameIndex : lldb.eFrameIndexCompletion,
+lldb.eArgTypeFunctionName : lldb.eSymbolCompletion,
+lldb.eArgTypeFunctionOrSymbol : lldb.eSymbolCompletion,
[Lldb-commits] [lldb] Add the ability to define a Python based command that uses CommandObjectParsed (PR #70734)
@@ -0,0 +1,315 @@ +""" +This module implements a couple of utility classes to make writing +lldb parsed commands more Pythonic. +The way to use it is to make a class for you command that inherits from ParsedCommandBase. +That will make an LLDBOVParser which you will use for your +option definition, and to fetch option values for the current invocation +of your command. Access to the OV parser is through: + +ParsedCommandBase.get_parser() + +Next, implement setup_command_definition in your new command class, and call: + + self.get_parser().add_option + +to add all your options. The order doesn't matter for options, lldb will sort them +alphabetically for you when it prints help. + +Similarly you can define the arguments with: + + self.get_parser.add_argument + +at present, lldb doesn't do as much work as it should verifying arguments, it pretty +much only checks that commands that take no arguments don't get passed arguments. + +Then implement the execute function for your command as: + +def __call__(self, debugger, args_array, exe_ctx, result): + +The arguments will be in a python array as strings. + +You can access the option values using varname you passed in when defining the option. hawkinsw wrote: ```suggestion You can access the option values using the varname you passed in when defining the option. ``` https://github.com/llvm/llvm-project/pull/70734 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
