[Lldb-commits] [lldb] Add new Python API `SBCommandInterpreter::GetTranscript()` (PR #90703)
https://github.com/clayborg requested changes to this pull request. You will need to hook this up so it actually works, and then add a test case to verify this works as expected. https://github.com/llvm/llvm-project/pull/90703 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Add new Python API `SBCommandInterpreter::GetTranscript()` (PR #90703)
https://github.com/royitaqi edited https://github.com/llvm/llvm-project/pull/90703 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Add new Python API `SBCommandInterpreter::GetTranscript()` (PR #90703)
https://github.com/royitaqi edited https://github.com/llvm/llvm-project/pull/90703 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Add new Python API `SBCommandInterpreter::GetTranscript()` (PR #90703)
https://github.com/royitaqi edited https://github.com/llvm/llvm-project/pull/90703 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Add new Python API `SBCommandInterpreter::GetTranscript()` (PR #90703)
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: None (royitaqi)
Changes
# Motivation
Currently, the user can already get the "transcript" (for "what is the
transcript", see `CommandInterpreter::SaveTranscript()`). However, the only way
to obtain the transcript data as a user is to first destroy the debugger, then
read the save directory. Note that destroy-callbacks cannot be used, because 1\
transcript data is private to the command interpreter (see
`CommandInterpreter.h`), and 2\ the writing of the transcript is *after* the
invocation of destory-callbacks (see `Debugger::Destroy()`).
So basically, there is no way to obtain the transcript:
* during the lifetime of a debugger (including the destroy-callbacks, which is
often performs logging tasks)
* without relying on external storage
# Proposal
Add a new Python API `SBCommandInterpreter::GetTranscript()`.
Goals:
* It can be called at any time during the debugger's life cycle, including in
destroy-callbacks.
* It returns data in-memory.
Structured data:
* To make data processing easier, the return type is `SBStructuredData`. See
comments in code for how the data is organized.
* In the future, `SaveTranscript` can be updated to write different formats
using such data (e.g. JSON). This is probably accompanied by a new setting
(e.g. `interpreter.save-session-format`).
# Alternatives
The return type can also be `std::vectorstd::pairstd::string,
SBCommandReturnObject`. This will make implementation easier, without
having to translate it to `SBStructuredData`. On the other hand,
`SBStructuredData` can convert to JSON easily, so it's more convenient for user
to process.
---
Full diff: https://github.com/llvm/llvm-project/pull/90703.diff
2 Files Affected:
- (modified) lldb/include/lldb/API/SBCommandInterpreter.h (+9-3)
- (modified) lldb/source/API/SBCommandInterpreter.cpp (+6-1)
``diff
diff --git a/lldb/include/lldb/API/SBCommandInterpreter.h
b/lldb/include/lldb/API/SBCommandInterpreter.h
index ba2e049204b8e6..d65f06d676f91f 100644
--- a/lldb/include/lldb/API/SBCommandInterpreter.h
+++ b/lldb/include/lldb/API/SBCommandInterpreter.h
@@ -247,13 +247,13 @@ class SBCommandInterpreter {
lldb::SBStringList ,
lldb::SBStringList );
- /// Returns whether an interrupt flag was raised either by the SBDebugger -
+ /// Returns whether an interrupt flag was raised either by the SBDebugger -
/// when the function is not running on the RunCommandInterpreter thread, or
/// by SBCommandInterpreter::InterruptCommand if it is. If your code is
doing
- /// interruptible work, check this API periodically, and interrupt if it
+ /// interruptible work, check this API periodically, and interrupt if it
/// returns true.
bool WasInterrupted() const;
-
+
/// Interrupts the command currently executing in the RunCommandInterpreter
/// thread.
///
@@ -318,6 +318,12 @@ class SBCommandInterpreter {
SBStructuredData GetStatistics();
+ /// Returns a list of handled commands, output and error. Each element in
+ /// the list is a dictionary with three keys: "command" (string), "output"
+ /// (list of strings) and optionally "error" (list of strings). Each string
+ /// in "output" and "error" is a line (without EOL characteres).
+ SBStructuredData GetTranscript();
+
protected:
friend class lldb_private::CommandPluginInterfaceImplementation;
diff --git a/lldb/source/API/SBCommandInterpreter.cpp
b/lldb/source/API/SBCommandInterpreter.cpp
index 83c0951c56db60..242b3f8f09c48a 100644
--- a/lldb/source/API/SBCommandInterpreter.cpp
+++ b/lldb/source/API/SBCommandInterpreter.cpp
@@ -150,7 +150,7 @@ bool SBCommandInterpreter::WasInterrupted() const {
bool SBCommandInterpreter::InterruptCommand() {
LLDB_INSTRUMENT_VA(this);
-
+
return (IsValid() ? m_opaque_ptr->InterruptCommand() : false);
}
@@ -571,6 +571,11 @@ SBStructuredData SBCommandInterpreter::GetStatistics() {
return data;
}
+SBStructuredData SBCommandInterpreter::GetTranscript() {
+ LLDB_INSTRUMENT_VA(this);
+ return SBStructuredData();
+}
+
lldb::SBCommand SBCommandInterpreter::AddMultiwordCommand(const char *name,
const char *help) {
LLDB_INSTRUMENT_VA(this, name, help);
``
https://github.com/llvm/llvm-project/pull/90703
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Add new Python API `SBCommandInterpreter::GetTranscript()` (PR #90703)
github-actions[bot] wrote: Thank you for submitting a Pull Request (PR) to the LLVM Project! This PR will be automatically labeled and the relevant teams will be notified. If you wish to, you can add reviewers by using the "Reviewers" section on this page. If this is not working for you, it is probably because you do not have write permissions for the repository. In which case you can instead tag reviewers by name in a comment by using `@` followed by their GitHub username. If you have received no comments on your PR for a week, you can request a review by "ping"ing the PR by adding a comment “Ping”. The common courtesy "ping" rate is once a week. Please remember that you are asking for valuable time from other developers. If you have further questions, they may be answered by the [LLVM GitHub User Guide](https://llvm.org/docs/GitHub.html). You can also ask questions in a comment on this PR, on the [LLVM Discord](https://discord.com/invite/xS7Z362) or on the [forums](https://discourse.llvm.org/). https://github.com/llvm/llvm-project/pull/90703 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Add new Python API `SBCommandInterpreter::GetTranscript()` (PR #90703)
https://github.com/royitaqi created
https://github.com/llvm/llvm-project/pull/90703
# Motivation
Currently, the user can already get the "transcript" (for "what is the
transcript", see `CommandInterpreter::SaveTranscript()`). However, the only way
to obtain the transcript data as a user is to first destroy the debugger, then
read the save directory. Note that destroy-callbacks cannot be used, because 1\
transcript data is private to the command interpreter (see
`CommandInterpreter.h`), and 2\ the writing of the transcript is *after* the
invocation of destory-callbacks (see `Debugger::Destroy()`).
So basically, there is no way to obtain the transcript:
* during the lifetime of a debugger (including the destroy-callbacks, which is
often performs logging tasks)
* without relying on external storage
# Proposal
Add a new Python API `SBCommandInterpreter::GetTranscript()`.
Goals:
* It can be called at any time during the debugger's life cycle, including in
destroy-callbacks.
* It returns data in-memory.
Structured data:
* To make data processing easier, the return type is `SBStructuredData`. See
comments in code for how the data is organized.
* In the future, `SaveTranscript` can be updated to write different formats
using such data (e.g. JSON). This is probably accompanied by a new setting
(e.g. `interpreter.save-session-format`).
# Alternatives
The return type can also be `std::vector>`. This will make implementation easier, without having
to translate it to `SBStructuredData`. On the other hand, `SBStructuredData`
can convert to JSON easily, so it's more convenient for user to process.
>From 0fd67e2de7e702ce6f7353845454ea7ff9f980d6 Mon Sep 17 00:00:00 2001
From: Roy Shi
Date: Tue, 30 Apr 2024 21:35:49 -0700
Subject: [PATCH] Add SBCommandInterpreter::GetTranscript()
---
lldb/include/lldb/API/SBCommandInterpreter.h | 12 +---
lldb/source/API/SBCommandInterpreter.cpp | 7 ++-
2 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/lldb/include/lldb/API/SBCommandInterpreter.h
b/lldb/include/lldb/API/SBCommandInterpreter.h
index ba2e049204b8e6..d65f06d676f91f 100644
--- a/lldb/include/lldb/API/SBCommandInterpreter.h
+++ b/lldb/include/lldb/API/SBCommandInterpreter.h
@@ -247,13 +247,13 @@ class SBCommandInterpreter {
lldb::SBStringList ,
lldb::SBStringList );
- /// Returns whether an interrupt flag was raised either by the SBDebugger -
+ /// Returns whether an interrupt flag was raised either by the SBDebugger -
/// when the function is not running on the RunCommandInterpreter thread, or
/// by SBCommandInterpreter::InterruptCommand if it is. If your code is
doing
- /// interruptible work, check this API periodically, and interrupt if it
+ /// interruptible work, check this API periodically, and interrupt if it
/// returns true.
bool WasInterrupted() const;
-
+
/// Interrupts the command currently executing in the RunCommandInterpreter
/// thread.
///
@@ -318,6 +318,12 @@ class SBCommandInterpreter {
SBStructuredData GetStatistics();
+ /// Returns a list of handled commands, output and error. Each element in
+ /// the list is a dictionary with three keys: "command" (string), "output"
+ /// (list of strings) and optionally "error" (list of strings). Each string
+ /// in "output" and "error" is a line (without EOL characteres).
+ SBStructuredData GetTranscript();
+
protected:
friend class lldb_private::CommandPluginInterfaceImplementation;
diff --git a/lldb/source/API/SBCommandInterpreter.cpp
b/lldb/source/API/SBCommandInterpreter.cpp
index 83c0951c56db60..242b3f8f09c48a 100644
--- a/lldb/source/API/SBCommandInterpreter.cpp
+++ b/lldb/source/API/SBCommandInterpreter.cpp
@@ -150,7 +150,7 @@ bool SBCommandInterpreter::WasInterrupted() const {
bool SBCommandInterpreter::InterruptCommand() {
LLDB_INSTRUMENT_VA(this);
-
+
return (IsValid() ? m_opaque_ptr->InterruptCommand() : false);
}
@@ -571,6 +571,11 @@ SBStructuredData SBCommandInterpreter::GetStatistics() {
return data;
}
+SBStructuredData SBCommandInterpreter::GetTranscript() {
+ LLDB_INSTRUMENT_VA(this);
+ return SBStructuredData();
+}
+
lldb::SBCommand SBCommandInterpreter::AddMultiwordCommand(const char *name,
const char *help) {
LLDB_INSTRUMENT_VA(this, name, help);
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Install generated API headers into LLDB.framework (PR #90666)
github-actions[bot] wrote: :warning: C/C++ code formatter, clang-format found issues in your code. :warning: You can test this locally with the following command: ``bash git-clang-format --diff 4cd11c986f78e19f53b3f3c92143b7b7c1ce54b1 9510a08995da26d0c3c1ea8d13f6c3f8fab772c2 -- lldb/include/lldb/API/LLDB.h `` View the diff from clang-format here. ``diff diff --git a/lldb/include/lldb/API/LLDB.h b/lldb/include/lldb/API/LLDB.h index 4347954af7..b256544326 100644 --- a/lldb/include/lldb/API/LLDB.h +++ b/lldb/include/lldb/API/LLDB.h @@ -39,8 +39,8 @@ #include "lldb/API/SBHostOS.h" #include "lldb/API/SBInstruction.h" #include "lldb/API/SBInstructionList.h" -#include "lldb/API/SBLanguages.h" #include "lldb/API/SBLanguageRuntime.h" +#include "lldb/API/SBLanguages.h" #include "lldb/API/SBLaunchInfo.h" #include "lldb/API/SBLineEntry.h" #include "lldb/API/SBListener.h" `` https://github.com/llvm/llvm-project/pull/90666 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Install generated API headers into LLDB.framework (PR #90666)
adrian-prantl wrote: I had to replace the GLOB with a hardcoded file name because the GLOB gets evaluated at CMake configure time, when the file doesn't exist yet. https://github.com/llvm/llvm-project/pull/90666 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Install generated API headers into LLDB.framework (PR #90666)
@@ -8,6 +8,12 @@ set(LLDB_INCLUDE_ROOT "${CMAKE_CURRENT_SOURCE_DIR}/include")
set(LLDB_SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR})
set(LLDB_BINARY_DIR ${CMAKE_CURRENT_BINARY_DIR})
+if (LLDB_BUILT_STANDALONE)
+ set(LLDB_OBJ_DIR ${CMAKE_CURRENT_BINARY_DIR})
+else()
+ set(LLDB_OBJ_DIR ${CMAKE_CURRENT_BINARY_DIR}/tools/lldb)
+endif()
adrian-prantl wrote:
It looks like when it's evaluated here it actually points to `tools/lldb` so
just setting the variable to CMAKE_CURRENT_BINARY_DIR here seems to do the
trick. Unless it's undefined which directory we get based on context?
https://github.com/llvm/llvm-project/pull/90666
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Install generated API headers into LLDB.framework (PR #90666)
https://github.com/adrian-prantl updated
https://github.com/llvm/llvm-project/pull/90666
>From 9510a08995da26d0c3c1ea8d13f6c3f8fab772c2 Mon Sep 17 00:00:00 2001
From: Adrian Prantl
Date: Tue, 30 Apr 2024 13:59:39 -0700
Subject: [PATCH] Install generated API headers into LLDB.framework
---
lldb/cmake/modules/LLDBConfig.cmake | 2 ++
lldb/cmake/modules/LLDBFramework.cmake | 2 ++
lldb/include/lldb/API/LLDB.h| 1 +
lldb/packages/Python/lldbsuite/test/builders/builder.py | 4
lldb/packages/Python/lldbsuite/test/make/Makefile.rules | 5 +++--
5 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/lldb/cmake/modules/LLDBConfig.cmake
b/lldb/cmake/modules/LLDBConfig.cmake
index a758261073ac57..5e897257bce75e 100644
--- a/lldb/cmake/modules/LLDBConfig.cmake
+++ b/lldb/cmake/modules/LLDBConfig.cmake
@@ -8,6 +8,8 @@ set(LLDB_INCLUDE_ROOT "${CMAKE_CURRENT_SOURCE_DIR}/include")
set(LLDB_SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR})
set(LLDB_BINARY_DIR ${CMAKE_CURRENT_BINARY_DIR})
+set(LLDB_OBJ_DIR ${CMAKE_CURRENT_BINARY_DIR})
+
if(CMAKE_SOURCE_DIR STREQUAL CMAKE_BINARY_DIR)
message(FATAL_ERROR
"In-source builds are not allowed. CMake would overwrite the makefiles "
diff --git a/lldb/cmake/modules/LLDBFramework.cmake
b/lldb/cmake/modules/LLDBFramework.cmake
index f915839f6b45a5..df2f8ddf54a3d5 100644
--- a/lldb/cmake/modules/LLDBFramework.cmake
+++ b/lldb/cmake/modules/LLDBFramework.cmake
@@ -71,6 +71,7 @@ endif()
# At configuration time, collect headers for the framework bundle and copy them
# into a staging directory. Later we can copy over the entire folder.
file(GLOB public_headers ${LLDB_SOURCE_DIR}/include/lldb/API/*.h)
+set(generated_public_headers ${LLDB_OBJ_DIR}/include/lldb/API/SBLanguages.h)
file(GLOB root_public_headers ${LLDB_SOURCE_DIR}/include/lldb/lldb-*.h)
file(GLOB root_private_headers ${LLDB_SOURCE_DIR}/include/lldb/lldb-private*.h)
list(REMOVE_ITEM root_public_headers ${root_private_headers})
@@ -80,6 +81,7 @@ find_program(unifdef_EXECUTABLE unifdef)
set(lldb_header_staging ${CMAKE_CURRENT_BINARY_DIR}/FrameworkHeaders)
foreach(header
${public_headers}
+${generated_public_headers}
${root_public_headers})
get_filename_component(basename ${header} NAME)
diff --git a/lldb/include/lldb/API/LLDB.h b/lldb/include/lldb/API/LLDB.h
index c83eb92fcfb30a..4347954af7138c 100644
--- a/lldb/include/lldb/API/LLDB.h
+++ b/lldb/include/lldb/API/LLDB.h
@@ -39,6 +39,7 @@
#include "lldb/API/SBHostOS.h"
#include "lldb/API/SBInstruction.h"
#include "lldb/API/SBInstructionList.h"
+#include "lldb/API/SBLanguages.h"
#include "lldb/API/SBLanguageRuntime.h"
#include "lldb/API/SBLaunchInfo.h"
#include "lldb/API/SBLineEntry.h"
diff --git a/lldb/packages/Python/lldbsuite/test/builders/builder.py
b/lldb/packages/Python/lldbsuite/test/builders/builder.py
index 823a982e674380..21ea3530e24fcb 100644
--- a/lldb/packages/Python/lldbsuite/test/builders/builder.py
+++ b/lldb/packages/Python/lldbsuite/test/builders/builder.py
@@ -148,6 +148,9 @@ def getLibCxxArgs(self):
return libcpp_args
return []
+def getLLDBObjRoot(self):
+return ["LLDB_OBJ_ROOT={}".format(configuration.lldb_obj_root)]
+
def _getDebugInfoArgs(self, debug_info):
if debug_info is None:
return []
@@ -185,6 +188,7 @@ def getBuildCommand(
self.getSDKRootSpec(),
self.getModuleCacheSpec(),
self.getLibCxxArgs(),
+self.getLLDBObjRoot(),
self.getCmdLine(dictionary),
]
command = list(itertools.chain(*command_parts))
diff --git a/lldb/packages/Python/lldbsuite/test/make/Makefile.rules
b/lldb/packages/Python/lldbsuite/test/make/Makefile.rules
index bfd249ccd43f2e..bd8eea3d6f5a04 100644
--- a/lldb/packages/Python/lldbsuite/test/make/Makefile.rules
+++ b/lldb/packages/Python/lldbsuite/test/make/Makefile.rules
@@ -238,10 +238,11 @@ ifeq "$(OS)" "Darwin"
endif
ifeq "$(OS)" "Darwin"
- CFLAGS += $(ARCHFLAG) $(ARCH) $(FRAMEWORK_INCLUDES)
-I$(LLDB_BASE_DIR)include
+ CFLAGS += $(ARCHFLAG) $(ARCH) $(FRAMEWORK_INCLUDES)
else
- CFLAGS += $(ARCHFLAG)$(ARCH) $(FRAMEWORK_INCLUDES)
-I$(LLDB_BASE_DIR)include
+ CFLAGS += $(ARCHFLAG)$(ARCH)
endif
+CFLAGS += -I$(LLDB_BASE_DIR)include -I$(LLDB_OBJ_ROOT)/include
CFLAGS += -I$(SRCDIR) -I$(THIS_FILE_DIR)
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Summarize std::string's when created from data. (PR #89110)
@@ -287,8 +292,49 @@ bool
lldb_private::formatters::LibStdcppStringSummaryProvider(
} else
return true;
} break;
-case eAddressTypeHost:
- break;
+case eAddressTypeHost: {
+
+ DataExtractor data;
+ Status error;
+ valobj.GetData(data, error);
+ if (error.Fail())
+return false;
+
+ lldb::offset_t offset = 0;
+ AddressType child_addressType = valobj.GetAddressTypeOfChildren();
+ if (child_addressType == eAddressTypeLoad) {
+// We have the host address of our std::string
+// But we need to read the pointee data from the debugged process.
+ProcessSP process_sp(valobj.GetProcessSP());
+// We want to read the address from std::string, which is the first 8
bytes.
+lldb::addr_t addr = data.GetAddress();
+if (!addr) {
+ stream.Printf("nullptr");
+ return true;
+}
+std::string contents;
+process_sp->ReadCStringFromMemory(addr, contents, error);
+if (error.Fail())
+ return false;
+
+stream.Printf("%s", contents.c_str());
+return true;
+ }
+
+ if (child_addressType == eAddressTypeHost) {
+lldb::offset_t size = data.GetByteSize();
+const void* dataStart = data.GetData(, size);
+if (!dataStart)
+ return false;
+
+const std::string* str = static_cast(dataStart);
clayborg wrote:
We can't assume that the host std::string will match the debugee std::string.
If we are remote debugging to another architecture, then we will have problems.
https://github.com/llvm/llvm-project/pull/89110
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Summarize std::string's when created from data. (PR #89110)
@@ -287,8 +292,49 @@ bool
lldb_private::formatters::LibStdcppStringSummaryProvider(
} else
return true;
} break;
-case eAddressTypeHost:
- break;
+case eAddressTypeHost: {
+
+ DataExtractor data;
+ Status error;
+ valobj.GetData(data, error);
+ if (error.Fail())
+return false;
+
+ lldb::offset_t offset = 0;
+ AddressType child_addressType = valobj.GetAddressTypeOfChildren();
+ if (child_addressType == eAddressTypeLoad) {
+// We have the host address of our std::string
+// But we need to read the pointee data from the debugged process.
+ProcessSP process_sp(valobj.GetProcessSP());
+// We want to read the address from std::string, which is the first 8
bytes.
+lldb::addr_t addr = data.GetAddress();
+if (!addr) {
+ stream.Printf("nullptr");
+ return true;
+}
+std::string contents;
+process_sp->ReadCStringFromMemory(addr, contents, error);
+if (error.Fail())
+ return false;
+
+stream.Printf("%s", contents.c_str());
+return true;
+ }
+
+ if (child_addressType == eAddressTypeHost) {
clayborg wrote:
This code is never being run because no one will set the child address type to
host memory.
https://github.com/llvm/llvm-project/pull/89110
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Install generated API headers into LLDB.framework (PR #90666)
@@ -8,6 +8,12 @@ set(LLDB_INCLUDE_ROOT "${CMAKE_CURRENT_SOURCE_DIR}/include")
set(LLDB_SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR})
set(LLDB_BINARY_DIR ${CMAKE_CURRENT_BINARY_DIR})
+if (LLDB_BUILT_STANDALONE)
+ set(LLDB_OBJ_DIR ${CMAKE_CURRENT_BINARY_DIR})
+else()
+ set(LLDB_OBJ_DIR ${CMAKE_CURRENT_BINARY_DIR}/tools/lldb)
+endif()
bulbazord wrote:
LLDBConfig is included after LLDBStandalone, so that can't work right?
https://github.com/llvm/llvm-project/pull/90666
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Install generated API headers into LLDB.framework (PR #90666)
@@ -8,6 +8,12 @@ set(LLDB_INCLUDE_ROOT "${CMAKE_CURRENT_SOURCE_DIR}/include")
set(LLDB_SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR})
set(LLDB_BINARY_DIR ${CMAKE_CURRENT_BINARY_DIR})
+if (LLDB_BUILT_STANDALONE)
+ set(LLDB_OBJ_DIR ${CMAKE_CURRENT_BINARY_DIR})
+else()
+ set(LLDB_OBJ_DIR ${CMAKE_CURRENT_BINARY_DIR}/tools/lldb)
+endif()
JDevlieghere wrote:
`LLDBConfig` shouldn't know about the standalone build. You should set it to
`CMAKE_CURRENT_BINARY_DIR` here and overwrite it in `LLDBStandalone.cmake`.
https://github.com/llvm/llvm-project/pull/90666
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Install generated API headers into LLDB.framework (PR #90666)
https://github.com/JDevlieghere requested changes to this pull request. https://github.com/llvm/llvm-project/pull/90666 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Install generated API headers into LLDB.framework (PR #90666)
https://github.com/JDevlieghere edited https://github.com/llvm/llvm-project/pull/90666 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Install generated API headers into LLDB.framework (PR #90666)
https://github.com/bulbazord approved this pull request. Looks fine to me. Thanks for fixing this! https://github.com/llvm/llvm-project/pull/90666 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][Windows] Fixed unresolved test lldb-api python_api/debugger/TestDebuggerAPI.py (PR #90580)
bulbazord wrote: I think you've laid out the events that happen nicely but I came to the opposite conclusion. I still don't think this is the right fix. We have buildbots running on x86_64 and it works there too. I don't think this test working on AArch64 machines is related. The platform architecture getting set to x86_64 makes sense to me because the ELF is built as an x86_64 binary. However, the platform_sp getting set to `host` during the creation of the Target. That seems like the bug to me, especially because we explicitly set the platform to `remote-linux` when trying to create the target. The presented solution is a small bandage to work around the underlying bug. Another way to look at it might be: If we have to set the platform to `remote-linux` ourselves after creating the target, what's the point of `SBDebugger::CreateTarget` taking a platform name as an argument? https://github.com/llvm/llvm-project/pull/90580 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Install generated API headers into LLDB.framework (PR #90666)
https://github.com/adrian-prantl updated
https://github.com/llvm/llvm-project/pull/90666
>From 6950a36e2619f032f2dd41f258f171b876274bd5 Mon Sep 17 00:00:00 2001
From: Adrian Prantl
Date: Tue, 30 Apr 2024 13:59:39 -0700
Subject: [PATCH] Install generated API headers into LLDB.framework
---
lldb/cmake/modules/LLDBConfig.cmake | 6 ++
lldb/cmake/modules/LLDBFramework.cmake | 2 ++
lldb/packages/Python/lldbsuite/test/builders/builder.py | 4
lldb/packages/Python/lldbsuite/test/builders/darwin.py | 1 -
lldb/packages/Python/lldbsuite/test/make/Makefile.rules | 5 +++--
5 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/lldb/cmake/modules/LLDBConfig.cmake
b/lldb/cmake/modules/LLDBConfig.cmake
index a758261073ac57..2b0a319472ce95 100644
--- a/lldb/cmake/modules/LLDBConfig.cmake
+++ b/lldb/cmake/modules/LLDBConfig.cmake
@@ -8,6 +8,12 @@ set(LLDB_INCLUDE_ROOT "${CMAKE_CURRENT_SOURCE_DIR}/include")
set(LLDB_SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR})
set(LLDB_BINARY_DIR ${CMAKE_CURRENT_BINARY_DIR})
+if (LLDB_BUILT_STANDALONE)
+ set(LLDB_OBJ_DIR ${CMAKE_CURRENT_BINARY_DIR})
+else()
+ set(LLDB_OBJ_DIR ${CMAKE_CURRENT_BINARY_DIR}/tools/lldb)
+endif()
+
if(CMAKE_SOURCE_DIR STREQUAL CMAKE_BINARY_DIR)
message(FATAL_ERROR
"In-source builds are not allowed. CMake would overwrite the makefiles "
diff --git a/lldb/cmake/modules/LLDBFramework.cmake
b/lldb/cmake/modules/LLDBFramework.cmake
index f915839f6b45a5..3805ba17e5bec9 100644
--- a/lldb/cmake/modules/LLDBFramework.cmake
+++ b/lldb/cmake/modules/LLDBFramework.cmake
@@ -71,6 +71,7 @@ endif()
# At configuration time, collect headers for the framework bundle and copy them
# into a staging directory. Later we can copy over the entire folder.
file(GLOB public_headers ${LLDB_SOURCE_DIR}/include/lldb/API/*.h)
+file(GLOB generated_public_headers ${LLDB_OBJ_DIR}//include/lldb/API/*.h)
file(GLOB root_public_headers ${LLDB_SOURCE_DIR}/include/lldb/lldb-*.h)
file(GLOB root_private_headers ${LLDB_SOURCE_DIR}/include/lldb/lldb-private*.h)
list(REMOVE_ITEM root_public_headers ${root_private_headers})
@@ -80,6 +81,7 @@ find_program(unifdef_EXECUTABLE unifdef)
set(lldb_header_staging ${CMAKE_CURRENT_BINARY_DIR}/FrameworkHeaders)
foreach(header
${public_headers}
+${generated_public_headers}
${root_public_headers})
get_filename_component(basename ${header} NAME)
diff --git a/lldb/packages/Python/lldbsuite/test/builders/builder.py
b/lldb/packages/Python/lldbsuite/test/builders/builder.py
index 823a982e674380..21ea3530e24fcb 100644
--- a/lldb/packages/Python/lldbsuite/test/builders/builder.py
+++ b/lldb/packages/Python/lldbsuite/test/builders/builder.py
@@ -148,6 +148,9 @@ def getLibCxxArgs(self):
return libcpp_args
return []
+def getLLDBObjRoot(self):
+return ["LLDB_OBJ_ROOT={}".format(configuration.lldb_obj_root)]
+
def _getDebugInfoArgs(self, debug_info):
if debug_info is None:
return []
@@ -185,6 +188,7 @@ def getBuildCommand(
self.getSDKRootSpec(),
self.getModuleCacheSpec(),
self.getLibCxxArgs(),
+self.getLLDBObjRoot(),
self.getCmdLine(dictionary),
]
command = list(itertools.chain(*command_parts))
diff --git a/lldb/packages/Python/lldbsuite/test/builders/darwin.py
b/lldb/packages/Python/lldbsuite/test/builders/darwin.py
index a023bda3ad8010..af393696700915 100644
--- a/lldb/packages/Python/lldbsuite/test/builders/darwin.py
+++ b/lldb/packages/Python/lldbsuite/test/builders/darwin.py
@@ -88,7 +88,6 @@ def getExtraMakeArgs(self):
args["FRAMEWORK_INCLUDES"] = "-F{}".format(private_frameworks)
operating_system, env = get_os_and_env()
-
builder_dir = os.path.dirname(os.path.abspath(__file__))
test_dir = os.path.dirname(builder_dir)
if not operating_system:
diff --git a/lldb/packages/Python/lldbsuite/test/make/Makefile.rules
b/lldb/packages/Python/lldbsuite/test/make/Makefile.rules
index bfd249ccd43f2e..bd8eea3d6f5a04 100644
--- a/lldb/packages/Python/lldbsuite/test/make/Makefile.rules
+++ b/lldb/packages/Python/lldbsuite/test/make/Makefile.rules
@@ -238,10 +238,11 @@ ifeq "$(OS)" "Darwin"
endif
ifeq "$(OS)" "Darwin"
- CFLAGS += $(ARCHFLAG) $(ARCH) $(FRAMEWORK_INCLUDES)
-I$(LLDB_BASE_DIR)include
+ CFLAGS += $(ARCHFLAG) $(ARCH) $(FRAMEWORK_INCLUDES)
else
- CFLAGS += $(ARCHFLAG)$(ARCH) $(FRAMEWORK_INCLUDES)
-I$(LLDB_BASE_DIR)include
+ CFLAGS += $(ARCHFLAG)$(ARCH)
endif
+CFLAGS += -I$(LLDB_BASE_DIR)include -I$(LLDB_OBJ_ROOT)/include
CFLAGS += -I$(SRCDIR) -I$(THIS_FILE_DIR)
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][Windows] Fixed unresolved test lldb-api python_api/debugger/TestDebuggerAPI.py (PR #90580)
https://github.com/slydiman edited https://github.com/llvm/llvm-project/pull/90580 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Support custom LLVM formatting for variables (PR #81196)
kastiglione wrote: revert: 0f628fdb1aa8be97a5d86c3259b8caaa997790ec apologies, thanks for reporting @aaupov. https://github.com/llvm/llvm-project/pull/81196 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] 0f628fd - Revert "[lldb] Support custom LLVM formatting for variables (#81196)"
Author: Dave Lee
Date: 2024-04-30T16:15:19-07:00
New Revision: 0f628fdb1aa8be97a5d86c3259b8caaa997790ec
URL:
https://github.com/llvm/llvm-project/commit/0f628fdb1aa8be97a5d86c3259b8caaa997790ec
DIFF:
https://github.com/llvm/llvm-project/commit/0f628fdb1aa8be97a5d86c3259b8caaa997790ec.diff
LOG: Revert "[lldb] Support custom LLVM formatting for variables (#81196)"
This reverts commit 7a8d15e919dde70118dbfa34e927be1705ded67d.
Added:
Modified:
lldb/docs/use/variable.rst
lldb/source/Core/FormatEntity.cpp
Removed:
lldb/test/API/functionalities/data-formatter/custom-printf-summary/Makefile
lldb/test/API/functionalities/data-formatter/custom-printf-summary/TestCustomSummaryLLVMFormat.py
lldb/test/API/functionalities/data-formatter/custom-printf-summary/main.c
diff --git a/lldb/docs/use/variable.rst b/lldb/docs/use/variable.rst
index e9175b25336ba9..8eaed6405315b4 100644
--- a/lldb/docs/use/variable.rst
+++ b/lldb/docs/use/variable.rst
@@ -460,15 +460,6 @@ summary strings, regardless of the format they have
applied to their types. To
do that, you can use %format inside an expression path, as in ${var.x->x%u},
which would display the value of x as an unsigned integer.
-Additionally, custom output can be achieved by using an LLVM format string,
-commencing with the ``:`` marker. To illustrate, compare ``${var.byte%x}`` and
-``${var.byte:x-}``. The former uses lldb's builtin hex formatting (``x``),
-which unconditionally inserts a ``0x`` prefix, and also zero pads the value to
-match the size of the type. The latter uses ``llvm::formatv`` formatting
-(``:x-``), and will print only the hex value, with no ``0x`` prefix, and no
-padding. This raw control is useful when composing multiple pieces into a
-larger whole.
-
You can also use some other special format markers, not available for formats
themselves, but which carry a special meaning when used in this context:
diff --git a/lldb/source/Core/FormatEntity.cpp
b/lldb/source/Core/FormatEntity.cpp
index da5b1cfce74ac8..ba62e26252591f 100644
--- a/lldb/source/Core/FormatEntity.cpp
+++ b/lldb/source/Core/FormatEntity.cpp
@@ -57,7 +57,6 @@
#include "llvm/ADT/STLExtras.h"
#include "llvm/ADT/StringRef.h"
#include "llvm/Support/Compiler.h"
-#include "llvm/Support/Regex.h"
#include "llvm/TargetParser/Triple.h"
#include
@@ -659,38 +658,6 @@ static char ConvertValueObjectStyleToChar(
return '\0';
}
-static llvm::Regex LLVMFormatPattern{"x[-+]?\\d*|n|d",
llvm::Regex::IgnoreCase};
-
-static bool DumpValueWithLLVMFormat(Stream , llvm::StringRef options,
-ValueObject ) {
- std::string formatted;
- std::string llvm_format = ("{0:" + options + "}").str();
-
- // Options supported by format_provider for integral arithmetic types.
- // See table in FormatProviders.h.
-
- auto type_info = valobj.GetTypeInfo();
- if (type_info & eTypeIsInteger && LLVMFormatPattern.match(options)) {
-if (type_info & eTypeIsSigned) {
- bool success = false;
- int64_t integer = valobj.GetValueAsSigned(0, );
- if (success)
-formatted = llvm::formatv(llvm_format.data(), integer);
-} else {
- bool success = false;
- uint64_t integer = valobj.GetValueAsUnsigned(0, );
- if (success)
-formatted = llvm::formatv(llvm_format.data(), integer);
-}
- }
-
- if (formatted.empty())
-return false;
-
- s.Write(formatted.data(), formatted.size());
- return true;
-}
-
static bool DumpValue(Stream , const SymbolContext *sc,
const ExecutionContext *exe_ctx,
const FormatEntity::Entry , ValueObject *valobj) {
@@ -761,12 +728,9 @@ static bool DumpValue(Stream , const SymbolContext *sc,
return RunScriptFormatKeyword(s, sc, exe_ctx, valobj,
entry.string.c_str());
}
- auto split = llvm::StringRef(entry.string).split(':');
- auto subpath = split.first;
- auto llvm_format = split.second;
-
+ llvm::StringRef subpath(entry.string);
// simplest case ${var}, just print valobj's value
- if (subpath.empty()) {
+ if (entry.string.empty()) {
if (entry.printf_format.empty() && entry.fmt == eFormatDefault &&
entry.number == ValueObject::eValueObjectRepresentationStyleValue)
was_plain_var = true;
@@ -775,7 +739,7 @@ static bool DumpValue(Stream , const SymbolContext *sc,
target = valobj;
} else // this is ${var.something} or multiple .something nested
{
-if (subpath[0] == '[')
+if (entry.string[0] == '[')
was_var_indexed = true;
ScanBracketedRange(subpath, close_bracket_index,
var_name_final_if_array_range, index_lower,
@@ -783,11 +747,14 @@ static bool DumpValue(Stream , const SymbolContext *sc,
Status error;
-LLDB_LOG(log, "[Debugger::FormatPrompt] symbol to expand: {0}", subpath);
+const std::string _path = entry.string;
+
+
[Lldb-commits] [lldb] [lldb][Windows] Fixed unresolved test lldb-api python_api/debugger/TestDebuggerAPI.py (PR #90580)
slydiman wrote:
> `SBDebugger::CreateTarget` takes a `platform_name` argument which we're
> already setting to "remote-linux".
Probably it works on buildbots because the host architecture is `Aarch64`. I'm
trying to get it working on Windows `x86_64`.
`target1 = self.dbg.CreateTarget(exe, None, "remote-linux", False, error)`
calls TargetList::CreateTargetInternal() in
llvm-project/lldb/source/Target/TargetList.cpp, line 76
platform_options contains `remote-linux`, triple_str is empty, user_exe_path is
a path to ELF created from elf.yaml (x86_64).
platform_arch is updated to `x86_64` in TargetList.cpp, line 169:
```
// Only one arch and none was specified.
prefer_platform_arch = true;
platform_arch = matching_module_spec.GetArchitecture();
```
and platform_sp is updated to `host` in TargetList.cpp, line 226:
```
// If "arch" isn't valid, yet "platform_arch" is, it means we have an
// executable file with a single architecture which should be used.
ArchSpec fixed_platform_arch;
if (!platform_sp->IsCompatibleArchitecture(platform_arch, {},
ArchSpec::CompatibleMatch, nullptr)) {
platform_sp = platform_list.GetOrCreate(platform_arch, {},
_platform_arch);
if (platform_sp)
platform_list.SetSelectedPlatform(platform_sp);
}
```
Next call `target2 = self.dbg.CreateTarget(exe, None, "remote-linux", False,
error)` will create the platform `remote-linux` in TargetList.cpp, line 98:
```
// Create a new platform if a platform was specified in the platform options
and doesn't match the selected platform.
if (platform_options && platform_options->PlatformWasSpecified() &&
!platform_options->PlatformMatches(platform_sp)) {
const bool select_platform = true;
platform_sp =
platform_options->CreatePlatformWithOptions(debugger.GetCommandInterpreter(),
arch, select_platform, error, platform_arch);
if (!platform_sp)
return error;
}
```
I don't think we need to change this logic. So the fix of this test looks
reasonable.
https://github.com/llvm/llvm-project/pull/90580
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Install generated API headers into LLDB.framework (PR #90666)
@@ -71,6 +71,7 @@ endif()
# At configuration time, collect headers for the framework bundle and copy them
# into a staging directory. Later we can copy over the entire folder.
file(GLOB public_headers ${LLDB_SOURCE_DIR}/include/lldb/API/*.h)
+file(GLOB built_public_headers
${LLDB_FRAMEWORK_ABSOLUTE_BUILD_DIR}/../tools/lldb/include/lldb/API/*.h)
bulbazord wrote:
Yeah that is definitely incorrect for a standalone build. You could put the
directory into a CMake variable and use that instead of reconstructing it here.
Also nit: `built_public_headers` -> `generated_public_headers`?
https://github.com/llvm/llvm-project/pull/90666
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Support custom LLVM formatting for variables (PR #81196)
aaupov wrote: This diff broke buildbot: https://lab.llvm.org/buildbot/#/builders/68/builds/73367 https://github.com/llvm/llvm-project/pull/81196 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Install generated API headers into LLDB.framework (PR #90666)
@@ -71,6 +71,7 @@ endif()
# At configuration time, collect headers for the framework bundle and copy them
# into a staging directory. Later we can copy over the entire folder.
file(GLOB public_headers ${LLDB_SOURCE_DIR}/include/lldb/API/*.h)
+file(GLOB built_public_headers
${LLDB_FRAMEWORK_ABSOLUTE_BUILD_DIR}/../tools/lldb/include/lldb/API/*.h)
adrian-prantl wrote:
@bulbazord @JDevlieghere I'm pretty sure this is incorrect in a standalone
build. Do you have any idea how I could properly derive the LLDB_OBJ_ROOT that
contains API|Core|Target|... here?
https://github.com/llvm/llvm-project/pull/90666
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Install generated API headers into LLDB.framework (PR #90666)
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Adrian Prantl (adrian-prantl)
Changes
---
Full diff: https://github.com/llvm/llvm-project/pull/90666.diff
1 Files Affected:
- (modified) lldb/cmake/modules/LLDBFramework.cmake (+2)
``diff
diff --git a/lldb/cmake/modules/LLDBFramework.cmake
b/lldb/cmake/modules/LLDBFramework.cmake
index f915839f6b45a5..a461f3ee3c9c59 100644
--- a/lldb/cmake/modules/LLDBFramework.cmake
+++ b/lldb/cmake/modules/LLDBFramework.cmake
@@ -71,6 +71,7 @@ endif()
# At configuration time, collect headers for the framework bundle and copy them
# into a staging directory. Later we can copy over the entire folder.
file(GLOB public_headers ${LLDB_SOURCE_DIR}/include/lldb/API/*.h)
+file(GLOB built_public_headers
${LLDB_FRAMEWORK_ABSOLUTE_BUILD_DIR}/../tools/lldb/include/lldb/API/*.h)
file(GLOB root_public_headers ${LLDB_SOURCE_DIR}/include/lldb/lldb-*.h)
file(GLOB root_private_headers ${LLDB_SOURCE_DIR}/include/lldb/lldb-private*.h)
list(REMOVE_ITEM root_public_headers ${root_private_headers})
@@ -80,6 +81,7 @@ find_program(unifdef_EXECUTABLE unifdef)
set(lldb_header_staging ${CMAKE_CURRENT_BINARY_DIR}/FrameworkHeaders)
foreach(header
${public_headers}
+${built_public_headers}
${root_public_headers})
get_filename_component(basename ${header} NAME)
``
https://github.com/llvm/llvm-project/pull/90666
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Install generated API headers into LLDB.framework (PR #90666)
https://github.com/adrian-prantl created
https://github.com/llvm/llvm-project/pull/90666
None
>From 628576baf4dbf11efa56a079dde9759ccc7e988d Mon Sep 17 00:00:00 2001
From: Adrian Prantl
Date: Tue, 30 Apr 2024 13:59:39 -0700
Subject: [PATCH] Install generated API headers into LLDB.framework
---
lldb/cmake/modules/LLDBFramework.cmake | 2 ++
1 file changed, 2 insertions(+)
diff --git a/lldb/cmake/modules/LLDBFramework.cmake
b/lldb/cmake/modules/LLDBFramework.cmake
index f915839f6b45a5..a461f3ee3c9c59 100644
--- a/lldb/cmake/modules/LLDBFramework.cmake
+++ b/lldb/cmake/modules/LLDBFramework.cmake
@@ -71,6 +71,7 @@ endif()
# At configuration time, collect headers for the framework bundle and copy them
# into a staging directory. Later we can copy over the entire folder.
file(GLOB public_headers ${LLDB_SOURCE_DIR}/include/lldb/API/*.h)
+file(GLOB built_public_headers
${LLDB_FRAMEWORK_ABSOLUTE_BUILD_DIR}/../tools/lldb/include/lldb/API/*.h)
file(GLOB root_public_headers ${LLDB_SOURCE_DIR}/include/lldb/lldb-*.h)
file(GLOB root_private_headers ${LLDB_SOURCE_DIR}/include/lldb/lldb-private*.h)
list(REMOVE_ITEM root_public_headers ${root_private_headers})
@@ -80,6 +81,7 @@ find_program(unifdef_EXECUTABLE unifdef)
set(lldb_header_staging ${CMAKE_CURRENT_BINARY_DIR}/FrameworkHeaders)
foreach(header
${public_headers}
+${built_public_headers}
${root_public_headers})
get_filename_component(basename ${header} NAME)
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][DWARF] Delay struct/class/union definition DIE searching when parsing declaration DIEs. (PR #90663)
github-actions[bot] wrote:
:warning: C/C++ code formatter, clang-format found issues in your code.
:warning:
You can test this locally with the following command:
``bash
git-clang-format --diff cf49d077fd75278abc405c8c125f40a975c830b4
4e83099b593e66f12dc21be5fbac5279e03e --
lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h
lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDwo.cpp
lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDwo.h
lldb/source/Plugins/SymbolFile/DWARF/UniqueDWARFASTType.cpp
lldb/source/Plugins/SymbolFile/DWARF/UniqueDWARFASTType.h
``
View the diff from clang-format here.
``diff
diff --git a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
index 5a317db7e7..c7069550cc 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
@@ -1689,12 +1689,10 @@ DWARFDIE SymbolFileDWARF::FindDefinitionDIE(const
DWARFDIE ) {
// and this DIE isn't the complete definition (we checked
// is_complete_objc_class above and know it is false), so the real
// definition is in here somewhere
- type_sp =
- FindCompleteObjCDefinitionTypeForDIE(die, attrs.name, true);
+ type_sp = FindCompleteObjCDefinitionTypeForDIE(die, attrs.name, true);
if (!type_sp) {
-SymbolFileDWARFDebugMap *debug_map_symfile =
-GetDebugMapSymfile();
+SymbolFileDWARFDebugMap *debug_map_symfile = GetDebugMapSymfile();
if (debug_map_symfile) {
// We weren't able to find a full declaration in this DWARF,
// see if we have a declaration anywhere else...
``
https://github.com/llvm/llvm-project/pull/90663
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][DWARF] Delay struct/class/union definition DIE searching when parsing declaration DIEs. (PR #90663)
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Zequan Wu (ZequanWu)
Changes
This is the implementation for
https://discourse.llvm.org/t/rfc-delay-definition-die-searching-when-parse-a-declaration-die-for-record-type/78526.
Motivation
Currently, lldb eagerly searches for definition DIE when parsing a declaration
DIE for struct/class/union definition DIE. It will search for all definition
DIEs with the same unqualified name (just `DW_AT_name` ) and then find out
those DIEs with same fully qualified name. Then lldb will try to resolve those
DIEs to create the Types from definition DIEs. It works fine most time.
However, when built with `-gsimple-template-names`, the search graph expands
very quickly, because for the specialized-template classes, they don’t have
template parameter names encoded inside `DW_AT_name`. They have
`DW_TAG_template_type_parameter` to reference the types used as template
parameters. In order to identify if a definition DIE matches a declaration DIE,
lldb needs to resolve all template parameter types first and those template
parameter types might be template classes as well, and so on… So, the search
graph explodes, causing a lot unnecessary searching/type-resolving to just get
the fully qualified names for a specialized-template class. This causes lldb
stack overflow for us internally on template-heavy libraries.
Implementation
Instead of searching for definition DIEs when parsing declaration DIEs, we
always construct the record type from the DIE regardless if it's definition or
declaration. At the same time, use a map `GetDeclarationDIEToDefinitionDIE()`
to track the mapping from declarations/definition DIEs to the unique definition
DIE. The process of searching for definition DIE is refactored to
`SymbolFileDWARF::FindDefinitionDIE` which is invoked when 1) completing the
type on `SymbolFileDWARF::CompleteType`. 2) the record type needs to start its
definition as a containing type so that nested classes can be added into it in
`PrepareContextToReceiveMembers`.
The key difference is `SymbolFileDWARF::ResolveType` return a `Type*` that
might be created from declaration DIE, which means it hasn't starts its
definition yet. We also need to change according in places where we want the
type to start definition, like `PrepareContextToReceiveMembers` (I'm not aware
of any other places, but this should be a simple call to
`SymbolFileDWARF::FindDefinitionDIE`)
Result
It fixes the stack overflow of lldb for the internal binary built with simple
template name. When constructing the fully qualified name built with
`-gsimple-template-names`, it gets the name of the type parameter by resolving
the referenced DIE, which might be a declaration (we won't try to search for
the definition DIE to just get the name).
---
Patch is 34.35 KiB, truncated to 20.00 KiB below, full version:
https://github.com/llvm/llvm-project/pull/90663.diff
7 Files Affected:
- (modified) lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
(+107-163)
- (modified) lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp (+103-2)
- (modified) lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h (+14)
- (modified) lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDwo.cpp (+5)
- (modified) lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDwo.h (+2)
- (modified) lldb/source/Plugins/SymbolFile/DWARF/UniqueDWARFASTType.cpp
(+50-45)
- (modified) lldb/source/Plugins/SymbolFile/DWARF/UniqueDWARFASTType.h (+15-6)
``diff
diff --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
index bea11e0e3840af..7ad661c9a9d49b 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
@@ -252,7 +252,8 @@ static void ForcefullyCompleteType(CompilerType type) {
static void PrepareContextToReceiveMembers(TypeSystemClang ,
ClangASTImporter _importer,
clang::DeclContext *decl_ctx,
- DWARFDIE die,
+ const DWARFDIE _ctx_die,
+ const DWARFDIE ,
const char *type_name_cstr) {
auto *tag_decl_ctx = clang::dyn_cast(decl_ctx);
if (!tag_decl_ctx)
@@ -279,6 +280,13 @@ static void PrepareContextToReceiveMembers(TypeSystemClang
,
type_name_cstr ? type_name_cstr : "", die.GetOffset());
}
+ // By searching for the definition DIE of the decl_ctx type, we will either:
+ // 1. Found the the definition DIE and start its definition with
+ // TypeSystemClang::StartTagDeclarationDefinition.
+ // 2. Unable to find it, then need to forcefully complete it.
+ die.GetDWARF()->FindDefinitionDIE(decl_ctx_die);
+ if
[Lldb-commits] [lldb] [lldb][DWARF] Delay struct/class/union definition DIE searching when parsing declaration DIEs. (PR #90663)
https://github.com/ZequanWu ready_for_review https://github.com/llvm/llvm-project/pull/90663 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][DWARF] Delay struct/class/union definition DIE searching when parsing declaration DIEs. (PR #90663)
https://github.com/ZequanWu created
https://github.com/llvm/llvm-project/pull/90663
This is the implementation for
https://discourse.llvm.org/t/rfc-delay-definition-die-searching-when-parse-a-declaration-die-for-record-type/78526.
Motivation
Currently, lldb eagerly searches for definition DIE when parsing a declaration
DIE for struct/class/union definition DIE. It will search for all definition
DIEs with the same unqualified name (just `DW_AT_name` ) and then find out
those DIEs with same fully qualified name. Then lldb will try to resolve those
DIEs to create the Types from definition DIEs. It works fine most time.
However, when built with `-gsimple-template-names`, the search graph expands
very quickly, because for the specialized-template classes, they don’t have
template parameter names encoded inside `DW_AT_name`. They have
`DW_TAG_template_type_parameter` to reference the types used as template
parameters. In order to identify if a definition DIE matches a declaration DIE,
lldb needs to resolve all template parameter types first and those template
parameter types might be template classes as well, and so on… So, the search
graph explodes, causing a lot unnecessary searching/type-resolving to just get
the fully qualified names for a specialized-template class. This causes lldb
stack overflow for us internally on template-heavy libraries.
Implementation
Instead of searching for definition DIEs when parsing declaration DIEs, we
always construct the record type from the DIE regardless if it's definition or
declaration. At the same time, use a map `GetDeclarationDIEToDefinitionDIE()`
to track the mapping from declarations/definition DIEs to the unique definition
DIE. The process of searching for definition DIE is refactored to
`SymbolFileDWARF::FindDefinitionDIE` which is invoked when 1) completing the
type on `SymbolFileDWARF::CompleteType`. 2) the record type needs to start its
definition as a containing type so that nested classes can be added into it in
`PrepareContextToReceiveMembers`.
The key difference is `SymbolFileDWARF::ResolveType` return a `Type*` that
might be created from declaration DIE, which means it hasn't starts its
definition yet. We also need to change according in places where we want the
type to start definition, like `PrepareContextToReceiveMembers` (I'm not aware
of any other places, but this should be a simple call to
`SymbolFileDWARF::FindDefinitionDIE`)
Result
It fixes the stack overflow of lldb for the internal binary built with simple
template name. When constructing the fully qualified name built with
`-gsimple-template-names`, it gets the name of the type parameter by resolving
the referenced DIE, which might be a declaration (we won't try to search for
the definition DIE to just get the name).
>From 4e83099b593e66f12dc21be5fbac5279e03e Mon Sep 17 00:00:00 2001
From: Zequan Wu
Date: Tue, 30 Apr 2024 16:23:11 -0400
Subject: [PATCH] [lldb][DWARF] Delay struct/class/union definition DIE
searching when parsing declaration DIEs.
---
.../SymbolFile/DWARF/DWARFASTParserClang.cpp | 270 +++---
.../SymbolFile/DWARF/SymbolFileDWARF.cpp | 105 ++-
.../SymbolFile/DWARF/SymbolFileDWARF.h| 14 +
.../SymbolFile/DWARF/SymbolFileDWARFDwo.cpp | 5 +
.../SymbolFile/DWARF/SymbolFileDWARFDwo.h | 2 +
.../SymbolFile/DWARF/UniqueDWARFASTType.cpp | 95 +++---
.../SymbolFile/DWARF/UniqueDWARFASTType.h | 21 +-
7 files changed, 296 insertions(+), 216 deletions(-)
diff --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
index bea11e0e3840af..7ad661c9a9d49b 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
@@ -252,7 +252,8 @@ static void ForcefullyCompleteType(CompilerType type) {
static void PrepareContextToReceiveMembers(TypeSystemClang ,
ClangASTImporter _importer,
clang::DeclContext *decl_ctx,
- DWARFDIE die,
+ const DWARFDIE _ctx_die,
+ const DWARFDIE ,
const char *type_name_cstr) {
auto *tag_decl_ctx = clang::dyn_cast(decl_ctx);
if (!tag_decl_ctx)
@@ -279,6 +280,13 @@ static void PrepareContextToReceiveMembers(TypeSystemClang
,
type_name_cstr ? type_name_cstr : "", die.GetOffset());
}
+ // By searching for the definition DIE of the decl_ctx type, we will either:
+ // 1. Found the the definition DIE and start its definition with
+ // TypeSystemClang::StartTagDeclarationDefinition.
+ // 2. Unable to find it, then need to forcefully complete it.
+ die.GetDWARF()->FindDefinitionDIE(decl_ctx_die);
+ if
[Lldb-commits] [lldb] SBDebugger: Add new APIs `AddDestroyCallback` and `RemoveDestroyCallback` (PR #89868)
https://github.com/royitaqi edited https://github.com/llvm/llvm-project/pull/89868 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][NFCI] Unify DW_TAG -> string conversions (PR #90657)
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Alex Langford (bulbazord)
Changes
The high level goal is to have 1 way of converting a DW_TAG value into a
human-readable string.
There are 3 ways this change accomplishes that:
1.) Changing DW_TAG_value_to_name to not create custom error strings.
The way it was doing this is error-prone: Specifically, it was using a
function-local static char buffer and handing out a pointer to it.
Initialization of this is thread-safe, but mutating it is definitely
not. Multiple threads that want to call this function could step on
each others toes. The implementation in this patch sidesteps the issue
by just returning a StringRef with no mention of the tag value in it.
2.) Changing all uses of DW_TAG_value_to_name to log the value of the
tag since the function doesn't create a string with the value in it
anymore.
3.) Removing `DWARFBaseDIE::GetTagAsCString()`. Callers should call
DW_TAG_value_to_name on the tag directly.
---
Full diff: https://github.com/llvm/llvm-project/pull/90657.diff
6 Files Affected:
- (modified) lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
(+32-30)
- (modified) lldb/source/Plugins/SymbolFile/DWARF/DWARFBaseDIE.cpp (-4)
- (modified) lldb/source/Plugins/SymbolFile/DWARF/DWARFBaseDIE.h (-2)
- (modified) lldb/source/Plugins/SymbolFile/DWARF/DWARFDefines.cpp (+5-11)
- (modified) lldb/source/Plugins/SymbolFile/DWARF/DWARFDefines.h (+1-1)
- (modified) lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp (+33-30)
``diff
diff --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
index bea11e0e3840af..f8101aba5c6277 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
@@ -452,9 +452,9 @@ TypeSP DWARFASTParserClang::ParseTypeFromDWARF(const
SymbolContext ,
log,
"DWARFASTParserClang::ParseTypeFromDWARF "
"(die = {0:x16}, decl_ctx = {1:p} (die "
-"{2:x16})) {3} name = '{4}')",
+"{2:x16})) {3} ({4}) name = '{5}')",
die.GetOffset(), static_cast(context), context_die.GetOffset(),
-die.GetTagAsCString(), die.GetName());
+DW_TAG_value_to_name(die.Tag()), die.Tag(), die.GetName());
}
Type *type_ptr = dwarf->GetDIEToType().lookup(die.GetDIE());
@@ -765,9 +765,10 @@ DWARFASTParserClang::ParseTypeModifier(const SymbolContext
,
if (log)
dwarf->GetObjectFile()->GetModule()->LogMessage(
log,
-"SymbolFileDWARF::ParseType (die = {0:x16}) {1} '{2}' "
+"SymbolFileDWARF::ParseType (die = {0:x16}) {1} ({2}) '{3}' "
"is Objective-C 'id' built-in type.",
-die.GetOffset(), die.GetTagAsCString(), die.GetName());
+die.GetOffset(), DW_TAG_value_to_name(die.Tag()), die.Tag(),
+die.GetName());
clang_type = m_ast.GetBasicType(eBasicTypeObjCID);
encoding_data_type = Type::eEncodingIsUID;
attrs.type.Clear();
@@ -776,9 +777,10 @@ DWARFASTParserClang::ParseTypeModifier(const SymbolContext
,
if (log)
dwarf->GetObjectFile()->GetModule()->LogMessage(
log,
-"SymbolFileDWARF::ParseType (die = {0:x16}) {1} '{2}' "
+"SymbolFileDWARF::ParseType (die = {0:x16}) {1} ({2}) '{3}' "
"is Objective-C 'Class' built-in type.",
-die.GetOffset(), die.GetTagAsCString(), die.GetName());
+die.GetOffset(), DW_TAG_value_to_name(die.Tag()), die.Tag(),
+die.GetName());
clang_type = m_ast.GetBasicType(eBasicTypeObjCClass);
encoding_data_type = Type::eEncodingIsUID;
attrs.type.Clear();
@@ -787,9 +789,10 @@ DWARFASTParserClang::ParseTypeModifier(const SymbolContext
,
if (log)
dwarf->GetObjectFile()->GetModule()->LogMessage(
log,
-"SymbolFileDWARF::ParseType (die = {0:x16}) {1} '{2}' "
+"SymbolFileDWARF::ParseType (die = {0:x16}) {1} ({2}) '{3}' "
"is Objective-C 'selector' built-in type.",
-die.GetOffset(), die.GetTagAsCString(), die.GetName());
+die.GetOffset(), DW_TAG_value_to_name(die.Tag()), die.Tag(),
+die.GetName());
clang_type = m_ast.GetBasicType(eBasicTypeObjCSel);
encoding_data_type = Type::eEncodingIsUID;
attrs.type.Clear();
@@ -808,10 +811,10 @@ DWARFASTParserClang::ParseTypeModifier(const
SymbolContext ,
if (log)
dwarf->GetObjectFile()->GetModule()->LogMessage(
log,
- "SymbolFileDWARF::ParseType (die = {0:x16}) {1} "
- "'{2}' is 'objc_object*', which we overrode to "
- "'id'.",
-
[Lldb-commits] [lldb] [lldb][NFCI] Unify DW_TAG -> string conversions (PR #90657)
https://github.com/bulbazord created
https://github.com/llvm/llvm-project/pull/90657
The high level goal is to have 1 way of converting a DW_TAG value into a
human-readable string.
There are 3 ways this change accomplishes that:
1.) Changing DW_TAG_value_to_name to not create custom error strings.
The way it was doing this is error-prone: Specifically, it was using a
function-local static char buffer and handing out a pointer to it.
Initialization of this is thread-safe, but mutating it is definitely
not. Multiple threads that want to call this function could step on
each others toes. The implementation in this patch sidesteps the issue
by just returning a StringRef with no mention of the tag value in it.
2.) Changing all uses of DW_TAG_value_to_name to log the value of the
tag since the function doesn't create a string with the value in it
anymore.
3.) Removing `DWARFBaseDIE::GetTagAsCString()`. Callers should call
DW_TAG_value_to_name on the tag directly.
>From bdcb733bcfd64e23edac44ae0a21897720084879 Mon Sep 17 00:00:00 2001
From: Alex Langford
Date: Tue, 30 Apr 2024 11:30:22 -0700
Subject: [PATCH] [lldb][NFCI] Unify DW_TAG -> string conversions
The high level goal is to have 1 way of converting a DW_TAG value into a
human-readable string.
There are 3 ways this change accomplishes that:
1.) Changing DW_TAG_value_to_name to not create custom error strings.
The way it was doing this is error-prone: Specifically, it was using a
function-local static char buffer and handing out a pointer to it.
Initialization of this is thread-safe, but mutating it is definitely
not. Multiple threads that want to call this function could step on
each others toes. The implementation in this patch sidesteps the issue
by just returning a StringRef with no mention of the tag value in it.
2.) Changing all uses of DW_TAG_value_to_name to log the value of the
tag since the function doesn't create a string with the value in it
anymore.
3.) Removing `DWARFBaseDIE::GetTagAsCString()`. Callers should call
DW_TAG_value_to_name on the tag directly.
---
.../SymbolFile/DWARF/DWARFASTParserClang.cpp | 62 +-
.../Plugins/SymbolFile/DWARF/DWARFBaseDIE.cpp | 4 --
.../Plugins/SymbolFile/DWARF/DWARFBaseDIE.h | 2 -
.../Plugins/SymbolFile/DWARF/DWARFDefines.cpp | 16 ++---
.../Plugins/SymbolFile/DWARF/DWARFDefines.h | 2 +-
.../SymbolFile/DWARF/SymbolFileDWARF.cpp | 63 ++-
6 files changed, 71 insertions(+), 78 deletions(-)
diff --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
index bea11e0e3840af..f8101aba5c6277 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
@@ -452,9 +452,9 @@ TypeSP DWARFASTParserClang::ParseTypeFromDWARF(const
SymbolContext ,
log,
"DWARFASTParserClang::ParseTypeFromDWARF "
"(die = {0:x16}, decl_ctx = {1:p} (die "
-"{2:x16})) {3} name = '{4}')",
+"{2:x16})) {3} ({4}) name = '{5}')",
die.GetOffset(), static_cast(context), context_die.GetOffset(),
-die.GetTagAsCString(), die.GetName());
+DW_TAG_value_to_name(die.Tag()), die.Tag(), die.GetName());
}
Type *type_ptr = dwarf->GetDIEToType().lookup(die.GetDIE());
@@ -765,9 +765,10 @@ DWARFASTParserClang::ParseTypeModifier(const SymbolContext
,
if (log)
dwarf->GetObjectFile()->GetModule()->LogMessage(
log,
-"SymbolFileDWARF::ParseType (die = {0:x16}) {1} '{2}' "
+"SymbolFileDWARF::ParseType (die = {0:x16}) {1} ({2}) '{3}' "
"is Objective-C 'id' built-in type.",
-die.GetOffset(), die.GetTagAsCString(), die.GetName());
+die.GetOffset(), DW_TAG_value_to_name(die.Tag()), die.Tag(),
+die.GetName());
clang_type = m_ast.GetBasicType(eBasicTypeObjCID);
encoding_data_type = Type::eEncodingIsUID;
attrs.type.Clear();
@@ -776,9 +777,10 @@ DWARFASTParserClang::ParseTypeModifier(const SymbolContext
,
if (log)
dwarf->GetObjectFile()->GetModule()->LogMessage(
log,
-"SymbolFileDWARF::ParseType (die = {0:x16}) {1} '{2}' "
+"SymbolFileDWARF::ParseType (die = {0:x16}) {1} ({2}) '{3}' "
"is Objective-C 'Class' built-in type.",
-die.GetOffset(), die.GetTagAsCString(), die.GetName());
+die.GetOffset(), DW_TAG_value_to_name(die.Tag()), die.Tag(),
+die.GetName());
clang_type = m_ast.GetBasicType(eBasicTypeObjCClass);
encoding_data_type = Type::eEncodingIsUID;
attrs.type.Clear();
@@ -787,9 +789,10 @@ DWARFASTParserClang::ParseTypeModifier(const SymbolContext
,
if (log)
[Lldb-commits] [lldb] 5f88f0c - [lldb] Fix a warning
Author: Kazu Hirata
Date: 2024-04-30T12:10:54-07:00
New Revision: 5f88f0c63fa75169665732a3377f5bb3fef6256d
URL:
https://github.com/llvm/llvm-project/commit/5f88f0c63fa75169665732a3377f5bb3fef6256d
DIFF:
https://github.com/llvm/llvm-project/commit/5f88f0c63fa75169665732a3377f5bb3fef6256d.diff
LOG: [lldb] Fix a warning
This patch fixes:
third-party/unittest/googletest/include/gtest/gtest.h:1379:11:
error: comparison of integers of different signs: 'const unsigned
int' and 'const int' [-Werror,-Wsign-compare]
Added:
Modified:
lldb/unittests/SymbolFile/DWARF/DWARFASTParserClangTests.cpp
Removed:
diff --git a/lldb/unittests/SymbolFile/DWARF/DWARFASTParserClangTests.cpp
b/lldb/unittests/SymbolFile/DWARF/DWARFASTParserClangTests.cpp
index f7a4b8f1ac59be..ee90855437a71e 100644
--- a/lldb/unittests/SymbolFile/DWARF/DWARFASTParserClangTests.cpp
+++ b/lldb/unittests/SymbolFile/DWARF/DWARFASTParserClangTests.cpp
@@ -417,9 +417,9 @@ TEST_F(DWARFASTParserClangTests, TestPtrAuthParsing) {
lldb::TypeSP type_sp =
ast_parser.ParseTypeFromDWARF(sc, ptrauth_type, _type);
CompilerType compiler_type = type_sp->GetForwardCompilerType();
- ASSERT_EQ(compiler_type.GetPtrAuthKey(), 0);
+ ASSERT_EQ(compiler_type.GetPtrAuthKey(), 0U);
ASSERT_EQ(compiler_type.GetPtrAuthAddressDiversity(), false);
- ASSERT_EQ(compiler_type.GetPtrAuthDiscriminator(), 42);
+ ASSERT_EQ(compiler_type.GetPtrAuthDiscriminator(), 42U);
}
struct ExtractIntFromFormValueTest : public testing::Test {
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Fix test_exit_status_message_sigterm test. (PR #90223)
https://github.com/mbucko updated https://github.com/llvm/llvm-project/pull/90223 >From bb166a95bafc74860d78da0dedb5760c579cae48 Mon Sep 17 00:00:00 2001 From: Miro Bucko Date: Fri, 26 Apr 2024 08:17:26 -0700 Subject: [PATCH] [lldb-dap] Fix test_exit_status_message_sigterm test. Summary: 'test_exit_status_message_sigterm' is failing due to 'psutil' dependency introduced in PR #89405. This fix removes 'deque' dependency and checks if 'psutil' can be imported before running the test. If 'psutil' cannot be imported, it emits a warning and skips the test. Test Plan: ./bin/llvm-lit -sv /path-to-llvm-project/lldb/test/API/tools/lldb-dap/console/TestDAP_console.py --filter=tools/lldb-dap/console/TestDAP_console.py Reviewers: @jeffreytan81,@clayborg,@kusmour, @JDevlieghere,@walter-erquinigo Subscribers: Tasks: lldb-dap Tags: --- .../tools/lldb-dap/console/TestDAP_console.py | 20 +-- 1 file changed, 14 insertions(+), 6 deletions(-) diff --git a/lldb/test/API/tools/lldb-dap/console/TestDAP_console.py b/lldb/test/API/tools/lldb-dap/console/TestDAP_console.py index 8f456aaf890c7f..8769f39633e62f 100644 --- a/lldb/test/API/tools/lldb-dap/console/TestDAP_console.py +++ b/lldb/test/API/tools/lldb-dap/console/TestDAP_console.py @@ -4,17 +4,15 @@ import dap_server import lldbdap_testcase -import psutil -from collections import deque from lldbsuite.test import lldbutil from lldbsuite.test.decorators import * from lldbsuite.test.lldbtest import * -def get_subprocess(process_name): -queue = deque([psutil.Process(os.getpid())]) +def get_subprocess(root_process, process_name): +queue = [root_process] while queue: -process = queue.popleft() +process = queue.pop() if process.name() == process_name: return process queue.extend(process.children()) @@ -131,7 +129,17 @@ def test_exit_status_message_sigterm(self): process_name = ( "debugserver" if platform.system() in ["Darwin"] else "lldb-server" ) -process = get_subprocess(process_name) + +try: +import psutil +except ImportError: +print( +"psutil not installed, please install using 'pip install psutil'. " +"Skipping test_exit_status_message_sigterm test.", +file=sys.stderr, +) +return +process = get_subprocess(psutil.Process(os.getpid()), process_name) process.terminate() process.wait() ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Fix test_exit_status_message_sigterm test. (PR #90223)
https://github.com/jeffreytan81 approved this pull request. Quick accept to unblock the build break. Feel free to follow-up in future patches for better solution. https://github.com/llvm/llvm-project/pull/90223 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Add a new SBExpressionOptions::SetLanguage() API (NFCI) (PR #89981)
JDevlieghere wrote: > Thanks for the explanation! What kind of tool reads this file? One such tool is SWIG, which happens to support macro expansion, but we have other tools downstream that don't. > It's still weird to use tblgen to process non-td files imho. We have a bunch > of places that run python scripts as part of the build > (clang/utils/bundle_resources.py, > clang/lib/Tooling/DumpTool/generate_cxx_src_locs.py, > compiler-rt/lib/sanitizer_common/scripts/gen_dynamic_list.py, > clang-tools-extra/clangd/quality/CompletionModelCodegen.py) – maybe that > could work here? Yeah I agree and that's my fault for suggesting it in the first place to Adrian. We considered Python but weren't sure it was a hard build dependency (even though LLDB relies on it extensively, you can actually turn it off with a CMake flag). If that's the case then that's certainly a viable option. https://github.com/llvm/llvm-project/pull/89981 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Add a new SBExpressionOptions::SetLanguage() API (NFCI) (PR #89981)
bulbazord wrote: This doesn't actually copy `SBLanguages.h` into the framework, so this breaks the framework. These tests now fail: ``` Unresolved Tests (5): lldb-api :: api/check_public_api_headers/TestPublicAPIHeaders.py lldb-api :: api/multiple-debuggers/TestMultipleDebuggers.py lldb-api :: api/multiple-targets/TestMultipleTargets.py lldb-api :: api/multithreaded/TestMultithreaded.py lldb-api :: functionalities/plugins/command_plugin/TestPluginCommands.py ``` https://github.com/llvm/llvm-project/pull/89981 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Support custom LLVM formatting for variables (PR #81196)
https://github.com/kastiglione closed https://github.com/llvm/llvm-project/pull/81196 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] 7a8d15e - [lldb] Support custom LLVM formatting for variables (#81196)
Author: Dave Lee
Date: 2024-04-30T10:45:10-07:00
New Revision: 7a8d15e919dde70118dbfa34e927be1705ded67d
URL:
https://github.com/llvm/llvm-project/commit/7a8d15e919dde70118dbfa34e927be1705ded67d
DIFF:
https://github.com/llvm/llvm-project/commit/7a8d15e919dde70118dbfa34e927be1705ded67d.diff
LOG: [lldb] Support custom LLVM formatting for variables (#81196)
Adds support for applying LLVM formatting to variables.
The reason for this is to support cases such as the following.
Let's say you have two separate bytes that you want to print as a
combined hex value. Consider the following summary string:
```
${var.byte1%x}${var.byte2%x}
```
The output of this will be: `0x120x34`. That is, a `0x` prefix is
unconditionally applied to each byte. This is unlike printf formatting
where you must include the `0x` yourself.
Currently, there's no way to do this with summary strings, instead
you'll need a summary provider in python or c++.
This change introduces formatting support using LLVM's formatter system.
This allows users to achieve the desired custom formatting using:
```
${var.byte1:x-}${var.byte2:x-}
```
Here, each variable is suffixed with `:x-`. This is passed to the LLVM
formatter as `{0:x-}`. For integer values, `x` declares the output as
hex, and `-` declares that no `0x` prefix is to be used. Further, one
could write:
```
${var.byte1:x-2}${var.byte2:x-2}
```
Where the added `2` results in these bytes being written with a minimum
of 2 digits.
An alternative considered was to add a new format specifier that would
print hex values without the `0x` prefix. The reason that approach was
not taken is because in addition to forcing a `0x` prefix, hex values
are also forced to use leading zeros. This approach lets the user have
full control over formatting.
Added:
lldb/test/API/functionalities/data-formatter/custom-printf-summary/Makefile
lldb/test/API/functionalities/data-formatter/custom-printf-summary/TestCustomSummaryLLVMFormat.py
lldb/test/API/functionalities/data-formatter/custom-printf-summary/main.c
Modified:
lldb/docs/use/variable.rst
lldb/source/Core/FormatEntity.cpp
Removed:
diff --git a/lldb/docs/use/variable.rst b/lldb/docs/use/variable.rst
index 8eaed6405315b4..e9175b25336ba9 100644
--- a/lldb/docs/use/variable.rst
+++ b/lldb/docs/use/variable.rst
@@ -460,6 +460,15 @@ summary strings, regardless of the format they have
applied to their types. To
do that, you can use %format inside an expression path, as in ${var.x->x%u},
which would display the value of x as an unsigned integer.
+Additionally, custom output can be achieved by using an LLVM format string,
+commencing with the ``:`` marker. To illustrate, compare ``${var.byte%x}`` and
+``${var.byte:x-}``. The former uses lldb's builtin hex formatting (``x``),
+which unconditionally inserts a ``0x`` prefix, and also zero pads the value to
+match the size of the type. The latter uses ``llvm::formatv`` formatting
+(``:x-``), and will print only the hex value, with no ``0x`` prefix, and no
+padding. This raw control is useful when composing multiple pieces into a
+larger whole.
+
You can also use some other special format markers, not available for formats
themselves, but which carry a special meaning when used in this context:
diff --git a/lldb/source/Core/FormatEntity.cpp
b/lldb/source/Core/FormatEntity.cpp
index ba62e26252591f..da5b1cfce74ac8 100644
--- a/lldb/source/Core/FormatEntity.cpp
+++ b/lldb/source/Core/FormatEntity.cpp
@@ -57,6 +57,7 @@
#include "llvm/ADT/STLExtras.h"
#include "llvm/ADT/StringRef.h"
#include "llvm/Support/Compiler.h"
+#include "llvm/Support/Regex.h"
#include "llvm/TargetParser/Triple.h"
#include
@@ -658,6 +659,38 @@ static char ConvertValueObjectStyleToChar(
return '\0';
}
+static llvm::Regex LLVMFormatPattern{"x[-+]?\\d*|n|d",
llvm::Regex::IgnoreCase};
+
+static bool DumpValueWithLLVMFormat(Stream , llvm::StringRef options,
+ValueObject ) {
+ std::string formatted;
+ std::string llvm_format = ("{0:" + options + "}").str();
+
+ // Options supported by format_provider for integral arithmetic types.
+ // See table in FormatProviders.h.
+
+ auto type_info = valobj.GetTypeInfo();
+ if (type_info & eTypeIsInteger && LLVMFormatPattern.match(options)) {
+if (type_info & eTypeIsSigned) {
+ bool success = false;
+ int64_t integer = valobj.GetValueAsSigned(0, );
+ if (success)
+formatted = llvm::formatv(llvm_format.data(), integer);
+} else {
+ bool success = false;
+ uint64_t integer = valobj.GetValueAsUnsigned(0, );
+ if (success)
+formatted = llvm::formatv(llvm_format.data(), integer);
+}
+ }
+
+ if (formatted.empty())
+return false;
+
+ s.Write(formatted.data(), formatted.size());
+ return true;
+}
+
static bool DumpValue(Stream , const SymbolContext *sc,
[Lldb-commits] [lldb] [LLDB][ELF] Fix section unification to not just use names. (PR #90099)
https://github.com/JDevlieghere approved this pull request. Looks good to me as well. https://github.com/llvm/llvm-project/pull/90099 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][Docs] Various style improvements to the tutorial (PR #90594)
JDevlieghere wrote: > > Always refer to lldb as lldb not LLDB, to match what the user sees on the > > command line. > > If this were any other doc I'd say it should always be LLDB and GDB as that's > the projects' branding. In this doc I think it's better to imagine the user > is looking at side by side command lines. I'm not sure I follow that reasoning. In all fairness I might be biased as I try to consistently use "LLDB" unless I'm referring tot the binary or the prompt. Ignoring things like `(lldb)`, `lldb-` and `lldb.`, it looks like the docs favor "LLDB" as well. ``` $ rg 'LLDB' | wc -l 605 $ rg 'lldb' | awk '!/\(lldb\)/ && !/lldb\./ && !/lldb-/' | wc -l 362 ``` Personally I'd lean towards more consistency. https://github.com/llvm/llvm-project/pull/90594 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Support custom LLVM formatting for variables (PR #81196)
https://github.com/kastiglione updated
https://github.com/llvm/llvm-project/pull/81196
>From 81a2034ff2b41e30a1f5b82c86b4d5d4c429ed52 Mon Sep 17 00:00:00 2001
From: Dave Lee
Date: Thu, 8 Feb 2024 13:59:12 -0800
Subject: [PATCH 1/9] [lldb] Support custom printf formatting for variables
---
lldb/source/Core/FormatEntity.cpp | 25 +++--
1 file changed, 23 insertions(+), 2 deletions(-)
diff --git a/lldb/source/Core/FormatEntity.cpp
b/lldb/source/Core/FormatEntity.cpp
index fa5eadc6ff4e9a..0e929203935304 100644
--- a/lldb/source/Core/FormatEntity.cpp
+++ b/lldb/source/Core/FormatEntity.cpp
@@ -883,8 +883,29 @@ static bool DumpValue(Stream , const SymbolContext *sc,
}
if (!is_array_range) {
-LLDB_LOGF(log,
- "[Debugger::FormatPrompt] dumping ordinary printable output");
+if (!entry.printf_format.empty()) {
+ auto type_info = target->GetTypeInfo();
+ if (type_info & eTypeIsInteger) {
+if (type_info & eTypeIsSigned) {
+ bool success = false;
+ auto integer = target->GetValueAsSigned(0, );
+ if (success) {
+LLDB_LOGF(log, "dumping using printf format");
+s.Printf(entry.printf_format.c_str(), integer);
+return true;
+ }
+} else {
+ bool success = false;
+ auto integer = target->GetValueAsUnsigned(0, );
+ if (success) {
+LLDB_LOGF(log, "dumping using printf format");
+s.Printf(entry.printf_format.c_str(), integer);
+return true;
+ }
+}
+ }
+}
+LLDB_LOGF(log, "dumping ordinary printable output");
return target->DumpPrintableRepresentation(s, val_obj_display,
custom_format);
} else {
>From 335ab1de4b39257e3bbb3bd969a0dd6991747558 Mon Sep 17 00:00:00 2001
From: Dave Lee
Date: Tue, 13 Feb 2024 13:26:35 -0800
Subject: [PATCH 2/9] Factor out DumpValueWithPrintf; Add test
---
lldb/source/Core/FormatEntity.cpp | 45 +++
.../custom-printf-summary/Makefile| 2 +
.../TestCustomPrintfSummary.py| 11 +
.../custom-printf-summary/main.c | 13 ++
4 files changed, 52 insertions(+), 19 deletions(-)
create mode 100644
lldb/test/API/functionalities/data-formatter/custom-printf-summary/Makefile
create mode 100644
lldb/test/API/functionalities/data-formatter/custom-printf-summary/TestCustomPrintfSummary.py
create mode 100644
lldb/test/API/functionalities/data-formatter/custom-printf-summary/main.c
diff --git a/lldb/source/Core/FormatEntity.cpp
b/lldb/source/Core/FormatEntity.cpp
index 0e929203935304..57a05507d844cf 100644
--- a/lldb/source/Core/FormatEntity.cpp
+++ b/lldb/source/Core/FormatEntity.cpp
@@ -658,6 +658,25 @@ static char ConvertValueObjectStyleToChar(
return '\0';
}
+static bool DumpValueWithPrintf(Stream , llvm::StringRef format,
+ValueObject ) {
+ auto type_info = target.GetTypeInfo();
+ if (type_info & eTypeIsInteger) {
+if (type_info & eTypeIsSigned) {
+ if (auto integer = target.GetValueAsSigned()) {
+s.Printf(format.data(), *integer);
+return true;
+ }
+} else {
+ if (auto integer = target.GetValueAsUnsigned()) {
+s.Printf(format.data(), *integer);
+return true;
+ }
+}
+ }
+ return false;
+}
+
static bool DumpValue(Stream , const SymbolContext *sc,
const ExecutionContext *exe_ctx,
const FormatEntity::Entry , ValueObject *valobj) {
@@ -884,25 +903,13 @@ static bool DumpValue(Stream , const SymbolContext *sc,
if (!is_array_range) {
if (!entry.printf_format.empty()) {
- auto type_info = target->GetTypeInfo();
- if (type_info & eTypeIsInteger) {
-if (type_info & eTypeIsSigned) {
- bool success = false;
- auto integer = target->GetValueAsSigned(0, );
- if (success) {
-LLDB_LOGF(log, "dumping using printf format");
-s.Printf(entry.printf_format.c_str(), integer);
-return true;
- }
-} else {
- bool success = false;
- auto integer = target->GetValueAsUnsigned(0, );
- if (success) {
-LLDB_LOGF(log, "dumping using printf format");
-s.Printf(entry.printf_format.c_str(), integer);
-return true;
- }
-}
+ if (DumpValueWithPrintf(s, entry.printf_format, *target)) {
+LLDB_LOGF(log, "dumping using printf format");
+return true;
+ } else {
+LLDB_LOG(log,
+ "unsupported printf format '{0}' - for type info flags {1}",
+ entry.printf_format, target->GetTypeInfo());
}
}
LLDB_LOGF(log, "dumping ordinary printable output");
diff --git
a/lldb/test/API/functionalities/data-formatter/custom-printf-summary/Makefile
[Lldb-commits] [lldb] [lldb] Support custom LLVM formatting for variables (PR #81196)
https://github.com/kastiglione updated
https://github.com/llvm/llvm-project/pull/81196
>From 81a2034ff2b41e30a1f5b82c86b4d5d4c429ed52 Mon Sep 17 00:00:00 2001
From: Dave Lee
Date: Thu, 8 Feb 2024 13:59:12 -0800
Subject: [PATCH 1/8] [lldb] Support custom printf formatting for variables
---
lldb/source/Core/FormatEntity.cpp | 25 +++--
1 file changed, 23 insertions(+), 2 deletions(-)
diff --git a/lldb/source/Core/FormatEntity.cpp
b/lldb/source/Core/FormatEntity.cpp
index fa5eadc6ff4e9a..0e929203935304 100644
--- a/lldb/source/Core/FormatEntity.cpp
+++ b/lldb/source/Core/FormatEntity.cpp
@@ -883,8 +883,29 @@ static bool DumpValue(Stream , const SymbolContext *sc,
}
if (!is_array_range) {
-LLDB_LOGF(log,
- "[Debugger::FormatPrompt] dumping ordinary printable output");
+if (!entry.printf_format.empty()) {
+ auto type_info = target->GetTypeInfo();
+ if (type_info & eTypeIsInteger) {
+if (type_info & eTypeIsSigned) {
+ bool success = false;
+ auto integer = target->GetValueAsSigned(0, );
+ if (success) {
+LLDB_LOGF(log, "dumping using printf format");
+s.Printf(entry.printf_format.c_str(), integer);
+return true;
+ }
+} else {
+ bool success = false;
+ auto integer = target->GetValueAsUnsigned(0, );
+ if (success) {
+LLDB_LOGF(log, "dumping using printf format");
+s.Printf(entry.printf_format.c_str(), integer);
+return true;
+ }
+}
+ }
+}
+LLDB_LOGF(log, "dumping ordinary printable output");
return target->DumpPrintableRepresentation(s, val_obj_display,
custom_format);
} else {
>From 335ab1de4b39257e3bbb3bd969a0dd6991747558 Mon Sep 17 00:00:00 2001
From: Dave Lee
Date: Tue, 13 Feb 2024 13:26:35 -0800
Subject: [PATCH 2/8] Factor out DumpValueWithPrintf; Add test
---
lldb/source/Core/FormatEntity.cpp | 45 +++
.../custom-printf-summary/Makefile| 2 +
.../TestCustomPrintfSummary.py| 11 +
.../custom-printf-summary/main.c | 13 ++
4 files changed, 52 insertions(+), 19 deletions(-)
create mode 100644
lldb/test/API/functionalities/data-formatter/custom-printf-summary/Makefile
create mode 100644
lldb/test/API/functionalities/data-formatter/custom-printf-summary/TestCustomPrintfSummary.py
create mode 100644
lldb/test/API/functionalities/data-formatter/custom-printf-summary/main.c
diff --git a/lldb/source/Core/FormatEntity.cpp
b/lldb/source/Core/FormatEntity.cpp
index 0e929203935304..57a05507d844cf 100644
--- a/lldb/source/Core/FormatEntity.cpp
+++ b/lldb/source/Core/FormatEntity.cpp
@@ -658,6 +658,25 @@ static char ConvertValueObjectStyleToChar(
return '\0';
}
+static bool DumpValueWithPrintf(Stream , llvm::StringRef format,
+ValueObject ) {
+ auto type_info = target.GetTypeInfo();
+ if (type_info & eTypeIsInteger) {
+if (type_info & eTypeIsSigned) {
+ if (auto integer = target.GetValueAsSigned()) {
+s.Printf(format.data(), *integer);
+return true;
+ }
+} else {
+ if (auto integer = target.GetValueAsUnsigned()) {
+s.Printf(format.data(), *integer);
+return true;
+ }
+}
+ }
+ return false;
+}
+
static bool DumpValue(Stream , const SymbolContext *sc,
const ExecutionContext *exe_ctx,
const FormatEntity::Entry , ValueObject *valobj) {
@@ -884,25 +903,13 @@ static bool DumpValue(Stream , const SymbolContext *sc,
if (!is_array_range) {
if (!entry.printf_format.empty()) {
- auto type_info = target->GetTypeInfo();
- if (type_info & eTypeIsInteger) {
-if (type_info & eTypeIsSigned) {
- bool success = false;
- auto integer = target->GetValueAsSigned(0, );
- if (success) {
-LLDB_LOGF(log, "dumping using printf format");
-s.Printf(entry.printf_format.c_str(), integer);
-return true;
- }
-} else {
- bool success = false;
- auto integer = target->GetValueAsUnsigned(0, );
- if (success) {
-LLDB_LOGF(log, "dumping using printf format");
-s.Printf(entry.printf_format.c_str(), integer);
-return true;
- }
-}
+ if (DumpValueWithPrintf(s, entry.printf_format, *target)) {
+LLDB_LOGF(log, "dumping using printf format");
+return true;
+ } else {
+LLDB_LOG(log,
+ "unsupported printf format '{0}' - for type info flags {1}",
+ entry.printf_format, target->GetTypeInfo());
}
}
LLDB_LOGF(log, "dumping ordinary printable output");
diff --git
a/lldb/test/API/functionalities/data-formatter/custom-printf-summary/Makefile
[Lldb-commits] [lldb] [LLDB][ELF] Fix section unification to not just use names. (PR #90099)
https://github.com/labath approved this pull request. https://github.com/llvm/llvm-project/pull/90099 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [clang] [compiler-rt] [libc] [libclc] [libcxxabi] [lld] [lldb] [llvm] [mlir] Add clarifying parenthesis around non-trivial conditions in ternary expressions. (PR #90391)
bulbazord wrote: LLDB changes look fine. https://github.com/llvm/llvm-project/pull/90391 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Support custom LLVM formatting for variables (PR #81196)
https://github.com/kastiglione updated
https://github.com/llvm/llvm-project/pull/81196
>From 81a2034ff2b41e30a1f5b82c86b4d5d4c429ed52 Mon Sep 17 00:00:00 2001
From: Dave Lee
Date: Thu, 8 Feb 2024 13:59:12 -0800
Subject: [PATCH 1/7] [lldb] Support custom printf formatting for variables
---
lldb/source/Core/FormatEntity.cpp | 25 +++--
1 file changed, 23 insertions(+), 2 deletions(-)
diff --git a/lldb/source/Core/FormatEntity.cpp
b/lldb/source/Core/FormatEntity.cpp
index fa5eadc6ff4e9a..0e929203935304 100644
--- a/lldb/source/Core/FormatEntity.cpp
+++ b/lldb/source/Core/FormatEntity.cpp
@@ -883,8 +883,29 @@ static bool DumpValue(Stream , const SymbolContext *sc,
}
if (!is_array_range) {
-LLDB_LOGF(log,
- "[Debugger::FormatPrompt] dumping ordinary printable output");
+if (!entry.printf_format.empty()) {
+ auto type_info = target->GetTypeInfo();
+ if (type_info & eTypeIsInteger) {
+if (type_info & eTypeIsSigned) {
+ bool success = false;
+ auto integer = target->GetValueAsSigned(0, );
+ if (success) {
+LLDB_LOGF(log, "dumping using printf format");
+s.Printf(entry.printf_format.c_str(), integer);
+return true;
+ }
+} else {
+ bool success = false;
+ auto integer = target->GetValueAsUnsigned(0, );
+ if (success) {
+LLDB_LOGF(log, "dumping using printf format");
+s.Printf(entry.printf_format.c_str(), integer);
+return true;
+ }
+}
+ }
+}
+LLDB_LOGF(log, "dumping ordinary printable output");
return target->DumpPrintableRepresentation(s, val_obj_display,
custom_format);
} else {
>From 335ab1de4b39257e3bbb3bd969a0dd6991747558 Mon Sep 17 00:00:00 2001
From: Dave Lee
Date: Tue, 13 Feb 2024 13:26:35 -0800
Subject: [PATCH 2/7] Factor out DumpValueWithPrintf; Add test
---
lldb/source/Core/FormatEntity.cpp | 45 +++
.../custom-printf-summary/Makefile| 2 +
.../TestCustomPrintfSummary.py| 11 +
.../custom-printf-summary/main.c | 13 ++
4 files changed, 52 insertions(+), 19 deletions(-)
create mode 100644
lldb/test/API/functionalities/data-formatter/custom-printf-summary/Makefile
create mode 100644
lldb/test/API/functionalities/data-formatter/custom-printf-summary/TestCustomPrintfSummary.py
create mode 100644
lldb/test/API/functionalities/data-formatter/custom-printf-summary/main.c
diff --git a/lldb/source/Core/FormatEntity.cpp
b/lldb/source/Core/FormatEntity.cpp
index 0e929203935304..57a05507d844cf 100644
--- a/lldb/source/Core/FormatEntity.cpp
+++ b/lldb/source/Core/FormatEntity.cpp
@@ -658,6 +658,25 @@ static char ConvertValueObjectStyleToChar(
return '\0';
}
+static bool DumpValueWithPrintf(Stream , llvm::StringRef format,
+ValueObject ) {
+ auto type_info = target.GetTypeInfo();
+ if (type_info & eTypeIsInteger) {
+if (type_info & eTypeIsSigned) {
+ if (auto integer = target.GetValueAsSigned()) {
+s.Printf(format.data(), *integer);
+return true;
+ }
+} else {
+ if (auto integer = target.GetValueAsUnsigned()) {
+s.Printf(format.data(), *integer);
+return true;
+ }
+}
+ }
+ return false;
+}
+
static bool DumpValue(Stream , const SymbolContext *sc,
const ExecutionContext *exe_ctx,
const FormatEntity::Entry , ValueObject *valobj) {
@@ -884,25 +903,13 @@ static bool DumpValue(Stream , const SymbolContext *sc,
if (!is_array_range) {
if (!entry.printf_format.empty()) {
- auto type_info = target->GetTypeInfo();
- if (type_info & eTypeIsInteger) {
-if (type_info & eTypeIsSigned) {
- bool success = false;
- auto integer = target->GetValueAsSigned(0, );
- if (success) {
-LLDB_LOGF(log, "dumping using printf format");
-s.Printf(entry.printf_format.c_str(), integer);
-return true;
- }
-} else {
- bool success = false;
- auto integer = target->GetValueAsUnsigned(0, );
- if (success) {
-LLDB_LOGF(log, "dumping using printf format");
-s.Printf(entry.printf_format.c_str(), integer);
-return true;
- }
-}
+ if (DumpValueWithPrintf(s, entry.printf_format, *target)) {
+LLDB_LOGF(log, "dumping using printf format");
+return true;
+ } else {
+LLDB_LOG(log,
+ "unsupported printf format '{0}' - for type info flags {1}",
+ entry.printf_format, target->GetTypeInfo());
}
}
LLDB_LOGF(log, "dumping ordinary printable output");
diff --git
a/lldb/test/API/functionalities/data-formatter/custom-printf-summary/Makefile
[Lldb-commits] [lldb] [lldb][Docs] Sort documented packets alphabetically (PR #90584)
https://github.com/JDevlieghere approved this pull request. https://github.com/llvm/llvm-project/pull/90584 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][Windows] Fixed unresolved test lldb-api python_api/debugger/TestDebuggerAPI.py (PR #90580)
https://github.com/bulbazord requested changes to this pull request. I don't think this is the right thing to do. `SBDebugger::CreateTarget` takes a `platform_name` argument which we're already setting to "remote-linux". If `target1.GetPlatform()` doesn't return the SBPlatform for `remote-linux` then I would think that's the actual bug. https://github.com/llvm/llvm-project/pull/90580 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Fix lock guads in PipePosix.cpp (PR #90572)
https://github.com/bulbazord commented: lgtm https://github.com/llvm/llvm-project/pull/90572 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] 4cd11c9 - Thread '--lldb-obj-root' through lldb-dotest for manual testing
Author: Adrian Prantl
Date: 2024-04-30T09:53:13-07:00
New Revision: 4cd11c986f78e19f53b3f3c92143b7b7c1ce54b1
URL:
https://github.com/llvm/llvm-project/commit/4cd11c986f78e19f53b3f3c92143b7b7c1ce54b1
DIFF:
https://github.com/llvm/llvm-project/commit/4cd11c986f78e19f53b3f3c92143b7b7c1ce54b1.diff
LOG: Thread '--lldb-obj-root' through lldb-dotest for manual testing
Added:
Modified:
lldb/utils/lldb-dotest/lldb-dotest.in
Removed:
diff --git a/lldb/utils/lldb-dotest/lldb-dotest.in
b/lldb/utils/lldb-dotest/lldb-dotest.in
index 022425591f4513..0e9648a6e6dc83 100755
--- a/lldb/utils/lldb-dotest/lldb-dotest.in
+++ b/lldb/utils/lldb-dotest/lldb-dotest.in
@@ -14,6 +14,7 @@ lldb_build_intel_pt = "@LLDB_BUILD_INTEL_PT@"
lldb_framework_dir = "@LLDB_FRAMEWORK_DIR_CONFIGURED@"
lldb_libs_dir = "@LLDB_LIBS_DIR_CONFIGURED@"
llvm_tools_dir = "@LLVM_TOOLS_DIR_CONFIGURED@"
+lldb_obj_root = "@LLDB_BINARY_DIR@"
has_libcxx = @LLDB_HAS_LIBCXX@
libcxx_libs_dir = "@LIBCXX_LIBRARY_DIR@"
libcxx_include_dir = "@LIBCXX_GENERATED_INCLUDE_DIR@"
@@ -45,6 +46,7 @@ if __name__ == '__main__':
cmd.extend(['--framework', lldb_framework_dir])
if lldb_build_intel_pt == "1":
cmd.extend(['--enable-plugin', 'intel-pt'])
+cmd.extend(['--lldb-obj-root', lldb_obj_root])
cmd.extend(wrapper_args)
# Invoke dotest.py and return exit code.
print(' '.join(cmd))
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] LLDB Debuginfod tests and a fix or two (PR #90622)
llvmbot wrote: @llvm/pr-subscribers-lldb Author: Kevin Frei (kevinfrei) Changes I'm taking yet another swing at getting these tests going, on the hypothesis that the problems with buildbots whatnot are because they're not configured with CURL support, which I've confirmed would cause the previous tests to fail. (I have no access to an ARM64 linux system, but I did repro the failure on MacOS configured without CURL support) So, the only difference between this diff and [previous](https://github.com/llvm/llvm-project/pull/85693) [diffs](https://github.com/llvm/llvm-project/pull/87676) that have already been approved is that I've added a condition to the tests to only run if Debuginfod capabilities should be built into the binary. I had done this for these tests when they were [Shell tests](https://github.com/llvm/llvm-project/pull/79181) and not API tests, but I couldn't find a direct analog in any API test, so I used the "plugins" model used by the intel-pt tests as well. --- Patch is 26.05 KiB, truncated to 20.00 KiB below, full version: https://github.com/llvm/llvm-project/pull/90622.diff 12 Files Affected: - (modified) lldb/packages/Python/lldbsuite/test/make/Makefile.rules (+25-1) - (modified) lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp (+25-13) - (modified) lldb/source/Plugins/SymbolLocator/CMakeLists.txt (+6-1) - (modified) lldb/source/Plugins/SymbolVendor/ELF/SymbolVendorELF.cpp (+27-2) - (added) lldb/test/API/debuginfod/Normal/Makefile (+19) - (added) lldb/test/API/debuginfod/Normal/TestDebuginfod.py (+183) - (added) lldb/test/API/debuginfod/Normal/main.c (+7) - (added) lldb/test/API/debuginfod/SplitDWARF/Makefile (+23) - (added) lldb/test/API/debuginfod/SplitDWARF/TestDebuginfodDWP.py (+192) - (added) lldb/test/API/debuginfod/SplitDWARF/main.c (+7) - (modified) lldb/test/API/lit.site.cfg.py.in (+4) - (modified) lldb/test/CMakeLists.txt (+1) ``diff diff --git a/lldb/packages/Python/lldbsuite/test/make/Makefile.rules b/lldb/packages/Python/lldbsuite/test/make/Makefile.rules index bfd249ccd43f2e..ee8793fa1b3029 100644 --- a/lldb/packages/Python/lldbsuite/test/make/Makefile.rules +++ b/lldb/packages/Python/lldbsuite/test/make/Makefile.rules @@ -51,7 +51,7 @@ LLDB_BASE_DIR := $(THIS_FILE_DIR)/../../../../../ # # GNUWin32 uname gives "windows32" or "server version windows32" while # some versions of MSYS uname return "MSYS_NT*", but most environments -# standardize on "Windows_NT", so we'll make it consistent here. +# standardize on "Windows_NT", so we'll make it consistent here. # When running tests from Visual Studio, the environment variable isn't # inherited all the way down to the process spawned for make. #-- @@ -210,6 +210,12 @@ else ifeq "$(SPLIT_DEBUG_SYMBOLS)" "YES" DSYM = $(EXE).debug endif + + ifeq "$(MAKE_DWP)" "YES" + MAKE_DWO := YES + DWP_NAME = $(EXE).dwp + DYLIB_DWP_NAME = $(DYLIB_NAME).dwp + endif endif LIMIT_DEBUG_INFO_FLAGS = @@ -357,6 +363,7 @@ ifneq "$(OS)" "Darwin" OBJCOPY ?= $(call replace_cc_with,objcopy) ARCHIVER ?= $(call replace_cc_with,ar) + DWP ?= $(call replace_cc_with,dwp) override AR = $(ARCHIVER) endif @@ -527,6 +534,10 @@ ifneq "$(CXX)" "" endif endif +ifeq "$(GEN_GNU_BUILD_ID)" "YES" + LDFLAGS += -Wl,--build-id +endif + #-- # DYLIB_ONLY variable can be used to skip the building of a.out. # See the sections below regarding dSYM file as well as the building of @@ -565,10 +576,17 @@ else endif else ifeq "$(SPLIT_DEBUG_SYMBOLS)" "YES" +ifeq "$(SAVE_FULL_DEBUG_BINARY)" "YES" + cp "$(EXE)" "$(EXE).unstripped" +endif $(OBJCOPY) --only-keep-debug "$(EXE)" "$(DSYM)" $(OBJCOPY) --strip-debug --add-gnu-debuglink="$(DSYM)" "$(EXE)" "$(EXE)" endif +ifeq "$(MAKE_DWP)" "YES" + $(DWP) -o "$(DWP_NAME)" $(DWOS) endif +endif + #-- # Make the dylib @@ -610,9 +628,15 @@ endif else $(LD) $(DYLIB_OBJECTS) $(LDFLAGS) -shared -o "$(DYLIB_FILENAME)" ifeq "$(SPLIT_DEBUG_SYMBOLS)" "YES" + ifeq "$(SAVE_FULL_DEBUG_BINARY)" "YES" + cp "$(DYLIB_FILENAME)" "$(DYLIB_FILENAME).unstripped" + endif $(OBJCOPY) --only-keep-debug "$(DYLIB_FILENAME)" "$(DYLIB_FILENAME).debug" $(OBJCOPY) --strip-debug --add-gnu-debuglink="$(DYLIB_FILENAME).debug" "$(DYLIB_FILENAME)" "$(DYLIB_FILENAME)" endif +ifeq "$(MAKE_DWP)" "YES" + $(DWP) -o $(DYLIB_DWP_FILE) $(DYLIB_DWOS) +endif endif #-- diff --git a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp index
[Lldb-commits] [lldb] LLDB Debuginfod tests and a fix or two (PR #90622)
https://github.com/kevinfrei ready_for_review https://github.com/llvm/llvm-project/pull/90622 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][Docs] Various style improvements to the tutorial (PR #90594)
https://github.com/medismailben approved this pull request. https://github.com/llvm/llvm-project/pull/90594 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][Docs] Various style improvements to the tutorial (PR #90594)
medismailben wrote: LGTM! https://github.com/llvm/llvm-project/pull/90594 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [clang] [compiler-rt] [libc] [libclc] [libcxxabi] [lld] [lldb] [llvm] [mlir] Add clarifying parenthesis around non-trivial conditions in ternary expressions. (PR #90391)
jayfoad wrote: AMDGPU changes are fine. https://github.com/llvm/llvm-project/pull/90391 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Summarize std::string's when created from data. (PR #89110)
https://github.com/Jlalond updated
https://github.com/llvm/llvm-project/pull/89110
>From e0316188d22605c670079e37855d3d8b5c944cee Mon Sep 17 00:00:00 2001
From: Jacob John Lalonde
Date: Wed, 10 Apr 2024 14:33:40 -0700
Subject: [PATCH 1/4] Fix bug where an sbvalue containing a std::string created
from data would not use the built in summary provider, but default to the
valueobjectprinter
std::string children are normally formatted as their summary [my_string_prop] =
"hello world".
Sbvalues created from data do not follow the same summary formatter path and
instead hit the value object printer.
This change fixes that and adds tests for the future.
Added tests in TestDataFormatterStdString.py and a formatter for a custom
struct.
---
.../Plugins/Language/CPlusPlus/LibStdcpp.cpp | 31 ++--
.../string/ConvertToDataFormatter.py | 50 +++
.../string/TestDataFormatterStdString.py | 28 +++
.../libstdcpp/string/main.cpp | 13 +
4 files changed, 118 insertions(+), 4 deletions(-)
create mode 100644
lldb/test/API/functionalities/data-formatter/data-formatter-stl/libstdcpp/string/ConvertToDataFormatter.py
diff --git a/lldb/source/Plugins/Language/CPlusPlus/LibStdcpp.cpp
b/lldb/source/Plugins/Language/CPlusPlus/LibStdcpp.cpp
index 86bb575af5ca34..0da01e9ca07fb6 100644
--- a/lldb/source/Plugins/Language/CPlusPlus/LibStdcpp.cpp
+++ b/lldb/source/Plugins/Language/CPlusPlus/LibStdcpp.cpp
@@ -254,13 +254,13 @@ bool
lldb_private::formatters::LibStdcppStringSummaryProvider(
} else
addr_of_string =
valobj.GetAddressOf(scalar_is_load_addr, _type);
- if (addr_of_string != LLDB_INVALID_ADDRESS) {
+ if (addr_of_string != LLDB_INVALID_ADDRESS ||
+addr_type == eAddressTypeHost) {
switch (addr_type) {
case eAddressTypeLoad: {
ProcessSP process_sp(valobj.GetProcessSP());
if (!process_sp)
return false;
-
StringPrinter::ReadStringAndDumpToStreamOptions options(valobj);
Status error;
lldb::addr_t addr_of_data =
@@ -287,8 +287,31 @@ bool
lldb_private::formatters::LibStdcppStringSummaryProvider(
} else
return true;
} break;
-case eAddressTypeHost:
- break;
+case eAddressTypeHost: {
+ // We have the host address of our std::string
+ // But we need to read the pointee data from the debugged process.
+ ProcessSP process_sp(valobj.GetProcessSP());
+ DataExtractor data;
+ Status error;
+ valobj.GetData(data, error);
+ if (error.Fail())
+return false;
+ // We want to read the address from std::string, which is the first 8
bytes.
+ lldb::offset_t offset = 0;
+ lldb::addr_t addr = data.GetAddress();
+ if (!addr)
+ {
+stream.Printf("nullptr");
+return true;
+ }
+
+ std::string contents;
+ process_sp->ReadCStringFromMemory(addr, contents, error);
+ if (error.Fail())
+return false;
+ stream.Printf("%s", contents.c_str());
+ return true;
+} break;
case eAddressTypeInvalid:
case eAddressTypeFile:
break;
diff --git
a/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libstdcpp/string/ConvertToDataFormatter.py
b/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libstdcpp/string/ConvertToDataFormatter.py
new file mode 100644
index 00..57e42c920f8294
--- /dev/null
+++
b/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libstdcpp/string/ConvertToDataFormatter.py
@@ -0,0 +1,50 @@
+# coding=utf8
+"""
+Helper formmater to verify Std::String by created via SBData
+"""
+
+import lldb
+
+class SyntheticFormatter:
+def __init__(self, valobj, dict):
+self.valobj = valobj
+
+def num_children(self):
+return 6
+
+def has_children(self):
+return True
+
+def get_child_at_index(self, index):
+name = None
+match index:
+case 0:
+name = "short_string"
+case 1:
+name = "long_string"
+case 2:
+name = "short_string_ptr"
+case 3:
+name = "long_string_ptr"
+case 4:
+name = "short_string_ref"
+case 5:
+name = "long_string_ref"
+case _:
+return None
+
+child = self.valobj.GetChildMemberWithName(name)
+valType = child.GetType()
+return self.valobj.CreateValueFromData(name,
+child.GetData(),
+valType)
+
+
+def __lldb_init_module(debugger, dict):
+typeName = "string_container"
+debugger.HandleCommand(
+'type synthetic add -x "'
++ typeName
++ '" --python-class '
++ f"{__name__}.SyntheticFormatter"
+)
diff --git
a/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libstdcpp/string/TestDataFormatterStdString.py
[Lldb-commits] [lldb] Add a new SBExpressionOptions::SetLanguage() API (NFCI) (PR #89981)
nico wrote: Thanks for the explanation! What kind of tool reads this file? It's still weird to use tblgen to process non-td files imho. We have a bunch of places that run python scripts as part of the build (clang/utils/bundle_resources.py, clang/lib/Tooling/DumpTool/generate_cxx_src_locs.py, compiler-rt/lib/sanitizer_common/scripts/gen_dynamic_list.py, clang-tools-extra/clangd/quality/CompletionModelCodegen.py) – maybe that could work here? https://github.com/llvm/llvm-project/pull/89981 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Debuginfod tests and a fix or two (PR #90622)
https://github.com/kevinfrei edited https://github.com/llvm/llvm-project/pull/90622 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] LLDB Debuginfod tests and a fix or two (PR #90622)
https://github.com/kevinfrei edited https://github.com/llvm/llvm-project/pull/90622 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] LLDB Debuginfod tests and a fix or two (PR #90622)
https://github.com/kevinfrei edited https://github.com/llvm/llvm-project/pull/90622 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Debuginfod tests and a fix or two (PR #90622)
https://github.com/kevinfrei edited https://github.com/llvm/llvm-project/pull/90622 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Debuginfod tests and a fix or two (PR #90622)
https://github.com/kevinfrei updated
https://github.com/llvm/llvm-project/pull/90622
>From dfa1acd8e51b04b4a37cde4fc064ab294ed7a02e Mon Sep 17 00:00:00 2001
From: Kevin Frei
Date: Mon, 25 Mar 2024 08:23:47 -0700
Subject: [PATCH 1/8] Trying to deal with Linux AArch64 test failures :/
---
.../SymbolVendor/ELF/SymbolVendorELF.cpp | 18 ++
.../API/debuginfod/Normal/TestDebuginfod.py | 187 +
.../SplitDWARF/TestDebuginfodDWP.py | 196 ++
3 files changed, 401 insertions(+)
create mode 100644 lldb/test/API/debuginfod/Normal/TestDebuginfod.py
create mode 100644 lldb/test/API/debuginfod/SplitDWARF/TestDebuginfodDWP.py
diff --git a/lldb/source/Plugins/SymbolVendor/ELF/SymbolVendorELF.cpp
b/lldb/source/Plugins/SymbolVendor/ELF/SymbolVendorELF.cpp
index b5fe35d71032a8..a881218a56cef3 100644
--- a/lldb/source/Plugins/SymbolVendor/ELF/SymbolVendorELF.cpp
+++ b/lldb/source/Plugins/SymbolVendor/ELF/SymbolVendorELF.cpp
@@ -44,6 +44,24 @@ llvm::StringRef
SymbolVendorELF::GetPluginDescriptionStatic() {
"executables.";
}
+// If this is needed elsewhere, it can be exported/moved.
+static bool IsDwpSymbolFile(const lldb::ModuleSP _sp,
+const FileSpec _spec) {
+ DataBufferSP dwp_file_data_sp;
+ lldb::offset_t dwp_file_data_offset = 0;
+ // Try to create an ObjectFile from the file_spec.
+ ObjectFileSP dwp_obj_file = ObjectFile::FindPlugin(
+ module_sp, _spec, 0, FileSystem::Instance().GetByteSize(file_spec),
+ dwp_file_data_sp, dwp_file_data_offset);
+ // The presence of a debug_cu_index section is the key identifying feature of
+ // a DWP file. Make sure we don't fill in the section list on dwp_obj_file
+ // (by calling GetSectionList(false)) as this is invoked before we may have
+ // all the symbol files collected and available.
+ return dwp_obj_file && ObjectFileELF::classof(dwp_obj_file.get()) &&
+ dwp_obj_file->GetSectionList(false)->FindSectionByType(
+ eSectionTypeDWARFDebugCuIndex, false);
+}
+
// CreateInstance
//
// Platforms can register a callback to use when creating symbol vendors to
diff --git a/lldb/test/API/debuginfod/Normal/TestDebuginfod.py
b/lldb/test/API/debuginfod/Normal/TestDebuginfod.py
new file mode 100644
index 00..a662fb9fc6e686
--- /dev/null
+++ b/lldb/test/API/debuginfod/Normal/TestDebuginfod.py
@@ -0,0 +1,187 @@
+import os
+import shutil
+import tempfile
+import struct
+
+import lldb
+from lldbsuite.test.decorators import *
+import lldbsuite.test.lldbutil as lldbutil
+from lldbsuite.test.lldbtest import *
+
+
+def getUUID(aoutuuid):
+"""
+Pull the 20 byte UUID out of the .note.gnu.build-id section that was dumped
+to a file already, as part of the build.
+"""
+with open(aoutuuid, "rb") as f:
+data = f.read(36)
+if len(data) != 36:
+return None
+header = struct.unpack_from("<4I", data)
+if len(header) != 4:
+return None
+# 4 element 'prefix', 20 bytes of uuid, 3 byte long string: 'GNU':
+if header[0] != 4 or header[1] != 20 or header[2] != 3 or header[3] !=
0x554E47:
+return None
+return data[16:].hex()
+
+
+"""
+Test support for the DebugInfoD network symbol acquisition protocol.
+This one is for simple / no split-dwarf scenarios.
+
+For no-split-dwarf scenarios, there are 2 variations:
+1 - A stripped binary with it's corresponding unstripped binary:
+2 - A stripped binary with a corresponding --only-keep-debug symbols file
+"""
+
+
+@skipUnlessPlatform(["linux", "freebsd"])
+class DebugInfodTests(TestBase):
+# No need to try every flavor of debug inf.
+NO_DEBUG_INFO_TESTCASE = True
+
+def test_normal_no_symbols(self):
+"""
+Validate behavior with no symbols or symbol locator.
+('baseline negative' behavior)
+"""
+test_root = self.config_test(["a.out"])
+self.try_breakpoint(False)
+
+def test_normal_default(self):
+"""
+Validate behavior with symbols, but no symbol locator.
+('baseline positive' behavior)
+"""
+test_root = self.config_test(["a.out", "a.out.debug"])
+self.try_breakpoint(True)
+
+def test_debuginfod_symbols(self):
+"""
+Test behavior with the full binary available from Debuginfod as
+'debuginfo' from the plug-in.
+"""
+test_root = self.config_test(["a.out"], "a.out.full")
+self.try_breakpoint(True)
+
+def test_debuginfod_executable(self):
+"""
+Test behavior with the full binary available from Debuginfod as
+'executable' from the plug-in.
+"""
+test_root = self.config_test(["a.out"], None, "a.out.full")
+self.try_breakpoint(True)
+
+def test_debuginfod_okd_symbols(self):
+"""
+Test behavior with the 'only-keep-debug' symbols available from
Debuginfod.
+"""
+test_root =
[Lldb-commits] [clang] [compiler-rt] [libc] [libclc] [libcxxabi] [lld] [lldb] [llvm] [mlir] Add clarifying parenthesis around non-trivial conditions in ternary expressions. (PR #90391)
luolent wrote: Hi @bulbazord , @lntue , thanks for your helpful comments, first time contributing here :) I have updated the PR. https://github.com/llvm/llvm-project/pull/90391 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [clang] [compiler-rt] [libc] [libclc] [libcxxabi] [lld] [lldb] [llvm] [mlir] Add clarifying parenthesis around non-trivial conditions in ternary expressions. (PR #90391)
https://github.com/luolent edited https://github.com/llvm/llvm-project/pull/90391 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [clang] [compiler-rt] [libc] [libclc] [libcxxabi] [lld] [lldb] [llvm] [mlir] Add clarifying parenthesis around non-trivial conditions in ternary expressions. (PR #90391)
https://github.com/luolent edited https://github.com/llvm/llvm-project/pull/90391 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Debuginfod tests and a fix or two (PR #90622)
github-actions[bot] wrote:
:warning: Python code formatter, darker found issues in your code. :warning:
You can test this locally with the following command:
``bash
darker --check --diff -r
8d28e5861f8b117a547850ffbb9a332aa6e91459...735822efd188c677337f84e472cf7be6edb42feb
lldb/test/API/debuginfod/Normal/TestDebuginfod.py
lldb/test/API/debuginfod/SplitDWARF/TestDebuginfodDWP.py
``
View the diff from darker here.
``diff
--- Normal/TestDebuginfod.py2024-04-30 15:48:36.00 +
+++ Normal/TestDebuginfod.py2024-04-30 15:55:22.188287 +
@@ -25,11 +25,10 @@
def setUp(self):
TestBase.setUp(self)
# Don't run these tests if we don't have Debuginfod support
if "Debuginfod" not in configuration.enabled_plugins:
self.skipTest("The Debuginfod SymbolLocator plugin is not enabled")
-
def test_normal_no_symbols(self):
"""
Validate behavior with no symbols or symbol locator.
('baseline negative' behavior)
``
https://github.com/llvm/llvm-project/pull/90622
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Debuginfod tests and a fix or two (PR #90622)
https://github.com/kevinfrei created
https://github.com/llvm/llvm-project/pull/90622
I'm taking another swing at getting these tests going, on the hypothesis that
the problems with buildbots & whatnot are because they're not configured with
CURL support, which I've confirmed would cause the previous tests to fail.
So, the only difference between this diff and previous diffs that have already
been approved is that I've added a condition to the tests to only run if
Debuginfod capabilities should be built into the binary. I had done this for
these tests when they were Shell tests and not API tests, but I couldn't find a
direct analog in any API test, so I used the "plugins" model used by the
intel-pt tests as well.
>From dfa1acd8e51b04b4a37cde4fc064ab294ed7a02e Mon Sep 17 00:00:00 2001
From: Kevin Frei
Date: Mon, 25 Mar 2024 08:23:47 -0700
Subject: [PATCH 1/7] Trying to deal with Linux AArch64 test failures :/
---
.../SymbolVendor/ELF/SymbolVendorELF.cpp | 18 ++
.../API/debuginfod/Normal/TestDebuginfod.py | 187 +
.../SplitDWARF/TestDebuginfodDWP.py | 196 ++
3 files changed, 401 insertions(+)
create mode 100644 lldb/test/API/debuginfod/Normal/TestDebuginfod.py
create mode 100644 lldb/test/API/debuginfod/SplitDWARF/TestDebuginfodDWP.py
diff --git a/lldb/source/Plugins/SymbolVendor/ELF/SymbolVendorELF.cpp
b/lldb/source/Plugins/SymbolVendor/ELF/SymbolVendorELF.cpp
index b5fe35d71032a8..a881218a56cef3 100644
--- a/lldb/source/Plugins/SymbolVendor/ELF/SymbolVendorELF.cpp
+++ b/lldb/source/Plugins/SymbolVendor/ELF/SymbolVendorELF.cpp
@@ -44,6 +44,24 @@ llvm::StringRef
SymbolVendorELF::GetPluginDescriptionStatic() {
"executables.";
}
+// If this is needed elsewhere, it can be exported/moved.
+static bool IsDwpSymbolFile(const lldb::ModuleSP _sp,
+const FileSpec _spec) {
+ DataBufferSP dwp_file_data_sp;
+ lldb::offset_t dwp_file_data_offset = 0;
+ // Try to create an ObjectFile from the file_spec.
+ ObjectFileSP dwp_obj_file = ObjectFile::FindPlugin(
+ module_sp, _spec, 0, FileSystem::Instance().GetByteSize(file_spec),
+ dwp_file_data_sp, dwp_file_data_offset);
+ // The presence of a debug_cu_index section is the key identifying feature of
+ // a DWP file. Make sure we don't fill in the section list on dwp_obj_file
+ // (by calling GetSectionList(false)) as this is invoked before we may have
+ // all the symbol files collected and available.
+ return dwp_obj_file && ObjectFileELF::classof(dwp_obj_file.get()) &&
+ dwp_obj_file->GetSectionList(false)->FindSectionByType(
+ eSectionTypeDWARFDebugCuIndex, false);
+}
+
// CreateInstance
//
// Platforms can register a callback to use when creating symbol vendors to
diff --git a/lldb/test/API/debuginfod/Normal/TestDebuginfod.py
b/lldb/test/API/debuginfod/Normal/TestDebuginfod.py
new file mode 100644
index 00..a662fb9fc6e686
--- /dev/null
+++ b/lldb/test/API/debuginfod/Normal/TestDebuginfod.py
@@ -0,0 +1,187 @@
+import os
+import shutil
+import tempfile
+import struct
+
+import lldb
+from lldbsuite.test.decorators import *
+import lldbsuite.test.lldbutil as lldbutil
+from lldbsuite.test.lldbtest import *
+
+
+def getUUID(aoutuuid):
+"""
+Pull the 20 byte UUID out of the .note.gnu.build-id section that was dumped
+to a file already, as part of the build.
+"""
+with open(aoutuuid, "rb") as f:
+data = f.read(36)
+if len(data) != 36:
+return None
+header = struct.unpack_from("<4I", data)
+if len(header) != 4:
+return None
+# 4 element 'prefix', 20 bytes of uuid, 3 byte long string: 'GNU':
+if header[0] != 4 or header[1] != 20 or header[2] != 3 or header[3] !=
0x554E47:
+return None
+return data[16:].hex()
+
+
+"""
+Test support for the DebugInfoD network symbol acquisition protocol.
+This one is for simple / no split-dwarf scenarios.
+
+For no-split-dwarf scenarios, there are 2 variations:
+1 - A stripped binary with it's corresponding unstripped binary:
+2 - A stripped binary with a corresponding --only-keep-debug symbols file
+"""
+
+
+@skipUnlessPlatform(["linux", "freebsd"])
+class DebugInfodTests(TestBase):
+# No need to try every flavor of debug inf.
+NO_DEBUG_INFO_TESTCASE = True
+
+def test_normal_no_symbols(self):
+"""
+Validate behavior with no symbols or symbol locator.
+('baseline negative' behavior)
+"""
+test_root = self.config_test(["a.out"])
+self.try_breakpoint(False)
+
+def test_normal_default(self):
+"""
+Validate behavior with symbols, but no symbol locator.
+('baseline positive' behavior)
+"""
+test_root = self.config_test(["a.out", "a.out.debug"])
+self.try_breakpoint(True)
+
+def test_debuginfod_symbols(self):
+"""
+Test behavior with the full binary
[Lldb-commits] [lldb] Add a new SBExpressionOptions::SetLanguage() API (NFCI) (PR #89981)
adrian-prantl wrote: Btw. github doesn't let you see older revisions, but the code snippet you posted that includes a .def file was exactly my first version of this patch. You can still find @JDevlieghere's comment asking me to change it though :-) Another thing worth noting is that the public LLDB API can't expect an LLVM header to be present either. https://github.com/llvm/llvm-project/pull/89981 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Add a new SBExpressionOptions::SetLanguage() API (NFCI) (PR #89981)
adrian-prantl wrote: That's also why it's a `.h` file and not a `.inc`. https://github.com/llvm/llvm-project/pull/89981 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Add a new SBExpressionOptions::SetLanguage() API (NFCI) (PR #89981)
adrian-prantl wrote:
> Why does this use tablegen to parse a .def file?
>
> Can't you get the same behavior without tablegen, using normal xmacro
> techniques, something like
>
> ```c++
> enum SBSourceLanguageName : uint16_t {
>
> #define HANDLE_DW_LNAME(ID, NAME, DESC, LOWER_BOUND) \
> eLanguageName ## NAME = ID,
>
> #include "llvm/include/llvm/BinaryFormat/Dwarf.def"
>
> #undef HANDLE_DW_LNAME
>
> };
> ```
>
> ? Why bring tablegen into this?
>
> (Sorry if I'm missing something obvious.)
That's a very valid question to ask!
The reason is that the header files produced here are part of the LLDB
scripting API and are going to be processed by tools that are not full
compilers and fully expanding this at compile-time avoids any compatibility
issues with not fully compliant interface generators. The reason why this is
implemented in C++ is because I don't want to assume that there is `sed` or
something equivalent available on the build system especially on platforms like
Windows.
https://github.com/llvm/llvm-project/pull/89981
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB][ELF] Fix section unification to not just use names. (PR #90099)
https://github.com/al45tair updated
https://github.com/llvm/llvm-project/pull/90099
>From ce54a7fb339a00029da266c9f518e344aac5d19e Mon Sep 17 00:00:00 2001
From: Alastair Houghton
Date: Thu, 25 Apr 2024 11:35:55 +0100
Subject: [PATCH 1/5] [LLDB][ELF] Fix section unification to not just use
names.
Section unification cannot just use names, because it's valid for ELF
binaries to have multiple sections with the same name. We should check
other section properties too.
rdar://124467787
---
.../Plugins/ObjectFile/ELF/ObjectFileELF.cpp | 64 +++
1 file changed, 53 insertions(+), 11 deletions(-)
diff --git a/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
b/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
index 0d95a1c12bde35..60fc68c96bcc1c 100644
--- a/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
+++ b/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
@@ -1854,6 +1854,49 @@ class VMAddressProvider {
};
}
+namespace {
+ // We have to do this because ELF doesn't have section IDs, and also
+ // doesn't require section names to be unique. (We use the section index
+ // for section IDs, but that isn't guaranteed to be the same in separate
+ // debug images.)
+ SectionSP FindMatchingSection(const SectionList _list,
+SectionSP section) {
+SectionSP sect_sp;
+
+addr_t vm_addr = section->GetFileAddress();
+ConstString name = section->GetName();
+offset_t file_size = section->GetFileSize();
+offset_t byte_size = section->GetByteSize();
+SectionType type = section->GetType();
+bool thread_specific = section->IsThreadSpecific();
+uint32_t permissions = section->GetPermissions();
+uint32_t alignment = section->GetLog2Align();
+
+for (auto sect_iter = section_list.begin();
+ sect_iter != section_list.end();
+ ++sect_iter) {
+ if ((*sect_iter)->GetName() == name
+ && (*sect_iter)->GetType() == type
+ && (*sect_iter)->IsThreadSpecific() == thread_specific
+ && (*sect_iter)->GetPermissions() == permissions
+ && (*sect_iter)->GetFileSize() == file_size
+ && (*sect_iter)->GetByteSize() == byte_size
+ && (*sect_iter)->GetFileAddress() == vm_addr
+ && (*sect_iter)->GetLog2Align() == alignment) {
+sect_sp = *sect_iter;
+break;
+ } else {
+sect_sp = FindMatchingSection((*sect_iter)->GetChildren(),
+ section);
+if (sect_sp)
+ break;
+ }
+}
+
+return sect_sp;
+ }
+}
+
void ObjectFileELF::CreateSections(SectionList _section_list) {
if (m_sections_up)
return;
@@ -2067,10 +2110,8 @@ unsigned ObjectFileELF::ParseSymbols(Symtab *symtab,
user_id_t start_id,
SectionList *module_section_list =
module_sp ? module_sp->GetSectionList() : nullptr;
- // Local cache to avoid doing a FindSectionByName for each symbol. The "const
- // char*" key must came from a ConstString object so they can be compared by
- // pointer
- std::unordered_map section_name_to_section;
+ // Cache the section mapping
+ std::unordered_map section_map;
unsigned i;
for (i = 0; i < num_symbols; ++i) {
@@ -2275,14 +2316,15 @@ unsigned ObjectFileELF::ParseSymbols(Symtab *symtab,
user_id_t start_id,
if (symbol_section_sp && module_section_list &&
module_section_list != section_list) {
- ConstString sect_name = symbol_section_sp->GetName();
- auto section_it = section_name_to_section.find(sect_name.GetCString());
- if (section_it == section_name_to_section.end())
+ auto section_it = section_map.find(symbol_section_sp);
+ if (section_it == section_map.end()) {
section_it =
-section_name_to_section
-.emplace(sect_name.GetCString(),
- module_section_list->FindSectionByName(sect_name))
-.first;
+ section_map
+ .emplace(symbol_section_sp,
+ FindMatchingSection(*module_section_list,
+ symbol_section_sp))
+ .first;
+ }
if (section_it->second)
symbol_section_sp = section_it->second;
}
>From 9653351729b4ef2d98faba936b8fa6fb51a9a47c Mon Sep 17 00:00:00 2001
From: Alastair Houghton
Date: Fri, 26 Apr 2024 14:53:20 +0100
Subject: [PATCH 2/5] [LLDB][ELF] Address review feedback, add test.
Fixed a couple of nits from review, and fixed up formatting.
Also added a test.
rdar://124467787
---
.../Plugins/ObjectFile/ELF/ObjectFileELF.cpp | 86 +-
.../ELF/Inputs/two-text-sections.elf | Bin 0 -> 4976 bytes
.../ObjectFile/ELF/two-text-sections.test | 8 ++
3 files changed, 49 insertions(+), 45 deletions(-)
create mode 100644 lldb/test/Shell/ObjectFile/ELF/Inputs/two-text-sections.elf
create mode 100644 lldb/test/Shell/ObjectFile/ELF/two-text-sections.test
diff --git
[Lldb-commits] [lldb] [LLDB][ELF] Fix section unification to not just use names. (PR #90099)
al45tair wrote: @labath @JDevlieghere Are we happy with this PR now? If so, I'll cherry pick it to the various Apple forks; I need it in order to merge https://github.com/apple/swift/pull/72061, which we need for both my fully statically linked Swift SDK work and for Amazon Linux 2023 support in Swift. https://github.com/llvm/llvm-project/pull/90099 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Fixed SyntaxWarning invalid escape sequence '\l' in lldbtest.py (PR #90609)
https://github.com/DavidSpickett closed https://github.com/llvm/llvm-project/pull/90609 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] c106abf - [lldb] Fixed SyntaxWarning invalid escape sequence '\l' in lldbtest.py (#90609)
Author: Dmitry Vasilyev
Date: 2024-04-30T15:15:14+01:00
New Revision: c106abfe9f3d3ed78a946009f7625088f28e9065
URL:
https://github.com/llvm/llvm-project/commit/c106abfe9f3d3ed78a946009f7625088f28e9065
DIFF:
https://github.com/llvm/llvm-project/commit/c106abfe9f3d3ed78a946009f7625088f28e9065.diff
LOG: [lldb] Fixed SyntaxWarning invalid escape sequence '\l' in lldbtest.py
(#90609)
Added:
Modified:
lldb/packages/Python/lldbsuite/test/lldbtest.py
Removed:
diff --git a/lldb/packages/Python/lldbsuite/test/lldbtest.py
b/lldb/packages/Python/lldbsuite/test/lldbtest.py
index 591e834c7cdf49..5fd686c143e9f9 100644
--- a/lldb/packages/Python/lldbsuite/test/lldbtest.py
+++ b/lldb/packages/Python/lldbsuite/test/lldbtest.py
@@ -1526,7 +1526,7 @@ def buildLibrary(self, sources, lib_name):
os.path.join(os.environ["LLDB_SRC"], "include"),
os.path.join(configuration.lldb_obj_root, "include"),
),
-"LD_EXTRAS": "-shared -l%s\liblldb.lib" % lib_dir,
+"LD_EXTRAS": "-shared -l%s\\liblldb.lib" % lib_dir,
}
else:
d = {
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Fixed SyntaxWarning invalid escape sequence '\l' in lldbtest.py (PR #90609)
https://github.com/DavidSpickett approved this pull request. LGTM https://github.com/llvm/llvm-project/pull/90609 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Add a new SBExpressionOptions::SetLanguage() API (NFCI) (PR #89981)
nico wrote: I left another comment on the commit that doesn't show up here (https://github.com/llvm/llvm-project/commit/975eca0e6a3459e59e96b0df33ea0cfbd157c597). If you do want to keep the generated file: All other tablegen invocations use ".inc" for tablegen output. Maybe this could match that convention? (But not needing a generated file seems even nicer.) https://github.com/llvm/llvm-project/pull/89981 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Fixed SyntaxWarning invalid escape sequence '\s' in decorators.py (PR #90607)
https://github.com/DavidSpickett closed https://github.com/llvm/llvm-project/pull/90607 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] 7ae32bf - [lldb] Fixed SyntaxWarning invalid escape sequence '\s' in decorators.py (#90607)
Author: Dmitry Vasilyev
Date: 2024-04-30T14:38:46+01:00
New Revision: 7ae32bf7581e03d92c78346a72ea20798520b978
URL:
https://github.com/llvm/llvm-project/commit/7ae32bf7581e03d92c78346a72ea20798520b978
DIFF:
https://github.com/llvm/llvm-project/commit/7ae32bf7581e03d92c78346a72ea20798520b978.diff
LOG: [lldb] Fixed SyntaxWarning invalid escape sequence '\s' in decorators.py
(#90607)
Added:
Modified:
lldb/packages/Python/lldbsuite/test/decorators.py
Removed:
diff --git a/lldb/packages/Python/lldbsuite/test/decorators.py
b/lldb/packages/Python/lldbsuite/test/decorators.py
index 7fb88cef165356..79cc0a2aeacbeb 100644
--- a/lldb/packages/Python/lldbsuite/test/decorators.py
+++ b/lldb/packages/Python/lldbsuite/test/decorators.py
@@ -1098,7 +1098,7 @@ def is_feature_enabled():
).decode("utf-8")
# If 'feature: 1' was output, then this feature is available
and
# the test should not be skipped.
-if re.match("%s: 1\s*" % feature, output):
+if re.match(r"%s: 1\s*" % feature, output):
return None
else:
return "%s is not supported on this system." % feature
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Fixed SyntaxWarning invalid escape sequence '\s' in decorators.py (PR #90607)
https://github.com/DavidSpickett approved this pull request. Thanks for the fix! https://github.com/llvm/llvm-project/pull/90607 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Fixed SyntaxWarning invalid escape sequence '\l' in lldbtest.py (PR #90609)
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Dmitry Vasilyev (slydiman)
Changes
---
Full diff: https://github.com/llvm/llvm-project/pull/90609.diff
1 Files Affected:
- (modified) lldb/packages/Python/lldbsuite/test/lldbtest.py (+1-1)
``diff
diff --git a/lldb/packages/Python/lldbsuite/test/lldbtest.py
b/lldb/packages/Python/lldbsuite/test/lldbtest.py
index 591e834c7cdf49..5fd686c143e9f9 100644
--- a/lldb/packages/Python/lldbsuite/test/lldbtest.py
+++ b/lldb/packages/Python/lldbsuite/test/lldbtest.py
@@ -1526,7 +1526,7 @@ def buildLibrary(self, sources, lib_name):
os.path.join(os.environ["LLDB_SRC"], "include"),
os.path.join(configuration.lldb_obj_root, "include"),
),
-"LD_EXTRAS": "-shared -l%s\liblldb.lib" % lib_dir,
+"LD_EXTRAS": "-shared -l%s\\liblldb.lib" % lib_dir,
}
else:
d = {
``
https://github.com/llvm/llvm-project/pull/90609
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Add a new SBExpressionOptions::SetLanguage() API (NFCI) (PR #89981)
nico wrote:
Why does this use tablegen to parse a .def file?
Can't you get the same behavior without tablegen, using normal xmacro
techniques, something like
```c++
enum SBSourceLanguageName : uint16_t {
#define HANDLE_DW_LNAME(ID, NAME, DESC, LOWER_BOUND) \
eLanguageName ## NAME = ID,
#include "llvm/include/llvm/BinaryFormat/Dwarf.def"
#undef HANDLE_DW_LNAME
};
```
? Why bring tablegen into this?
(Sorry if I'm missing something obvious.)
https://github.com/llvm/llvm-project/pull/89981
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Fixed SyntaxWarning invalid escape sequence '\l' in lldbtest.py (PR #90609)
https://github.com/slydiman created
https://github.com/llvm/llvm-project/pull/90609
None
>From 697ee70d089642107514329c4611b766372c9bad Mon Sep 17 00:00:00 2001
From: Dmitry Vasilyev
Date: Tue, 30 Apr 2024 17:36:24 +0400
Subject: [PATCH] [lldb] Fixed SyntaxWarning invalid escape sequence '\l' in
lldbtest.py
---
lldb/packages/Python/lldbsuite/test/lldbtest.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lldb/packages/Python/lldbsuite/test/lldbtest.py
b/lldb/packages/Python/lldbsuite/test/lldbtest.py
index 591e834c7cdf49..5fd686c143e9f9 100644
--- a/lldb/packages/Python/lldbsuite/test/lldbtest.py
+++ b/lldb/packages/Python/lldbsuite/test/lldbtest.py
@@ -1526,7 +1526,7 @@ def buildLibrary(self, sources, lib_name):
os.path.join(os.environ["LLDB_SRC"], "include"),
os.path.join(configuration.lldb_obj_root, "include"),
),
-"LD_EXTRAS": "-shared -l%s\liblldb.lib" % lib_dir,
+"LD_EXTRAS": "-shared -l%s\\liblldb.lib" % lib_dir,
}
else:
d = {
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Fixed SyntaxWarning invalid escape sequence '\s' in decorators.py (PR #90607)
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Dmitry Vasilyev (slydiman)
Changes
---
Full diff: https://github.com/llvm/llvm-project/pull/90607.diff
1 Files Affected:
- (modified) lldb/packages/Python/lldbsuite/test/decorators.py (+1-1)
``diff
diff --git a/lldb/packages/Python/lldbsuite/test/decorators.py
b/lldb/packages/Python/lldbsuite/test/decorators.py
index 7fb88cef165356..79cc0a2aeacbeb 100644
--- a/lldb/packages/Python/lldbsuite/test/decorators.py
+++ b/lldb/packages/Python/lldbsuite/test/decorators.py
@@ -1098,7 +1098,7 @@ def is_feature_enabled():
).decode("utf-8")
# If 'feature: 1' was output, then this feature is available
and
# the test should not be skipped.
-if re.match("%s: 1\s*" % feature, output):
+if re.match(r"%s: 1\s*" % feature, output):
return None
else:
return "%s is not supported on this system." % feature
``
https://github.com/llvm/llvm-project/pull/90607
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Fixed SyntaxWarning invalid escape sequence '\s' in decorators.py (PR #90607)
https://github.com/slydiman created
https://github.com/llvm/llvm-project/pull/90607
None
>From f64ab848420b18dbf7d7d6f2fb269ebab6075bec Mon Sep 17 00:00:00 2001
From: Dmitry Vasilyev
Date: Tue, 30 Apr 2024 17:30:38 +0400
Subject: [PATCH] [lldb] Fixed SyntaxWarning invalid escape sequence '\s' in
decorators.py
---
lldb/packages/Python/lldbsuite/test/decorators.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lldb/packages/Python/lldbsuite/test/decorators.py
b/lldb/packages/Python/lldbsuite/test/decorators.py
index 7fb88cef165356..79cc0a2aeacbeb 100644
--- a/lldb/packages/Python/lldbsuite/test/decorators.py
+++ b/lldb/packages/Python/lldbsuite/test/decorators.py
@@ -1098,7 +1098,7 @@ def is_feature_enabled():
).decode("utf-8")
# If 'feature: 1' was output, then this feature is available
and
# the test should not be skipped.
-if re.match("%s: 1\s*" % feature, output):
+if re.match(r"%s: 1\s*" % feature, output):
return None
else:
return "%s is not supported on this system." % feature
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [clang] [lldb] [llvm] [AArch64][TargetParser] autogen ArchExtKind enum - renaming (PR #90320)
sdkrystian wrote: @tmatheson-arm This breaks builds without the `AArch64` target enabled (e.g. `LLVM_TARGETS_TO_BUILD=X86` ) https://github.com/llvm/llvm-project/pull/90320 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Be conversative about setting highmem address masks (PR #90533)
DavidSpickett wrote: On the face of it > When we have an unset high memory address mask, and we are told to set low- > and high-memory to the same new address mask, maintain the high memory mask > as unset in Process. The same thing is done with the > SBProcess::SetAddressMask API when the user specifies > lldb.eAddressMaskRangeAll. Seems to itself be confusing and if you're doing this to address > When high memory has a different set of masks, those become active in Process > and the user can use highmem-virtual-addressable-bits to override only the > highmem value, if it is wrong. You're adding one gotcha to avoid another. However, I think the result of the highmem mask being unset is the same as setting both masks to the same value. Except that `virtual-addressable-bits` will now effectively apply to both masks, until the user sets *only* the high mask to some value. At that point, `highmem-virtual-addressable-bits` must be used to modify the high mem value. Correct? So this doesn't actually change anything for an API user that was setting address masks for high and low all at once. They'll still think both are the same value, but *internally*, lldb tries high, see's that it's unset, and falls back to the low mask. https://github.com/llvm/llvm-project/pull/90533 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Be conversative about setting highmem address masks (PR #90533)
@@ -1465,6 +1465,20 @@ class Process : public
std::enable_shared_from_this,
/// platforms where there is a difference (only Arm Thumb at this time).
lldb::addr_t FixAnyAddress(lldb::addr_t pc);
+ /// Retrieve the actual address masks for high memory code/data,
+ /// without the normal fallbacks of returning the low-memory masks
+ /// or the user settings. Needed by SBProcess to determine if
+ /// the high address masks have actually been set, and should
+ /// be updated when "set all masks" is requested. In most cases,
+ /// the highmem masks should be left to have LLDB_INVALID_ADDRESS_MASK,
+ /// unset.
+ lldb::addr_t GetConcreteHighmemCodeAddressMask() {
DavidSpickett wrote:
All this makes me wonder if this can be `optional` but we're
already knee deep in the `INVALID_` style and it would only obscure the intent
of this patch.
https://github.com/llvm/llvm-project/pull/90533
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][Docs] Various style improvements to the tutorial (PR #90594)
DavidSpickett wrote: > Always refer to lldb as lldb not LLDB, to match what the user sees on the > command line. If this were any other doc I'd say it should always be LLDB and GDB as that's the projects' branding. In this doc I think it's better to imagine the user is looking at side by side command lines. https://github.com/llvm/llvm-project/pull/90594 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][Docs] Various style improvements to the tutorial (PR #90594)
llvmbot wrote: @llvm/pr-subscribers-lldb Author: David Spickett (DavidSpickett) Changes * Replace "we" with either "you" (when talking to the reader) or "lldb" (when talking about the project). * Always refer to lldb as lldb not LLDB, to match what the user sees on the command line. * Remove a bunch of contractions for example "won't". Which don't (pun intended) seem like a big deal at first but even I as a native English speaker find the text clearer with them expanded. * Use RST's plain text highlighting for keywords and command names. * Split some very long lines for easier editing in future. --- Patch is 34.48 KiB, truncated to 20.00 KiB below, full version: https://github.com/llvm/llvm-project/pull/90594.diff 1 Files Affected: - (modified) lldb/docs/use/tutorial.rst (+171-154) ``diff diff --git a/lldb/docs/use/tutorial.rst b/lldb/docs/use/tutorial.rst index ff956d750c29f2..c7f89976156ca4 100644 --- a/lldb/docs/use/tutorial.rst +++ b/lldb/docs/use/tutorial.rst @@ -1,89 +1,94 @@ Tutorial -Here's a short precis of how to run lldb if you are familiar with the gdb -command set. We will start with some details on lldb command structure and -syntax to help orient you. +This document describes how to use lldb if you are already familiar with +gdb's command set. We will start with some details on lldb command structure and +syntax. Command Structure - -Unlike gdb's command set, which is rather free-form, we tried to make the lldb command syntax fairly structured. The commands are all of the form: +Unlike gdb's quite free-form commands, lldb's are more structured. All commands +are of the form: :: [-options [option-value]] [argument [argument...]] -The command line parsing is done before command execution, so it is uniform -across all the commands. The command syntax for basic commands is very simple, -arguments, options and option values are all white-space separated, and -either single or double-quotes (in pairs) are used to protect white-spaces -in an argument. If you need to put a backslash or double-quote character in an -argument you back-slash it in the argument. That makes the command syntax more -regular, but it also means you may have to quote some arguments in lldb that -you wouldn't in gdb. +The command line parsing is done before command execution, so it is the same for +all commands. The command syntax for basic commands is very simple. -There is one other special quote character in lldb - the backtick. +* Arguments, options and option values are all white-space separated. +* Either single ``'`` or double-quotes ``"`` (in pairs) are used to protect white-spaces + in an argument. +* Escape backslashes and double quotes within arguments should be escaped + with a backslash ``\``. + +This makes lldb's commands more regular, but it also means you may have to quote +some arguments in lldb that you would not in gdb. + +There is one other special quote character in lldb - the backtick `. If you put backticks around an argument or option value, lldb will run the text of the value through the expression parser, and the result of the expression -will be passed to the command. So for instance, if "len" is a local -int variable with the value 5, then the command: +will be passed to the command. So for instance, if ``len`` is a local +``int`` variable with the value ``5``, then the command: :: (lldb) memory read -c `len` 0x12345 -will receive the value 5 for the count option, rather than the string "len". - +Will receive the value ``5`` for the count option, rather than the string ``len``. Options can be placed anywhere on the command line, but if the arguments begin -with a "-" then you have to tell lldb that you're done with options for the -current command by adding an option termination: "--". So for instance, if you -want to launch a process and give the "process launch" command the -"--stop-at-entry" option, yet you want the process you are about to launch to -be launched with the arguments "-program_arg value", you would type: +with a ``-`` then you have to tell lldb that you are done with options for the +current command by adding an option termination: ``--``. + +So for instance, if you want to launch a process and give the ``process launch`` +command the ``--stop-at-entry`` option, yet you want the process you are about +to launch to be launched with the arguments ``-program_arg value``, you would type: :: (lldb) process launch --stop-at-entry -- -program_arg value We also tried to reduce the number of special purpose argument parsers, which -sometimes forces the user to be a little more explicit about stating their -intentions. The first instance you'll note of this is the breakpoint command. -In gdb, to set a breakpoint, you might enter +sometimes forces the user to be explicit about their intentions. The first +instance you willl see of this is the breakpoint command. In
[Lldb-commits] [lldb] [lldb][Docs] Various style improvements to the tutorial (PR #90594)
https://github.com/DavidSpickett created https://github.com/llvm/llvm-project/pull/90594 * Replace "we" with either "you" (when talking to the reader) or "lldb" (when talking about the project). * Always refer to lldb as lldb not LLDB, to match what the user sees on the command line. * Remove a bunch of contractions for example "won't". Which don't (pun intended) seem like a big deal at first but even I as a native English speaker find the text clearer with them expanded. * Use RST's plain text highlighting for keywords and command names. * Split some very long lines for easier editing in future. >From 7fb721934de0bb3aa3b8c26ef02ef33863b6145d Mon Sep 17 00:00:00 2001 From: David Spickett Date: Tue, 30 Apr 2024 11:56:09 +0100 Subject: [PATCH 1/4] [lldb][Docs] Update the tutorial doc * Remove some unnecessary phrases * Use RST plain text highlights for key words and commands * Split some very long lines to ~80 columns for easier editing --- lldb/docs/use/tutorial.rst | 301 - 1 file changed, 159 insertions(+), 142 deletions(-) diff --git a/lldb/docs/use/tutorial.rst b/lldb/docs/use/tutorial.rst index ff956d750c29f2..d7a3d34d3ea804 100644 --- a/lldb/docs/use/tutorial.rst +++ b/lldb/docs/use/tutorial.rst @@ -1,73 +1,78 @@ Tutorial -Here's a short precis of how to run lldb if you are familiar with the gdb -command set. We will start with some details on lldb command structure and -syntax to help orient you. +This document describes how to use lldb if you are already familiar with +gdb's command set. We will start with some details on lldb command structure and +syntax. Command Structure - -Unlike gdb's command set, which is rather free-form, we tried to make the lldb command syntax fairly structured. The commands are all of the form: +Unlike gdb's quite free-form commands, lldb's are more structured. All commands +are of the form: :: [-options [option-value]] [argument [argument...]] -The command line parsing is done before command execution, so it is uniform -across all the commands. The command syntax for basic commands is very simple, -arguments, options and option values are all white-space separated, and -either single or double-quotes (in pairs) are used to protect white-spaces -in an argument. If you need to put a backslash or double-quote character in an -argument you back-slash it in the argument. That makes the command syntax more -regular, but it also means you may have to quote some arguments in lldb that -you wouldn't in gdb. +The command line parsing is done before command execution, so it is the same for +all commands. The command syntax for basic commands is very simple. -There is one other special quote character in lldb - the backtick. +* Arguments, options and option values are all white-space separated. +* Either single ``'`` or double-quotes ``"`` (in pairs) are used to protect white-spaces + in an argument. +* Escape backslashes and double quotes within arguments should be escaped + with a backslash ``\``. + +This makes lldb's commands more regular, but it also means you may have to quote +some arguments in lldb that you wouldn't in gdb. + +There is one other special quote character in lldb - the backtick `. If you put backticks around an argument or option value, lldb will run the text of the value through the expression parser, and the result of the expression -will be passed to the command. So for instance, if "len" is a local -int variable with the value 5, then the command: +will be passed to the command. So for instance, if ``len`` is a local +``int`` variable with the value ``5``, then the command: :: (lldb) memory read -c `len` 0x12345 -will receive the value 5 for the count option, rather than the string "len". - +Will receive the value ``5`` for the count option, rather than the string ``len``. Options can be placed anywhere on the command line, but if the arguments begin -with a "-" then you have to tell lldb that you're done with options for the -current command by adding an option termination: "--". So for instance, if you -want to launch a process and give the "process launch" command the -"--stop-at-entry" option, yet you want the process you are about to launch to -be launched with the arguments "-program_arg value", you would type: +with a ``-`` then you have to tell lldb that you're done with options for the +current command by adding an option termination: ``--``. + +So for instance, if you want to launch a process and give the ``process launch`` +command the ``--stop-at-entry`` option, yet you want the process you are about +to launch to be launched with the arguments ``-program_arg value``, you would type: :: (lldb) process launch --stop-at-entry -- -program_arg value We also tried to reduce the number of special purpose argument parsers, which -sometimes forces the user to be a little more explicit about stating their
[Lldb-commits] [lldb] [lldb][Docs] Remove .txt copy of tutorial (PR #90585)
llvmbot wrote: @llvm/pr-subscribers-lldb Author: David Spickett (DavidSpickett) Changes This was last modified in 4fd3347d6e4b0c873c789528e1c9a1b55990d1b6 in 2021 and was made obsolete by the RST version that edb874b2310dc6eeaa27330ca1b1c013da7bdd65 added in 2019. There are some differences but at this point, I'd bet the RST is the correct one. --- Full diff: https://github.com/llvm/llvm-project/pull/90585.diff 1 Files Affected: - (removed) lldb/docs/lldb-for-gdb-users.txt (-488) ``diff diff --git a/lldb/docs/lldb-for-gdb-users.txt b/lldb/docs/lldb-for-gdb-users.txt deleted file mode 100644 index e5eae376bb4807..00 --- a/lldb/docs/lldb-for-gdb-users.txt +++ /dev/null @@ -1,488 +0,0 @@ -Here's a short precis of how to run lldb if you are familiar with the -gdb command set: - - -1) LLDB Command Structure: - -First some details on lldb command structure to help orient you... - -Unlike gdb's command set, which is rather free-form, we tried to make -the lldb command syntax fairly structured. The commands are all of the -form - - [-options [option-value]] [argument [argument...]] - -The command line parsing is done before command execution, so it is -uniform across all the commands. The command syntax is very simple, -basically arguments, options and option values are all white-space -separated. If you need to put a backslash or double-quote character -in an argument you back-slash it in the argument. That makes the -command syntax more regular, but it also means you may have to -quote some arguments in lldb that you wouldn't in gdb. - -Options can be placed anywhere on the command line, but if the arguments -begin with a "-" then you have to tell lldb that you're done with options -using the "--" option. So for instance, the "process launch" command takes -the "-s" option to mean "stop the process at the first instruction". It's -arguments are the arguments you are passing to the program. So if you wanted -to pass an argument that contained a "-" you would have to do: - -(lldb) process launch -- -program_arg value - -We also tried to reduce the number of special purpose argument -parsers, which sometimes forces the user to be a little more explicit -about stating their intentions. The first instance you'll note of -this is the breakpoint command. In gdb, to set a breakpoint, you -would just say: - -(gdb) break foo.c:12 - -or - -(gdb) break foo - -if foo is a function. As time went on, the parser that tells foo.c:12 -from foo from foo.c::foo (which means the function foo in the file -foo.c) got more and more complex and bizarre, and especially in C++ -there are times where there's really no way to specify the function -you want to break on. The lldb commands are more verbose but also precise. -So you say: - -(lldb) breakpoint set -f foo.c -l 12 - -to set a file & line breakpoint. To set a breakpoint on a function -by name, you do: - -(lldb) breakpoint set -n foo - -This can allow us to be more expressive, so you can say: - -(lldb) breakpoint set -M foo - -to break on all C++ methods named foo, or: - -(lldb) breakpoint set -S alignLeftEdges: - -to set a breakpoint on all ObjC selectors called alignLeftEdges:. It -also makes it easy to compose specifications, like: - -(lldb) breakpoint set -s foo.dylib -n foo - -for all functions called foo in the shared library foo.dylib. Suggestions -on more interesting primitives of this sort are also very welcome. - -So for instance: - -(lldb) breakpoint set -n "-[SKTGraphicView alignLeftEdges:]" - -Just like gdb, the lldb command interpreter does a shortest unique -string match on command names, so the previous command can also be -typed: - -(lldb) b s -n "-[SKTGraphicView alignLeftEdges:]" - -lldb also supports command completion for source file names, symbol -names, file names, etc. Completion is initiated by a hitting a . -Individual options in a command can have different completers, so for -instance the -f option in "breakpoint" completes to source files, the --s option to currently loaded shared libraries, etc... We can even do -things like if you specify -s, and are completing on -f, we will only -list source files in the shared library specified by -s... - -The individual commands are pretty extensively documented, using -the "help" command. And there is an "apropos" command that will -search the help for a particular word and dump a summary help string -for each matching command. - -Finally, there is a mechanism to construct aliases for commonly used -commands. So for instance if you get annoyed typing - -(lldb) b s -f foo.c -l 12 - -you can do: - -(lldb) command alias bfl breakpoint set -f %1 -l %2 -(lldb) bfl foo.c 12 - -We have added a few aliases for commonly used commands (e.g. "step", -"next" and "continue") but we haven't tried to be exhaustive because -in our experience it is more convenient to make the basic commands -unique down to a letter or two, and then learn these sequences than -fill the
[Lldb-commits] [lldb] [lldb][Docs] Remove .txt copy of tutorial (PR #90585)
https://github.com/DavidSpickett created https://github.com/llvm/llvm-project/pull/90585 This was last modified in 4fd3347d6e4b0c873c789528e1c9a1b55990d1b6 in 2021 and was made obsolete by the RST version that edb874b2310dc6eeaa27330ca1b1c013da7bdd65 added in 2019. There are some differences but at this point, I'd bet the RST is the correct one. >From 3943242eb3f484a370cacffcf4c490fe8f62c826 Mon Sep 17 00:00:00 2001 From: David Spickett Date: Tue, 30 Apr 2024 11:15:07 +0100 Subject: [PATCH] [lldb][Docs] Remove .txt copy of tutorial This was last modified in 4fd3347d6e4b0c873c789528e1c9a1b55990d1b6 in 2021 and was made obselete by the RST version that edb874b2310dc6eeaa27330ca1b1c013da7bdd65 added in 2019. There are some differences but at this point, I'd bet the RST is the correct one. --- lldb/docs/lldb-for-gdb-users.txt | 488 --- 1 file changed, 488 deletions(-) delete mode 100644 lldb/docs/lldb-for-gdb-users.txt diff --git a/lldb/docs/lldb-for-gdb-users.txt b/lldb/docs/lldb-for-gdb-users.txt deleted file mode 100644 index e5eae376bb4807..00 --- a/lldb/docs/lldb-for-gdb-users.txt +++ /dev/null @@ -1,488 +0,0 @@ -Here's a short precis of how to run lldb if you are familiar with the -gdb command set: - - -1) LLDB Command Structure: - -First some details on lldb command structure to help orient you... - -Unlike gdb's command set, which is rather free-form, we tried to make -the lldb command syntax fairly structured. The commands are all of the -form - - [-options [option-value]] [argument [argument...]] - -The command line parsing is done before command execution, so it is -uniform across all the commands. The command syntax is very simple, -basically arguments, options and option values are all white-space -separated. If you need to put a backslash or double-quote character -in an argument you back-slash it in the argument. That makes the -command syntax more regular, but it also means you may have to -quote some arguments in lldb that you wouldn't in gdb. - -Options can be placed anywhere on the command line, but if the arguments -begin with a "-" then you have to tell lldb that you're done with options -using the "--" option. So for instance, the "process launch" command takes -the "-s" option to mean "stop the process at the first instruction". It's -arguments are the arguments you are passing to the program. So if you wanted -to pass an argument that contained a "-" you would have to do: - -(lldb) process launch -- -program_arg value - -We also tried to reduce the number of special purpose argument -parsers, which sometimes forces the user to be a little more explicit -about stating their intentions. The first instance you'll note of -this is the breakpoint command. In gdb, to set a breakpoint, you -would just say: - -(gdb) break foo.c:12 - -or - -(gdb) break foo - -if foo is a function. As time went on, the parser that tells foo.c:12 -from foo from foo.c::foo (which means the function foo in the file -foo.c) got more and more complex and bizarre, and especially in C++ -there are times where there's really no way to specify the function -you want to break on. The lldb commands are more verbose but also precise. -So you say: - -(lldb) breakpoint set -f foo.c -l 12 - -to set a file & line breakpoint. To set a breakpoint on a function -by name, you do: - -(lldb) breakpoint set -n foo - -This can allow us to be more expressive, so you can say: - -(lldb) breakpoint set -M foo - -to break on all C++ methods named foo, or: - -(lldb) breakpoint set -S alignLeftEdges: - -to set a breakpoint on all ObjC selectors called alignLeftEdges:. It -also makes it easy to compose specifications, like: - -(lldb) breakpoint set -s foo.dylib -n foo - -for all functions called foo in the shared library foo.dylib. Suggestions -on more interesting primitives of this sort are also very welcome. - -So for instance: - -(lldb) breakpoint set -n "-[SKTGraphicView alignLeftEdges:]" - -Just like gdb, the lldb command interpreter does a shortest unique -string match on command names, so the previous command can also be -typed: - -(lldb) b s -n "-[SKTGraphicView alignLeftEdges:]" - -lldb also supports command completion for source file names, symbol -names, file names, etc. Completion is initiated by a hitting a . -Individual options in a command can have different completers, so for -instance the -f option in "breakpoint" completes to source files, the --s option to currently loaded shared libraries, etc... We can even do -things like if you specify -s, and are completing on -f, we will only -list source files in the shared library specified by -s... - -The individual commands are pretty extensively documented, using -the "help" command. And there is an "apropos" command that will -search the help for a particular word and dump a summary help string -for each matching command. - -Finally, there is a mechanism to construct aliases for commonly used -commands.
[Lldb-commits] [lldb] [lldb][Docs] Sort documented packets alphabetically (PR #90584)
llvmbot wrote: @llvm/pr-subscribers-lldb Author: David Spickett (DavidSpickett) Changes For the platform and extension doc. Also add links in the extension doc to the GDB specs we're extending. --- Patch is 170.36 KiB, truncated to 20.00 KiB below, full version: https://github.com/llvm/llvm-project/pull/90584.diff 2 Files Affected: - (modified) lldb/docs/resources/lldbgdbremote.md (+1623-1618) - (modified) lldb/docs/resources/lldbplatformpackets.md (+15-15) ``diff diff --git a/lldb/docs/resources/lldbgdbremote.md b/lldb/docs/resources/lldbgdbremote.md index aaf903c9a5d13b..1467723fb79dce 100644 --- a/lldb/docs/resources/lldbgdbremote.md +++ b/lldb/docs/resources/lldbgdbremote.md @@ -1,14 +1,19 @@ # GDB Remote Protocol Extensions LLDB has added new GDB server packets to better support multi-threaded and -remote debugging. +remote debugging. These extend the +[protocol defined by GDB ](https://sourceware.org/gdb/current/onlinedocs/gdb.html/Packets.html#Packets) (and [this page](https://sourceware.org/gdb/current/onlinedocs/gdb.html/Host-I_002fO-Packets.html#Host-I_002fO-Packets) for `vFile` packets). -Why? Normally you need to start the correct GDB and the -correct GDB server when debugging. If you have mismatch, then things go wrong -very quickly. LLDB makes extensive use of the GDB remote protocol and we -wanted to make sure that the experience was a bit more dynamic where we can -discover information about a remote target without having to know anything up -front. +If a packet is restated here it is because LLDB's version has some behaviour +difference to GDB's version, or it provides some context for a following LLDB +extension packet. + +Why did we add these? The most common reason is flexibility. Normally you need +to start the correct GDB and the correct GDB server when debugging. If you have +mismatch, then things go wrong very quickly. LLDB makes extensive use of the GDB +remote protocol and we wanted to make sure that the experience was a bit more +dynamic where we can discover information about a remote target without having +to know anything up front. We also ran into performance issues with the existing GDB remote protocol that can be overcome when using a reliable communications layer. @@ -22,67 +27,48 @@ We prefer to be able to dynamically determine what kind of architecture, OS and vendor we are debugging, as well as how things are laid out when it comes to the thread register contexts. -Below are the details on the new packets we have added above and beyond the -standard GDB remote protocol packets. - -## QStartNoAckMode +## _M\,\ -Try to enable no ACK mode to skip sending ACKs and NACKs. +Allocate memory on the remote target with the specified size and +permissions. -Having to send an ACK/NACK after every packet slows things down a bit, so we -have a way to disable ACK packets to minimize the traffic for reliable -communication interfaces (like sockets). Below GDB or LLDB will send this -packet to try and disable ACKs. All lines that start with "send packet: " are -from GDB/LLDB, and all lines that start with "read packet: " are from the GDB -remote server: +The allocate memory packet starts with `_M,`. It returns a +raw big endian address value, or an empty response for unimplemented, or `EXX` for an error +code. The packet is formatted as: ``` -send packet: $QStartNoAckMode#b0 -read packet: + -read packet: $OK#9a -send packet: + +char packet[256]; +int packet_len; +packet_len = ::snprintf ( +packet, +sizeof(packet), +"_M%zx,%s%s%s", +(size_t)size, +permissions & lldb::ePermissionsReadable ? "r" : "", +permissions & lldb::ePermissionsWritable ? "w" : "", +permissions & lldb::ePermissionsExecutable ? "x" : ""); ``` -**Priority To Implement:** High. Any GDB remote server that can implement this -should if the connection is reliable. This improves packet throughput and increases -the performance of the connection. - -## QSupported - -Query the GDB remote server for features it supports - -QSupported is a standard GDB Remote Serial Protocol packet, but -there are several additions to the response that lldb can parse. -They are not all listed here. - -An example exchange: -``` -send packet: qSupported:xmlRegisters=i386,arm,mips,arc;multiprocess+;fork-events+;vfork-events+ +You request a size and give the permissions. This packet does NOT need to be +implemented if you don't want to support running JITed code. The return value +is just the address of the newly allocated memory as raw big endian hex bytes. -read packet: qXfer:features:read+;PacketSize=2;qEcho+;native-signals+;SupportedCompressions=lzfse,zlib-deflate,lz4,lzma;SupportedWatchpointTypes=aarch64-mask,aarch64-bas; -``` +**Priority To Implement:** High if you want LLDB to be able to JIT code and run +that code. JIT code also needs data which is also allocated and tracked. Low if +you don't support running JIT'ed code. -In the example above,
[Lldb-commits] [lldb] [lldb][Windows] Fixed unresolved test lldb-api python_api/debugger/TestDebuggerAPI.py (PR #90580)
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Dmitry Vasilyev (slydiman)
Changes
It is necessary to select the expected platform at the beginning. In case of
`Windows` host platform1.GetName() returned `host`. platform2.GetName()
returned `remote-linux`, but platform2.GetWorkingDirectory() was None and
finally
```
File "llvm-project\lldb\test\API\python_api\debugger\TestDebuggerAPI.py",
line 108, in test_CreateTarget_platform
platform2.GetWorkingDirectory().endswith("bar"),
AttributeError: 'NoneType' object has no attribute 'endswith'
```
---
Full diff: https://github.com/llvm/llvm-project/pull/90580.diff
1 Files Affected:
- (modified) lldb/test/API/python_api/debugger/TestDebuggerAPI.py (+1)
``diff
diff --git a/lldb/test/API/python_api/debugger/TestDebuggerAPI.py
b/lldb/test/API/python_api/debugger/TestDebuggerAPI.py
index 522de2466012ed..3d6484e5c9fbc4 100644
--- a/lldb/test/API/python_api/debugger/TestDebuggerAPI.py
+++ b/lldb/test/API/python_api/debugger/TestDebuggerAPI.py
@@ -95,6 +95,7 @@ def test_CreateTarget_platform(self):
exe = self.getBuildArtifact("a.out")
self.yaml2obj("elf.yaml", exe)
error = lldb.SBError()
+self.dbg.SetSelectedPlatform(lldb.SBPlatform("remote-linux"))
target1 = self.dbg.CreateTarget(exe, None, "remote-linux", False,
error)
self.assertSuccess(error)
platform1 = target1.GetPlatform()
``
https://github.com/llvm/llvm-project/pull/90580
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][Windows] Fixed unresolved test lldb-api python_api/debugger/TestDebuggerAPI.py (PR #90580)
https://github.com/slydiman created
https://github.com/llvm/llvm-project/pull/90580
It is necessary to select the expected platform at the beginning. In case of
`Windows` host platform1.GetName() returned `host`. platform2.GetName()
returned `remote-linux`, but platform2.GetWorkingDirectory() was None and
finally
```
File "llvm-project\lldb\test\API\python_api\debugger\TestDebuggerAPI.py",
line 108, in test_CreateTarget_platform
platform2.GetWorkingDirectory().endswith("bar"),
AttributeError: 'NoneType' object has no attribute 'endswith'
```
>From 0d6ff964ed83e06ed3947d709884ed6dd43e90b5 Mon Sep 17 00:00:00 2001
From: Dmitry Vasilyev
Date: Tue, 30 Apr 2024 13:42:45 +0400
Subject: [PATCH] [lldb][Windows] Fixed unresolved test lldb-api
python_api/debugger/TestDebuggerAPI.py
It is necessary to select the expected platform at the beginning.
In case of `Windows` host platform1.GetName() returned `host`.
platform2.GetName() returned `remote-linux`, but
platform2.GetWorkingDirectory() was None and finally
```
File "llvm-project\lldb\test\API\python_api\debugger\TestDebuggerAPI.py",
line 108, in test_CreateTarget_platform
platform2.GetWorkingDirectory().endswith("bar"),
AttributeError: 'NoneType' object has no attribute 'endswith'
```
---
lldb/test/API/python_api/debugger/TestDebuggerAPI.py | 1 +
1 file changed, 1 insertion(+)
diff --git a/lldb/test/API/python_api/debugger/TestDebuggerAPI.py
b/lldb/test/API/python_api/debugger/TestDebuggerAPI.py
index 522de2466012ed..3d6484e5c9fbc4 100644
--- a/lldb/test/API/python_api/debugger/TestDebuggerAPI.py
+++ b/lldb/test/API/python_api/debugger/TestDebuggerAPI.py
@@ -95,6 +95,7 @@ def test_CreateTarget_platform(self):
exe = self.getBuildArtifact("a.out")
self.yaml2obj("elf.yaml", exe)
error = lldb.SBError()
+self.dbg.SetSelectedPlatform(lldb.SBPlatform("remote-linux"))
target1 = self.dbg.CreateTarget(exe, None, "remote-linux", False,
error)
self.assertSuccess(error)
platform1 = target1.GetPlatform()
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [PAC][lldb][Dwarf] Support `__ptrauth`-qualified types in user expressions (PR #84387)
https://github.com/kovdan01 closed https://github.com/llvm/llvm-project/pull/84387 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
