[Lldb-commits] [PATCH] D159408: Switch over to using the LLVM archive parser for BSD archives.
This revision was automatically updated to reflect the committed changes.
Closed by commit rGd4a141ef932a: Switch over to using the LLVM archive parser
for BSD archives. (authored by clayborg).
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D159408/new/
https://reviews.llvm.org/D159408
Files:
lldb/source/Plugins/ObjectContainer/BSD-Archive/ObjectContainerBSDArchive.cpp
lldb/source/Plugins/ObjectContainer/BSD-Archive/ObjectContainerBSDArchive.h
lldb/test/API/functionalities/archives/TestBSDArchives.py
lldb/test/API/functionalities/archives/b.c
lldb/test/API/functionalities/archives/c.c
Index: lldb/test/API/functionalities/archives/c.c
===
--- lldb/test/API/functionalities/archives/c.c
+++ lldb/test/API/functionalities/archives/c.c
@@ -1,5 +1,6 @@
static int __c_global = 3;
-
+char __extra[4096]; // Make sure sizeof b.o differs from a.o and c.o
+char __extra2[4096]; // Make sure sizeof b.o differs from a.o and c.o
int c(int arg) {
int result = arg + __c_global;
return result;
Index: lldb/test/API/functionalities/archives/b.c
===
--- lldb/test/API/functionalities/archives/b.c
+++ lldb/test/API/functionalities/archives/b.c
@@ -1,4 +1,5 @@
static int __b_global = 2;
+char __extra[4096]; // Make sure sizeof b.o differs from a.o and c.o
int b(int arg) {
int result = arg + __b_global;
Index: lldb/test/API/functionalities/archives/TestBSDArchives.py
===
--- lldb/test/API/functionalities/archives/TestBSDArchives.py
+++ lldb/test/API/functionalities/archives/TestBSDArchives.py
@@ -70,12 +70,6 @@
)
self.expect_var_path("__b_global", type="int", value="2")
-# Test loading thin archives
-archive_path = self.getBuildArtifact("libbar.a")
-module_specs = lldb.SBModuleSpecList.GetModuleSpecifications(archive_path)
-num_specs = module_specs.GetSize()
-self.assertEqual(num_specs, 1)
-self.assertEqual(module_specs.GetSpecAtIndex(0).GetObjectName(), "c.o")
def check_frame_variable_errors(self, thread, error_strings):
command_result = lldb.SBCommandReturnObject()
@@ -129,6 +123,53 @@
]
self.check_frame_variable_errors(thread, error_strings)
+@skipIfRemote
+def test_archive_specifications(self):
+"""
+Create archives and make sure the information we get when retrieving
+the modules specifications is correct.
+"""
+self.build()
+libbar_path = self.getBuildArtifact("libbar.a")
+libfoo_path = self.getBuildArtifact("libfoo.a")
+libfoothin_path = self.getBuildArtifact("libfoo-thin.a")
+objfile_a = self.getBuildArtifact("a.o")
+objfile_b = self.getBuildArtifact("b.o")
+objfile_c = self.getBuildArtifact("c.o")
+size_a = os.path.getsize(objfile_a)
+size_b = os.path.getsize(objfile_b)
+size_c = os.path.getsize(objfile_c)
+
+# Test loading normal archives
+module_specs = lldb.SBModuleSpecList.GetModuleSpecifications(libfoo_path)
+num_specs = module_specs.GetSize()
+self.assertEqual(num_specs, 2)
+spec = module_specs.GetSpecAtIndex(0)
+self.assertEqual(spec.GetObjectName(), "a.o")
+self.assertEqual(spec.GetObjectSize(), size_a)
+spec = module_specs.GetSpecAtIndex(1)
+self.assertEqual(spec.GetObjectName(), "b.o")
+self.assertEqual(spec.GetObjectSize(), size_b)
+
+# Test loading thin archives
+module_specs = lldb.SBModuleSpecList.GetModuleSpecifications(libbar_path)
+num_specs = module_specs.GetSize()
+self.assertEqual(num_specs, 1)
+spec = module_specs.GetSpecAtIndex(0)
+self.assertEqual(spec.GetObjectName(), "c.o")
+self.assertEqual(spec.GetObjectSize(), size_c)
+
+module_specs = lldb.SBModuleSpecList.GetModuleSpecifications(libfoothin_path)
+num_specs = module_specs.GetSize()
+self.assertEqual(num_specs, 2)
+spec = module_specs.GetSpecAtIndex(0)
+self.assertEqual(spec.GetObjectName(), "a.o")
+self.assertEqual(spec.GetObjectSize(), size_a)
+spec = module_specs.GetSpecAtIndex(1)
+self.assertEqual(spec.GetObjectName(), "b.o")
+self.assertEqual(spec.GetObjectSize(), size_b, libfoothin_path)
+
+
@skipIfRemote
@skipUnlessDarwin
def test_frame_var_errors_when_thin_archive_malformed(self):
@@ -142,6 +183,8 @@
libfoo_path = self.getBuildArtifact("libfoo.a")
libthin_path = self.getBuildArtifact("libfoo-thin.a")
objfile_a = self.getBuildArtifact("a.o")
+objfile_b = self.getBuildArtifact("b.o")
+objfile_c = self.getBuildArtifact("c.o")
# Replace the libfoo.a file with a thin archive containing the
[Lldb-commits] [lldb] d4a141e - Switch over to using the LLVM archive parser for BSD archives.
Author: Greg Clayton
Date: 2023-09-05T16:54:05-07:00
New Revision: d4a141ef932a596df61581090b70d0b546de68b2
URL:
https://github.com/llvm/llvm-project/commit/d4a141ef932a596df61581090b70d0b546de68b2
DIFF:
https://github.com/llvm/llvm-project/commit/d4a141ef932a596df61581090b70d0b546de68b2.diff
LOG: Switch over to using the LLVM archive parser for BSD archives.
Our LLDB parser didn't correctly handle archives of all flavors on different
systems, it currently only correctly handled BSD archives, normal and thin, on
macOS, but I noticed that it was getting incorrect information when decoding a
variety of archives on linux. There were subtle changes to how names were
encoded that we didn't handle correctly and we also didn't set the result of
GetObjectSize() correctly as there was some bad math. This didn't matter when
exracting .o files from .a files for LLDB because the size was always way too
big, but it was big enough to at least read enough bytes for each object within
the archive.
This patch does the following:
- switch over to use LLVM's archive parser and avoids previous code duplication
- remove values from ObjectContainerBSDArchive::Object that we don't use like:
- uid
- gid
- mode
- fix ths ObjectContainerBSDArchive::Object::file_size value to be correct
- adds tests to test that we get the correct module specifications
Differential Revision: https://reviews.llvm.org/D159408
Added:
Modified:
lldb/source/Plugins/ObjectContainer/BSD-Archive/ObjectContainerBSDArchive.cpp
lldb/source/Plugins/ObjectContainer/BSD-Archive/ObjectContainerBSDArchive.h
lldb/test/API/functionalities/archives/TestBSDArchives.py
lldb/test/API/functionalities/archives/b.c
lldb/test/API/functionalities/archives/c.c
Removed:
diff --git
a/lldb/source/Plugins/ObjectContainer/BSD-Archive/ObjectContainerBSDArchive.cpp
b/lldb/source/Plugins/ObjectContainer/BSD-Archive/ObjectContainerBSDArchive.cpp
index 51b2535421a6a9d..7aa5b8d81890aee 100644
---
a/lldb/source/Plugins/ObjectContainer/BSD-Archive/ObjectContainerBSDArchive.cpp
+++
b/lldb/source/Plugins/ObjectContainer/BSD-Archive/ObjectContainerBSDArchive.cpp
@@ -10,7 +10,6 @@
#if defined(_WIN32) || defined(__ANDROID__)
// Defines from ar, missing on Windows
-#define ARMAG "!\n"
#define SARMAG 8
#define ARFMAG "`\n"
@@ -32,9 +31,11 @@ typedef struct ar_hdr {
#include "lldb/Host/FileSystem.h"
#include "lldb/Symbol/ObjectFile.h"
#include "lldb/Utility/ArchSpec.h"
+#include "lldb/Utility/LLDBLog.h"
#include "lldb/Utility/Stream.h"
#include "lldb/Utility/Timer.h"
+#include "llvm/Object/Archive.h"
#include "llvm/Support/MemoryBuffer.h"
using namespace lldb;
@@ -49,158 +50,19 @@ ObjectContainerBSDArchive::Object::Object() : ar_name() {}
void ObjectContainerBSDArchive::Object::Clear() {
ar_name.Clear();
modification_time = 0;
- uid = 0;
- gid = 0;
- mode = 0;
size = 0;
file_offset = 0;
file_size = 0;
}
-lldb::offset_t ObjectContainerBSDArchive::Object::ExtractFromThin(
-const DataExtractor , lldb::offset_t offset,
-llvm::StringRef stringTable) {
- size_t ar_name_len = 0;
- std::string str;
- char *err;
-
- // File header
- //
- // The common format is as follows.
- //
- // Offset Length NameFormat
- // 0 16 File name ASCII right padded with spaces (no spaces
- // allowed in file name)
- // 16 12 File modDecimal as cstring right padded with
- // spaces
- // 28 6 Owner IDDecimal as cstring right padded with
- // spaces
- // 34 6 Group IDDecimal as cstring right padded with
- // spaces
- // 40 8 File mode Octal as cstring right padded with
- // spaces
- // 48 10 File byte size Decimal as cstring right padded with
- // spaces
- // 58 2 File magic 0x60 0x0A
-
- // Make sure there is enough data for the file header and bail if not
- if (!data.ValidOffsetForDataOfSize(offset, 60))
-return LLDB_INVALID_OFFSET;
-
- str.assign((const char *)data.GetData(, 16), 16);
- if (!(llvm::StringRef(str).startswith("//") || stringTable.empty())) {
-// Strip off any trailing spaces.
-const size_t last_pos = str.find_last_not_of(' ');
-if (last_pos != std::string::npos) {
- if (last_pos + 1 < 16)
-str.erase(last_pos + 1);
-}
-int start = strtoul(str.c_str() + 1, , 10);
-int end = stringTable.find('\n', start);
-str.assign(stringTable.data() + start, end - start - 1);
-ar_name.SetCString(str.c_str());
- }
-
- str.assign((const char *)data.GetData(, 12), 12);
- modification_time = strtoul(str.c_str(), , 10);
-
- str.assign((const char *)data.GetData(, 6), 6);
- uid = strtoul(str.c_str(), , 10);
-
- str.assign((const char *)data.GetData(, 6), 6);
- gid = strtoul(str.c_str(), , 10);
-
- str.assign((const
[Lldb-commits] [PATCH] D159408: Switch over to using the LLVM archive parser for BSD archives.
JDevlieghere accepted this revision. JDevlieghere added a comment. This revision is now accepted and ready to land. LGTM! Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D159408/new/ https://reviews.llvm.org/D159408 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D159408: Switch over to using the LLVM archive parser for BSD archives.
clayborg updated this revision to Diff 555933.
clayborg added a comment.
Log any errors we encounter during archive object parsing.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D159408/new/
https://reviews.llvm.org/D159408
Files:
lldb/source/Plugins/ObjectContainer/BSD-Archive/ObjectContainerBSDArchive.cpp
lldb/source/Plugins/ObjectContainer/BSD-Archive/ObjectContainerBSDArchive.h
lldb/test/API/functionalities/archives/TestBSDArchives.py
lldb/test/API/functionalities/archives/b.c
lldb/test/API/functionalities/archives/c.c
Index: lldb/test/API/functionalities/archives/c.c
===
--- lldb/test/API/functionalities/archives/c.c
+++ lldb/test/API/functionalities/archives/c.c
@@ -1,5 +1,6 @@
static int __c_global = 3;
-
+char __extra[4096]; // Make sure sizeof b.o differs from a.o and c.o
+char __extra2[4096]; // Make sure sizeof b.o differs from a.o and c.o
int c(int arg) {
int result = arg + __c_global;
return result;
Index: lldb/test/API/functionalities/archives/b.c
===
--- lldb/test/API/functionalities/archives/b.c
+++ lldb/test/API/functionalities/archives/b.c
@@ -1,4 +1,5 @@
static int __b_global = 2;
+char __extra[4096]; // Make sure sizeof b.o differs from a.o and c.o
int b(int arg) {
int result = arg + __b_global;
Index: lldb/test/API/functionalities/archives/TestBSDArchives.py
===
--- lldb/test/API/functionalities/archives/TestBSDArchives.py
+++ lldb/test/API/functionalities/archives/TestBSDArchives.py
@@ -70,12 +70,6 @@
)
self.expect_var_path("__b_global", type="int", value="2")
-# Test loading thin archives
-archive_path = self.getBuildArtifact("libbar.a")
-module_specs = lldb.SBModuleSpecList.GetModuleSpecifications(archive_path)
-num_specs = module_specs.GetSize()
-self.assertEqual(num_specs, 1)
-self.assertEqual(module_specs.GetSpecAtIndex(0).GetObjectName(), "c.o")
def check_frame_variable_errors(self, thread, error_strings):
command_result = lldb.SBCommandReturnObject()
@@ -129,6 +123,53 @@
]
self.check_frame_variable_errors(thread, error_strings)
+@skipIfRemote
+def test_archive_specifications(self):
+"""
+Create archives and make sure the information we get when retrieving
+the modules specifications is correct.
+"""
+self.build()
+libbar_path = self.getBuildArtifact("libbar.a")
+libfoo_path = self.getBuildArtifact("libfoo.a")
+libfoothin_path = self.getBuildArtifact("libfoo-thin.a")
+objfile_a = self.getBuildArtifact("a.o")
+objfile_b = self.getBuildArtifact("b.o")
+objfile_c = self.getBuildArtifact("c.o")
+size_a = os.path.getsize(objfile_a)
+size_b = os.path.getsize(objfile_b)
+size_c = os.path.getsize(objfile_c)
+
+# Test loading normal archives
+module_specs = lldb.SBModuleSpecList.GetModuleSpecifications(libfoo_path)
+num_specs = module_specs.GetSize()
+self.assertEqual(num_specs, 2)
+spec = module_specs.GetSpecAtIndex(0)
+self.assertEqual(spec.GetObjectName(), "a.o")
+self.assertEqual(spec.GetObjectSize(), size_a)
+spec = module_specs.GetSpecAtIndex(1)
+self.assertEqual(spec.GetObjectName(), "b.o")
+self.assertEqual(spec.GetObjectSize(), size_b)
+
+# Test loading thin archives
+module_specs = lldb.SBModuleSpecList.GetModuleSpecifications(libbar_path)
+num_specs = module_specs.GetSize()
+self.assertEqual(num_specs, 1)
+spec = module_specs.GetSpecAtIndex(0)
+self.assertEqual(spec.GetObjectName(), "c.o")
+self.assertEqual(spec.GetObjectSize(), size_c)
+
+module_specs = lldb.SBModuleSpecList.GetModuleSpecifications(libfoothin_path)
+num_specs = module_specs.GetSize()
+self.assertEqual(num_specs, 2)
+spec = module_specs.GetSpecAtIndex(0)
+self.assertEqual(spec.GetObjectName(), "a.o")
+self.assertEqual(spec.GetObjectSize(), size_a)
+spec = module_specs.GetSpecAtIndex(1)
+self.assertEqual(spec.GetObjectName(), "b.o")
+self.assertEqual(spec.GetObjectSize(), size_b, libfoothin_path)
+
+
@skipIfRemote
@skipUnlessDarwin
def test_frame_var_errors_when_thin_archive_malformed(self):
@@ -142,6 +183,8 @@
libfoo_path = self.getBuildArtifact("libfoo.a")
libthin_path = self.getBuildArtifact("libfoo-thin.a")
objfile_a = self.getBuildArtifact("a.o")
+objfile_b = self.getBuildArtifact("b.o")
+objfile_c = self.getBuildArtifact("c.o")
# Replace the libfoo.a file with a thin archive containing the same
# debug information (a.o, b.o). Then remove
[Lldb-commits] [PATCH] D157609: [lldb] Add more ways to find split DWARF files
clayborg added inline comments.
Comment at: lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp:1747-1754
if (!comp_dir) {
unit.SetDwoError(Status::createWithFormat(
"unable to locate relative .dwo debug file \"{0}\" for "
"skeleton DIE {1:x16} without valid DW_AT_comp_dir "
"attribute",
dwo_name, cu_die.GetOffset()));
return nullptr;
If we have no comp_dir, then we should still search for the file right? We are
returning early here without trying to use the search paths?
Comment at: lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp:1779
+FileSystem::Instance().Resolve(dirspec);
+if (!FileSystem::Instance().IsDirectory(dirspec))
+ continue;
Will this return false for a symlink to a directory?
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D157609/new/
https://reviews.llvm.org/D157609
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D159387: [lldb][NFCI] Remove unused method TypeCategoryMap::Get(uint32_t, ValueSP &)
This revision was automatically updated to reflect the committed changes.
Closed by commit rG5bff905c0de5: [lldb][NFCI] Remove unused method
TypeCategoryMap::Get(uint32_t, ValueSP ) (authored by bulbazord).
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D159387/new/
https://reviews.llvm.org/D159387
Files:
lldb/include/lldb/DataFormatters/TypeCategoryMap.h
lldb/source/DataFormatters/TypeCategoryMap.cpp
Index: lldb/source/DataFormatters/TypeCategoryMap.cpp
===
--- lldb/source/DataFormatters/TypeCategoryMap.cpp
+++ lldb/source/DataFormatters/TypeCategoryMap.cpp
@@ -139,20 +139,6 @@
return true;
}
-bool TypeCategoryMap::Get(uint32_t pos, ValueSP ) {
- std::lock_guard guard(m_map_mutex);
- MapIterator iter = m_map.begin();
- MapIterator end = m_map.end();
- while (pos > 0) {
-iter++;
-pos--;
-if (iter == end)
- return false;
- }
- entry = iter->second;
- return false;
-}
-
bool TypeCategoryMap::AnyMatches(
const FormattersMatchCandidate _type,
TypeCategoryImpl::FormatCategoryItems items, bool only_enabled,
Index: lldb/include/lldb/DataFormatters/TypeCategoryMap.h
===
--- lldb/include/lldb/DataFormatters/TypeCategoryMap.h
+++ lldb/include/lldb/DataFormatters/TypeCategoryMap.h
@@ -63,8 +63,6 @@
bool Get(KeyType name, ValueSP );
- bool Get(uint32_t pos, ValueSP );
-
void ForEach(ForEachCallback callback);
lldb::TypeCategoryImplSP GetAtIndex(uint32_t);
Index: lldb/source/DataFormatters/TypeCategoryMap.cpp
===
--- lldb/source/DataFormatters/TypeCategoryMap.cpp
+++ lldb/source/DataFormatters/TypeCategoryMap.cpp
@@ -139,20 +139,6 @@
return true;
}
-bool TypeCategoryMap::Get(uint32_t pos, ValueSP ) {
- std::lock_guard guard(m_map_mutex);
- MapIterator iter = m_map.begin();
- MapIterator end = m_map.end();
- while (pos > 0) {
-iter++;
-pos--;
-if (iter == end)
- return false;
- }
- entry = iter->second;
- return false;
-}
-
bool TypeCategoryMap::AnyMatches(
const FormattersMatchCandidate _type,
TypeCategoryImpl::FormatCategoryItems items, bool only_enabled,
Index: lldb/include/lldb/DataFormatters/TypeCategoryMap.h
===
--- lldb/include/lldb/DataFormatters/TypeCategoryMap.h
+++ lldb/include/lldb/DataFormatters/TypeCategoryMap.h
@@ -63,8 +63,6 @@
bool Get(KeyType name, ValueSP );
- bool Get(uint32_t pos, ValueSP );
-
void ForEach(ForEachCallback callback);
lldb::TypeCategoryImplSP GetAtIndex(uint32_t);
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] 5bff905 - [lldb][NFCI] Remove unused method TypeCategoryMap::Get(uint32_t, ValueSP &)
Author: Alex Langford
Date: 2023-09-05T10:53:56-07:00
New Revision: 5bff905c0de50ff87b73e6a1e93d0a5b0f38e1a9
URL:
https://github.com/llvm/llvm-project/commit/5bff905c0de50ff87b73e6a1e93d0a5b0f38e1a9
DIFF:
https://github.com/llvm/llvm-project/commit/5bff905c0de50ff87b73e6a1e93d0a5b0f38e1a9.diff
LOG: [lldb][NFCI] Remove unused method TypeCategoryMap::Get(uint32_t, ValueSP &)
Differential Revision: https://reviews.llvm.org/D159387
Added:
Modified:
lldb/include/lldb/DataFormatters/TypeCategoryMap.h
lldb/source/DataFormatters/TypeCategoryMap.cpp
Removed:
diff --git a/lldb/include/lldb/DataFormatters/TypeCategoryMap.h
b/lldb/include/lldb/DataFormatters/TypeCategoryMap.h
index d4f7634c90b065e..363d841b198a297 100644
--- a/lldb/include/lldb/DataFormatters/TypeCategoryMap.h
+++ b/lldb/include/lldb/DataFormatters/TypeCategoryMap.h
@@ -63,8 +63,6 @@ class TypeCategoryMap {
bool Get(KeyType name, ValueSP );
- bool Get(uint32_t pos, ValueSP );
-
void ForEach(ForEachCallback callback);
lldb::TypeCategoryImplSP GetAtIndex(uint32_t);
diff --git a/lldb/source/DataFormatters/TypeCategoryMap.cpp
b/lldb/source/DataFormatters/TypeCategoryMap.cpp
index 55635173cc8c56f..c3de9196e39c553 100644
--- a/lldb/source/DataFormatters/TypeCategoryMap.cpp
+++ b/lldb/source/DataFormatters/TypeCategoryMap.cpp
@@ -139,20 +139,6 @@ bool TypeCategoryMap::Get(KeyType name, ValueSP ) {
return true;
}
-bool TypeCategoryMap::Get(uint32_t pos, ValueSP ) {
- std::lock_guard guard(m_map_mutex);
- MapIterator iter = m_map.begin();
- MapIterator end = m_map.end();
- while (pos > 0) {
-iter++;
-pos--;
-if (iter == end)
- return false;
- }
- entry = iter->second;
- return false;
-}
-
bool TypeCategoryMap::AnyMatches(
const FormattersMatchCandidate _type,
TypeCategoryImpl::FormatCategoryItems items, bool only_enabled,
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][Docs] Add page about debugging lldb itself (PR #65332)
@@ -0,0 +1,254 @@ +Debugging LLDB +== + +This page details various ways to debug LLDB itself and other LLDB tools. If +you want to know how to use LLDB in general, please refer to +:doc:`/use/tutorial`. + +As LLDB is generally split into 2 tools, ``lldb`` and ``lldb-server`` +(``debugserver`` on Mac OS), the techniques shown here will not always apply to +both. With some knowledge of them all, you can mix and match as needed. + +In this document we refer to the initial ``lldb`` as the debugger and the +program being debugged as the debugee. + +Building For Debugging +-- + +To build LLDB with debugging information add the following to your CMake +configuration: + +:: + + -DCMAKE_BUILD_TYPE=Debug \ + -DLLDB_EXPORT_ALL_SYMBOLS=1 bulbazord wrote: I would also recommend explicitly turning on `LLVM_ENABLE_ASSERTIONS=On` as well -- Some bugs may be easier to diagnose if LLDB asserts instead of returning an error somewhere. https://github.com/llvm/llvm-project/pull/65332 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][Docs] Add page about debugging lldb itself (PR #65332)
https://github.com/bulbazord commented: Generally seems good to me. Thanks for taking the time to write this up. https://github.com/llvm/llvm-project/pull/65332 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][Docs] Add page about debugging lldb itself (PR #65332)
https://github.com/bulbazord edited https://github.com/llvm/llvm-project/pull/65332 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][Docs] Add page about debugging lldb itself (PR #65332)
@@ -0,0 +1,254 @@ +Debugging LLDB +== + +This page details various ways to debug LLDB itself and other LLDB tools. If +you want to know how to use LLDB in general, please refer to +:doc:`/use/tutorial`. + +As LLDB is generally split into 2 tools, ``lldb`` and ``lldb-server`` +(``debugserver`` on Mac OS), the techniques shown here will not always apply to +both. With some knowledge of them all, you can mix and match as needed. + +In this document we refer to the initial ``lldb`` as the debugger and the +program being debugged as the debugee. bulbazord wrote: How about `and the program being debugged as the inferior (sometimes referred to as the debugee).`? https://github.com/llvm/llvm-project/pull/65332 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][Docs] Add simpler "automatic" cross-compile option to build docs (PR #65311)
https://github.com/bulbazord approved this pull request. LGTM! Big fan of removing the "just" everywhere, I definitely agree that everyone's perspective is different;. https://github.com/llvm/llvm-project/pull/65311 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] be0e42c - [lldb][Plugins] Reflect structure changes in ObjectContainer
Author: Antonio Frighetto
Date: 2023-09-05T19:13:43+02:00
New Revision: be0e42c16b8cfb59d5e8e3527141cd7f4931cd17
URL:
https://github.com/llvm/llvm-project/commit/be0e42c16b8cfb59d5e8e3527141cd7f4931cd17
DIFF:
https://github.com/llvm/llvm-project/commit/be0e42c16b8cfb59d5e8e3527141cd7f4931cd17.diff
LOG: [lldb][Plugins] Reflect structure changes in ObjectContainer
Reflect recent changes made to MachO
`fileset_entry_command` struct.
Added:
Modified:
lldb/source/Plugins/ObjectContainer/Mach-O-Fileset/ObjectContainerMachOFileset.cpp
Removed:
diff --git
a/lldb/source/Plugins/ObjectContainer/Mach-O-Fileset/ObjectContainerMachOFileset.cpp
b/lldb/source/Plugins/ObjectContainer/Mach-O-Fileset/ObjectContainerMachOFileset.cpp
index 4f9661eb0cdf0b2..2dc71d85777ca7a 100644
---
a/lldb/source/Plugins/ObjectContainer/Mach-O-Fileset/ObjectContainerMachOFileset.cpp
+++
b/lldb/source/Plugins/ObjectContainer/Mach-O-Fileset/ObjectContainerMachOFileset.cpp
@@ -158,7 +158,7 @@ ParseFileset(DataExtractor , mach_header header,
if (lc.cmd == LC_FILESET_ENTRY) {
fileset_entry_command entry;
data.CopyData(load_cmd_offset, sizeof(fileset_entry_command), );
- lldb::offset_t entry_id_offset = load_cmd_offset + entry.entry_id;
+ lldb::offset_t entry_id_offset = load_cmd_offset + entry.entry_id.offset;
const char *id = data.GetCStr(_id_offset);
entries.emplace_back(entry.vmaddr + slide, entry.fileoff,
std::string(id));
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D159408: Switch over to using the LLVM archive parser for BSD archives.
JDevlieghere added a comment.
Overall this looks good, but instead of consuming all the errors, let's log
them with `LLDB_LOG_ERROR`. Note that the API is a bit tricky and still
requires you to provide a format string:
LLDB_LOG_ERROR(GetLog(LLDBLog::Object), something.takeError(), "context
before printing the actual error: {0}");
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D159408/new/
https://reviews.llvm.org/D159408
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] d227c8a - Add missing nullptr check.
Author: Adrian Prantl
Date: 2023-09-05T09:48:06-07:00
New Revision: d227c8a1200081fdab14e93165927787544c5f12
URL:
https://github.com/llvm/llvm-project/commit/d227c8a1200081fdab14e93165927787544c5f12
DIFF:
https://github.com/llvm/llvm-project/commit/d227c8a1200081fdab14e93165927787544c5f12.diff
LOG: Add missing nullptr check.
While it's the plugin's moral duty to also set the error, this code
can't depend on that.
Added:
Modified:
lldb/source/Expression/UserExpression.cpp
Removed:
diff --git a/lldb/source/Expression/UserExpression.cpp
b/lldb/source/Expression/UserExpression.cpp
index 93724af4322470b..e16a335d581a71b 100644
--- a/lldb/source/Expression/UserExpression.cpp
+++ b/lldb/source/Expression/UserExpression.cpp
@@ -255,7 +255,7 @@ UserExpression::Evaluate(ExecutionContext _ctx,
target->GetUserExpressionForLanguage(expr, full_prefix, language,
desired_type, options, ctx_obj,
error));
- if (error.Fail()) {
+ if (error.Fail() || !user_expression_sp) {
LLDB_LOG(log, "== [UserExpression::Evaluate] Getting expression: {0} ==",
error.AsCString());
return lldb::eExpressionSetupError;
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D112374: [clang] Implement ElaboratedType sugaring for types written bare
ldionne added a comment. (sorry, no idea why it says "this revision is now accepted and ready to land on my behalf, I was just removing the libc++ review group to clear our review queue) Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D112374/new/ https://reviews.llvm.org/D112374 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][Docs] Add simpler "automatic" cross-compile option to build docs (PR #65311)
https://github.com/JDevlieghere approved this pull request. https://github.com/llvm/llvm-project/pull/65311 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][Docs] Add page about debugging lldb itself (PR #65332)
@@ -0,0 +1,254 @@ +Debugging LLDB +== + +This page details various ways to debug LLDB itself and other LLDB tools. If +you want to know how to use LLDB in general, please refer to +:doc:`/use/tutorial`. + +As LLDB is generally split into 2 tools, ``lldb`` and ``lldb-server`` +(``debugserver`` on Mac OS), the techniques shown here will not always apply to +both. With some knowledge of them all, you can mix and match as needed. + +In this document we refer to the initial ``lldb`` as the debugger and the +program being debugged as the debugee. + +Building For Debugging +-- + +To build LLDB with debugging information add the following to your CMake +configuration: + +:: + + -DCMAKE_BUILD_TYPE=Debug \ + -DLLDB_EXPORT_ALL_SYMBOLS=1 + +Note that the ``lldb`` you will use to do the debugging does not itself need to +have debug information. + +Then build as you normally would. + +Debugging ``lldb`` +-- + +The simplest scenario is where we want to debug a local execution of ``lldb`` +like this one: + +:: + + ./bin/lldb test_program + +LLDB is like any other program, so you can use the same approach. + +:: + + ./bin/lldb -- ./bin/lldb /tmp/test.o + +That's it. At least, that's the minimum. There's nothing special about LLDB +being a debugger that means you can't attach another debugger to it like any +other program. + +What can be an issue is that both debuggers have command line interfaces which +makes it very confusing which one is which: + +:: + + (the debugger) + (lldb) run + Process 1741640 launched: '<...>/bin/lldb' (aarch64) + Process 1741640 stopped and restarted: thread 1 received signal: SIGCHLD + + (the debugee) + (lldb) target create "/tmp/test.o" + Current executable set to '/tmp/test.o' (aarch64). + +Another issue is that when you resume the debugee, it will not print the +``(lldb)`` prompt because as far as it knows it hasn't changed state. A quick +way around that is to type something that is clearly not a command and hit +enter. + +:: + + (lldb) Process 1742266 stopped and restarted: thread 1 received signal: SIGCHLD + Process 1742266 stopped + * thread #1, name = 'lldb', stop reason = signal SIGSTOP + frame #0: 0xed5bfbf0 libc.so.6`__GI___libc_read at read.c:26:10 + (lldb) c + Process 1742266 resuming + notacommand + error: 'notacommand' is not a valid command. + (lldb) + +You could just remember whether you are in the debugger or the debugee but +it's thinking overhead, and for interrupt based events you simply may not be +able to know. + +Here are some better approaches. First, you could use another debugger like GDB +to debug LLDB. Perhaps an IDE like XCode or Visual Studio Code. Something which JDevlieghere wrote: `s/XCode/Xcode` https://github.com/llvm/llvm-project/pull/65332 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][Docs] Add page about debugging lldb itself (PR #65332)
@@ -0,0 +1,254 @@ +Debugging LLDB +== + +This page details various ways to debug LLDB itself and other LLDB tools. If +you want to know how to use LLDB in general, please refer to +:doc:`/use/tutorial`. + +As LLDB is generally split into 2 tools, ``lldb`` and ``lldb-server`` +(``debugserver`` on Mac OS), the techniques shown here will not always apply to +both. With some knowledge of them all, you can mix and match as needed. + +In this document we refer to the initial ``lldb`` as the debugger and the +program being debugged as the debugee. JDevlieghere wrote: The rest of the docs often refer to the program being debugged as the _inferior_. I personally don't mind _debugee_ but inferior would definitely be more consistent/familiar. https://github.com/llvm/llvm-project/pull/65332 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][Docs] Add page about debugging lldb itself (PR #65332)
@@ -0,0 +1,254 @@ +Debugging LLDB +== + +This page details various ways to debug LLDB itself and other LLDB tools. If +you want to know how to use LLDB in general, please refer to +:doc:`/use/tutorial`. + +As LLDB is generally split into 2 tools, ``lldb`` and ``lldb-server`` +(``debugserver`` on Mac OS), the techniques shown here will not always apply to +both. With some knowledge of them all, you can mix and match as needed. + +In this document we refer to the initial ``lldb`` as the debugger and the +program being debugged as the debugee. + +Building For Debugging +-- + +To build LLDB with debugging information add the following to your CMake +configuration: + +:: + + -DCMAKE_BUILD_TYPE=Debug \ + -DLLDB_EXPORT_ALL_SYMBOLS=1 + +Note that the ``lldb`` you will use to do the debugging does not itself need to +have debug information. + +Then build as you normally would. JDevlieghere wrote: Maybe add a backlink here to the building docs. https://github.com/llvm/llvm-project/pull/65332 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][Docs] Add page about debugging lldb itself (PR #65332)
@@ -0,0 +1,254 @@ +Debugging LLDB JDevlieghere wrote: Before the reshuffle of the pages, there were a handful of pages that had "LLDB" in their title, something like "Building LLDB" or "Testing LLDB", I don't remember. This page is somewhat different, because people might see it and click on it without realizing it's under the "Developing LLDB" section. On the one hand I hate the inconsistency but on the other hand I'm not sure what else to call this page. https://github.com/llvm/llvm-project/pull/65332 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][Docs] Add page about debugging lldb itself (PR #65332)
@@ -0,0 +1,254 @@ +Debugging LLDB +== + +This page details various ways to debug LLDB itself and other LLDB tools. If +you want to know how to use LLDB in general, please refer to +:doc:`/use/tutorial`. + +As LLDB is generally split into 2 tools, ``lldb`` and ``lldb-server`` +(``debugserver`` on Mac OS), the techniques shown here will not always apply to +both. With some knowledge of them all, you can mix and match as needed. + +In this document we refer to the initial ``lldb`` as the debugger and the +program being debugged as the debugee. + +Building For Debugging +-- + +To build LLDB with debugging information add the following to your CMake +configuration: + +:: + + -DCMAKE_BUILD_TYPE=Debug \ + -DLLDB_EXPORT_ALL_SYMBOLS=1 + +Note that the ``lldb`` you will use to do the debugging does not itself need to +have debug information. + +Then build as you normally would. + +Debugging ``lldb`` +-- + +The simplest scenario is where we want to debug a local execution of ``lldb`` +like this one: + +:: + + ./bin/lldb test_program + +LLDB is like any other program, so you can use the same approach. + +:: + + ./bin/lldb -- ./bin/lldb /tmp/test.o + +That's it. At least, that's the minimum. There's nothing special about LLDB +being a debugger that means you can't attach another debugger to it like any +other program. + +What can be an issue is that both debuggers have command line interfaces which +makes it very confusing which one is which: + +:: + + (the debugger) + (lldb) run + Process 1741640 launched: '<...>/bin/lldb' (aarch64) + Process 1741640 stopped and restarted: thread 1 received signal: SIGCHLD + + (the debugee) + (lldb) target create "/tmp/test.o" + Current executable set to '/tmp/test.o' (aarch64). + +Another issue is that when you resume the debugee, it will not print the +``(lldb)`` prompt because as far as it knows it hasn't changed state. A quick +way around that is to type something that is clearly not a command and hit +enter. + +:: + + (lldb) Process 1742266 stopped and restarted: thread 1 received signal: SIGCHLD + Process 1742266 stopped + * thread #1, name = 'lldb', stop reason = signal SIGSTOP + frame #0: 0xed5bfbf0 libc.so.6`__GI___libc_read at read.c:26:10 + (lldb) c + Process 1742266 resuming + notacommand + error: 'notacommand' is not a valid command. + (lldb) + +You could just remember whether you are in the debugger or the debugee but +it's thinking overhead, and for interrupt based events you simply may not be +able to know. + +Here are some better approaches. First, you could use another debugger like GDB +to debug LLDB. Perhaps an IDE like XCode or Visual Studio Code. Something which +runs LLDB under the hood so you don't have to type in commands to the debugger +yourself. + +Or you could change the prompt text for the debugger and/or debugee. + +:: + + $ ./bin/lldb -o "settings set prompt \"(lldb debugger) \"" -- \ +./bin/lldb -o "settings set prompt \"(lldb debuggee) \"" /tmp/test.o + <...> + (lldb) settings set prompt "(lldb debugger) " + (lldb debugger) run + <...> + (lldb) settings set prompt "(lldb debuggee) " + (lldb debuggee) + +If you want spacial separation you can run the debugee in one terminal then +attach to it in another. Remember that while paused in the debugger, the debugee +will not respond to input so you will have to ``continue`` in the debugger +first. + +:: + + (in terminal A) + $ ./bin/lldb /tmp/test.o + + (in terminal B) + $ ./bin/lldb ./bin/lldb --attach-pid $(pidof lldb) + +Placing Breakpoints +*** + +Generally you will want to hit some breakpoint in the debugee ``lldb``. To place +that breakpoint you must first stop the debugee. + +If you're debugging from another window this is done with ``process interrupt``. +The debugee will stop, you place the breakpoint and then ``continue``. Go back +to the debugee and input the command that should trigger the breakpoint. + +If you are running debugger and debugee in the same window, input ``ctrl+c`` +instead of ``process interrupt`` and then folllow the rest of the steps. + +If you are doing this with ``lldb-server`` and find your breakpoint is never +hit, check that you are breaking in code that is actually run by +``lldb-server``. There are cases where code only used by ``lldb`` ends up +linked into ``lldb-server``, so the debugger can break there but the breakpoint +will never be hit. + +Debugging ``lldb-server`` +- + +Note: If you are on MacOS you are likely using ``debugserver`` instead of +``lldb-server``. The spirit of these instructions applies but the specifics will +be different. + +We suggest you read :doc:`/use/remote` before attempting to debug ``lldb-server`` +as working out exactly what you want to debug requires that you understand its +various modes and behaviour. While you may not be literally debugging on a +remote target, think of your
[Lldb-commits] [lldb] [lldb][Docs] Add page about debugging lldb itself (PR #65332)
DavidSpickett wrote: For some reason I can't add the `pr-subscribers-lldb` team to this, but maybe I'm not supposed to be able to. https://github.com/llvm/llvm-project/pull/65332 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][Docs] Add page about debugging lldb itself (PR #65332)
https://github.com/github-actions[bot] labeled https://github.com/llvm/llvm-project/pull/65332 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][Docs] Add page about debugging lldb itself (PR #65332)
https://github.com/DavidSpickett created https://github.com/llvm/llvm-project/pull/65332: We have docs about how to use lldb on other programs, this tells you how to use lldb on ldlb and lldb-server. Lacking any Mac experience I've not included any debugserver information apart from stating it will be similar but not the same. I plan for this page to include sections on debugging tests and other things but this initial commit is purely about the two main binaries involved. >From 3952f4c66e5b9aa476142109e78a92a4ef4406c4 Mon Sep 17 00:00:00 2001 From: David Spickett Date: Tue, 5 Sep 2023 15:04:05 +0100 Subject: [PATCH] [lldb][Docs] Add page about debugging lldb itself We have docs about how to use lldb on other programs, this tells you how to use lldb on ldlb and lldb-server. Lacking any Mac experience I've not included any debugserver information apart from stating it will be similar but not the same. I plan for this page to include sections on debugging tests and other things but this initial commit is purely about the two main binaries involved. --- lldb/docs/index.rst| 1 + lldb/docs/resources/debugging-lldb.rst | 254 + 2 files changed, 255 insertions(+) create mode 100644 lldb/docs/resources/debugging-lldb.rst diff --git a/lldb/docs/index.rst b/lldb/docs/index.rst index e12a4569cfdd2ea..500800d4eaa1c08 100644 --- a/lldb/docs/index.rst +++ b/lldb/docs/index.rst @@ -148,6 +148,7 @@ interesting areas to contribute to lldb. resources/contributing resources/build resources/test + resources/debugging-lldb resources/fuzzing resources/sbapi resources/extensions diff --git a/lldb/docs/resources/debugging-lldb.rst b/lldb/docs/resources/debugging-lldb.rst new file mode 100644 index 000..7d49b1cdad7e4c1 --- /dev/null +++ b/lldb/docs/resources/debugging-lldb.rst @@ -0,0 +1,254 @@ +Debugging LLDB +== + +This page details various ways to debug LLDB itself and other LLDB tools. If +you want to know how to use LLDB in general, please refer to +:doc:`/use/tutorial`. + +As LLDB is generally split into 2 tools, ``lldb`` and ``lldb-server`` +(``debugserver`` on Mac OS), the techniques shown here will not always apply to +both. With some knowledge of them all, you can mix and match as needed. + +In this document we refer to the initial ``lldb`` as the debugger and the +program being debugged as the debugee. + +Building For Debugging +-- + +To build LLDB with debugging information add the following to your CMake +configuration: + +:: + + -DCMAKE_BUILD_TYPE=Debug \ + -DLLDB_EXPORT_ALL_SYMBOLS=1 + +Note that the ``lldb`` you will use to do the debugging does not itself need to +have debug information. + +Then build as you normally would. + +Debugging ``lldb`` +-- + +The simplest scenario is where we want to debug a local execution of ``lldb`` +like this one: + +:: + + ./bin/lldb test_program + +LLDB is like any other program, so you can use the same approach. + +:: + + ./bin/lldb -- ./bin/lldb /tmp/test.o + +That's it. At least, that's the minimum. There's nothing special about LLDB +being a debugger that means you can't attach another debugger to it like any +other program. + +What can be an issue is that both debuggers have command line interfaces which +makes it very confusing which one is which: + +:: + + (the debugger) + (lldb) run + Process 1741640 launched: '<...>/bin/lldb' (aarch64) + Process 1741640 stopped and restarted: thread 1 received signal: SIGCHLD + + (the debugee) + (lldb) target create "/tmp/test.o" + Current executable set to '/tmp/test.o' (aarch64). + +Another issue is that when you resume the debugee, it will not print the +``(lldb)`` prompt because as far as it knows it hasn't changed state. A quick +way around that is to type something that is clearly not a command and hit +enter. + +:: + + (lldb) Process 1742266 stopped and restarted: thread 1 received signal: SIGCHLD + Process 1742266 stopped + * thread #1, name = 'lldb', stop reason = signal SIGSTOP + frame #0: 0xed5bfbf0 libc.so.6`__GI___libc_read at read.c:26:10 + (lldb) c + Process 1742266 resuming + notacommand + error: 'notacommand' is not a valid command. + (lldb) + +You could just remember whether you are in the debugger or the debugee but +it's thinking overhead, and for interrupt based events you simply may not be +able to know. + +Here are some better approaches. First, you could use another debugger like GDB +to debug LLDB. Perhaps an IDE like XCode or Visual Studio Code. Something which +runs LLDB under the hood so you don't have to type in commands to the debugger +yourself. + +Or you could change the prompt text for the debugger and/or debugee. + +:: + + $ ./bin/lldb -o "settings set prompt \"(lldb debugger) \"" -- \ +./bin/lldb -o "settings set prompt \"(lldb debuggee) \"" /tmp/test.o + <...> + (lldb) settings set prompt "(lldb debugger) " + (lldb
[Lldb-commits] [lldb] [lldb][Docs] Add page about debugging lldb itself (PR #65332)
https://github.com/DavidSpickett review_requested https://github.com/llvm/llvm-project/pull/65332 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][Docs] Add page about debugging lldb itself (PR #65332)
https://github.com/DavidSpickett review_requested https://github.com/llvm/llvm-project/pull/65332 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][Docs] Add page about debugging lldb itself (PR #65332)
https://github.com/DavidSpickett review_requested https://github.com/llvm/llvm-project/pull/65332 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][Docs] Add simpler "automatic" cross-compile option to build docs (PR #65311)
https://github.com/github-actions[bot] labeled https://github.com/llvm/llvm-project/pull/65311 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][Docs] Add simpler "automatic" cross-compile option to build docs (PR #65311)
https://github.com/DavidSpickett updated https://github.com/llvm/llvm-project/pull/65311: >From e310a8a41688f1e3eff9a39e38b4c954b1316851 Mon Sep 17 00:00:00 2001 From: David Spickett Date: Tue, 5 Sep 2023 11:22:38 +0100 Subject: [PATCH] [lldb][Docs] Add simpler "automatic" cross-compile option to build docs The main way I cross build lldb is to point CMake at an existing host build to get the native tablegen tools. This is what we had documented before. There is another option where you start from scratch and the host tools are built for you. This patch documents that and explains which one to choose. Added another arm64 example which uses this. So the frst one is the "automatic" build and the second is the traditional approach. For ease of copy paste and understanding, I've kept the full command in each section and noted the one difference between them. Along the way I updated some of the preamble to explain the two approaches and updated some language e.g. removing "just ...". Eveyone's "just" is different, doubly so when cross-compiling. --- lldb/docs/resources/build.rst | 75 +++ 1 file changed, 58 insertions(+), 17 deletions(-) diff --git a/lldb/docs/resources/build.rst b/lldb/docs/resources/build.rst index 25ba3bfc4e84a46..b405a20e239912c 100644 --- a/lldb/docs/resources/build.rst +++ b/lldb/docs/resources/build.rst @@ -427,10 +427,10 @@ of CMake at this time. Please refer to `CMake's documentation
[Lldb-commits] [lldb] [lldb][Docs] Add simpler "automatic" cross-compile option to build docs (PR #65311)
DavidSpickett wrote: Also, Github is able to preview the rst which is very nice for review. https://github.com/llvm/llvm-project/pull/65311 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][Docs] Add simpler "automatic" cross-compile option to build docs (PR #65311)
DavidSpickett wrote: This isn't worth documenting but just for review background, you end up with these tools: ``` $ ls /work/open_source/test_lldb_cross/NATIVE/bin/ clang-tblgen lldb-tblgen llvm-config llvm-lit llvm-min-tblgen llvm-tblgen ``` Previous update to these docs was https://reviews.llvm.org/D158085. https://github.com/llvm/llvm-project/pull/65311 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][Docs] Add simpler "automatic" cross-compile option to build docs (PR #65311)
https://github.com/DavidSpickett review_requested https://github.com/llvm/llvm-project/pull/65311 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][Docs] Add simpler "automatic" cross-compile option to build docs (PR #65311)
https://github.com/DavidSpickett review_requested https://github.com/llvm/llvm-project/pull/65311 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][Docs] Add simpler "automatic" cross-compile option to build docs (PR #65311)
https://github.com/DavidSpickett created https://github.com/llvm/llvm-project/pull/65311: The main way I cross build lldb is to point CMake at an existing host build to get the native tablegen tools. This is what we had documented before. There is another option where you start from scratch and the host tools are built for you. This patch documents that and explains which one to choose. Added another arm64 example which uses this. So the frst one is the "automatic" build and the second is the traditional approach. For ease of copy paste and understanding, I've kept the full command in each section and noted the one difference between them. Along the way I updated some of the preamble to explain the two approaches and updated some language e.g. removing "just ...". Eveyone's "just" is different, doubly so when cross-compiling. >From 761b9adb5bcc3d425342eb75099d6be9692f28c4 Mon Sep 17 00:00:00 2001 From: David Spickett Date: Tue, 5 Sep 2023 11:22:38 +0100 Subject: [PATCH] [lldb][Docs] Add simpler "automatic" cross-compile option to build docs The main way I cross build lldb is to point CMake at an existing host build to get the native tablegen tools. This is what we had documented before. There is another option where you start from scratch and the host tools are built for you. This patch documents that and explains which one to choose. Added another arm64 example which uses this. So the frst one is the "automatic" build and the second is the traditional approach. For ease of copy paste and understanding, I've kept the full command in each section and noted the one difference between them. Along the way I updated some of the preamble to explain the two approaches and updated some language e.g. removing "just ...". Eveyone's "just" is different, doubly so when cross-compiling. --- lldb/docs/resources/build.rst | 75 +++ 1 file changed, 58 insertions(+), 17 deletions(-) diff --git a/lldb/docs/resources/build.rst b/lldb/docs/resources/build.rst index 25ba3bfc4e84a4..b405a20e239912 100644 --- a/lldb/docs/resources/build.rst +++ b/lldb/docs/resources/build.rst @@ -427,10 +427,10 @@ of CMake at this time. Please refer to `CMake's documentation
[Lldb-commits] [PATCH] D157845: [lldb][AArch64] Remove bool return from UpdateARM64SVERegistersInfos
This revision was automatically updated to reflect the committed changes.
Closed by commit rGf6b6234d14d2: [lldb][AArch64] Remove bool return from
UpdateARM64SVERegistersInfos (authored by DavidSpickett).
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D157845/new/
https://reviews.llvm.org/D157845
Files:
lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.h
Index: lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.h
===
--- lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.h
+++ lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.h
@@ -38,7 +38,7 @@
~GDBRemoteDynamicRegisterInfo() override = default;
- bool UpdateARM64SVERegistersInfos(uint64_t vg);
+ void UpdateARM64SVERegistersInfos(uint64_t vg);
};
class GDBRemoteRegisterContext : public RegisterContext {
Index: lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
===
--- lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
+++ lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
@@ -772,27 +772,28 @@
uint32_t vg_reg_num = reg_info->kinds[eRegisterKindLLDB];
uint64_t vg_reg_value = ReadRegisterAsUnsigned(vg_reg_num, fail_value);
- if (vg_reg_value != fail_value && vg_reg_value <= 32) {
-const RegisterInfo *reg_info = m_reg_info_sp->GetRegisterInfo("p0");
-if (!reg_info || vg_reg_value == reg_info->byte_size)
- return false;
+ if (vg_reg_value == fail_value || vg_reg_value > 32)
+return false;
-if (m_reg_info_sp->UpdateARM64SVERegistersInfos(vg_reg_value)) {
- // Make a heap based buffer that is big enough to store all registers
- m_reg_data.SetData(std::make_shared(
- m_reg_info_sp->GetRegisterDataByteSize(), 0));
- m_reg_data.SetByteOrder(GetByteOrder());
+ reg_info = m_reg_info_sp->GetRegisterInfo("p0");
+ // Predicate registers have 1 bit per byte in the vector so their size is
+ // VL / 8. VG is in units of 8 bytes already, so if the size of p0 == VG
+ // already, we do not have to reconfigure.
+ if (!reg_info || vg_reg_value == reg_info->byte_size)
+return false;
- InvalidateAllRegisters();
+ m_reg_info_sp->UpdateARM64SVERegistersInfos(vg_reg_value);
+ // Make a heap based buffer that is big enough to store all registers
+ m_reg_data.SetData(std::make_shared(
+ m_reg_info_sp->GetRegisterDataByteSize(), 0));
+ m_reg_data.SetByteOrder(GetByteOrder());
- return true;
-}
- }
+ InvalidateAllRegisters();
- return false;
+ return true;
}
-bool GDBRemoteDynamicRegisterInfo::UpdateARM64SVERegistersInfos(uint64_t vg) {
+void GDBRemoteDynamicRegisterInfo::UpdateARM64SVERegistersInfos(uint64_t vg) {
// SVE Z register size is vg x 8 bytes.
uint32_t z_reg_byte_size = vg * 8;
@@ -813,5 +814,4 @@
// Re-calculate register offsets
ConfigureOffsets();
- return true;
}
Index: lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.h
===
--- lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.h
+++ lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.h
@@ -38,7 +38,7 @@
~GDBRemoteDynamicRegisterInfo() override = default;
- bool UpdateARM64SVERegistersInfos(uint64_t vg);
+ void UpdateARM64SVERegistersInfos(uint64_t vg);
};
class GDBRemoteRegisterContext : public RegisterContext {
Index: lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
===
--- lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
+++ lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
@@ -772,27 +772,28 @@
uint32_t vg_reg_num = reg_info->kinds[eRegisterKindLLDB];
uint64_t vg_reg_value = ReadRegisterAsUnsigned(vg_reg_num, fail_value);
- if (vg_reg_value != fail_value && vg_reg_value <= 32) {
-const RegisterInfo *reg_info = m_reg_info_sp->GetRegisterInfo("p0");
-if (!reg_info || vg_reg_value == reg_info->byte_size)
- return false;
+ if (vg_reg_value == fail_value || vg_reg_value > 32)
+return false;
-if (m_reg_info_sp->UpdateARM64SVERegistersInfos(vg_reg_value)) {
- // Make a heap based buffer that is big enough to store all registers
- m_reg_data.SetData(std::make_shared(
- m_reg_info_sp->GetRegisterDataByteSize(), 0));
- m_reg_data.SetByteOrder(GetByteOrder());
+ reg_info = m_reg_info_sp->GetRegisterInfo("p0");
+ // Predicate registers have 1 bit per byte in the vector so their size is
+ // VL / 8. VG is in units of 8 bytes already, so if the size of p0 == VG
+ // already, we do not have to reconfigure.
+ if (!reg_info || vg_reg_value ==
[Lldb-commits] [lldb] f6b6234 - [lldb][AArch64] Remove bool return from UpdateARM64SVERegistersInfos
Author: David Spickett
Date: 2023-09-05T10:03:50+01:00
New Revision: f6b6234d14d2fa379a1f2d6b54259cac89a7fc73
URL:
https://github.com/llvm/llvm-project/commit/f6b6234d14d2fa379a1f2d6b54259cac89a7fc73
DIFF:
https://github.com/llvm/llvm-project/commit/f6b6234d14d2fa379a1f2d6b54259cac89a7fc73.diff
LOG: [lldb][AArch64] Remove bool return from UpdateARM64SVERegistersInfos
This always succeeds. While I'm here, document why we check the size
of p0 against the value of VG.
Reviewed By: omjavaid
Differential Revision: https://reviews.llvm.org/D157845
Added:
Modified:
lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.h
Removed:
diff --git
a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
index e8606ddae5674a7..bd9211bbaad5293 100644
--- a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
+++ b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
@@ -772,27 +772,28 @@ bool GDBRemoteRegisterContext::AArch64SVEReconfigure() {
uint32_t vg_reg_num = reg_info->kinds[eRegisterKindLLDB];
uint64_t vg_reg_value = ReadRegisterAsUnsigned(vg_reg_num, fail_value);
- if (vg_reg_value != fail_value && vg_reg_value <= 32) {
-const RegisterInfo *reg_info = m_reg_info_sp->GetRegisterInfo("p0");
-if (!reg_info || vg_reg_value == reg_info->byte_size)
- return false;
+ if (vg_reg_value == fail_value || vg_reg_value > 32)
+return false;
-if (m_reg_info_sp->UpdateARM64SVERegistersInfos(vg_reg_value)) {
- // Make a heap based buffer that is big enough to store all registers
- m_reg_data.SetData(std::make_shared(
- m_reg_info_sp->GetRegisterDataByteSize(), 0));
- m_reg_data.SetByteOrder(GetByteOrder());
+ reg_info = m_reg_info_sp->GetRegisterInfo("p0");
+ // Predicate registers have 1 bit per byte in the vector so their size is
+ // VL / 8. VG is in units of 8 bytes already, so if the size of p0 == VG
+ // already, we do not have to reconfigure.
+ if (!reg_info || vg_reg_value == reg_info->byte_size)
+return false;
- InvalidateAllRegisters();
+ m_reg_info_sp->UpdateARM64SVERegistersInfos(vg_reg_value);
+ // Make a heap based buffer that is big enough to store all registers
+ m_reg_data.SetData(std::make_shared(
+ m_reg_info_sp->GetRegisterDataByteSize(), 0));
+ m_reg_data.SetByteOrder(GetByteOrder());
- return true;
-}
- }
+ InvalidateAllRegisters();
- return false;
+ return true;
}
-bool GDBRemoteDynamicRegisterInfo::UpdateARM64SVERegistersInfos(uint64_t vg) {
+void GDBRemoteDynamicRegisterInfo::UpdateARM64SVERegistersInfos(uint64_t vg) {
// SVE Z register size is vg x 8 bytes.
uint32_t z_reg_byte_size = vg * 8;
@@ -813,5 +814,4 @@ bool
GDBRemoteDynamicRegisterInfo::UpdateARM64SVERegistersInfos(uint64_t vg) {
// Re-calculate register offsets
ConfigureOffsets();
- return true;
}
diff --git a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.h
b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.h
index d185cb5aede1e50..a4fa18327047c08 100644
--- a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.h
+++ b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.h
@@ -38,7 +38,7 @@ class GDBRemoteDynamicRegisterInfo final : public
DynamicRegisterInfo {
~GDBRemoteDynamicRegisterInfo() override = default;
- bool UpdateARM64SVERegistersInfos(uint64_t vg);
+ void UpdateARM64SVERegistersInfos(uint64_t vg);
};
class GDBRemoteRegisterContext : public RegisterContext {
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D157609: [lldb] Add more ways to find split DWARF files
DavidSpickett added inline comments. Comment at: lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp:1808-1810 +FileSpec dwo_name_next_to_binary(next_to_binary); +dwo_name_next_to_binary.AppendPathComponent(dwo_name); +dwo_paths.Append(dwo_name_next_to_binary); clayborg wrote: > Should we only do this if "dwo_name" is relative? Also if "comp_dir" is > relative, do we want to add another path to search here? > Should we only do this if "dwo_name" is relative? Done. > Also if "comp_dir" is relative, do we want to add another path to search here? binary dir + relative comp dir is covered in the first set of checks around: ``` // if DW_AT_comp_dir is relative, it should be relative to the location... ``` Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D157609/new/ https://reviews.llvm.org/D157609 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D157609: [lldb] Add more ways to find split DWARF files
DavidSpickett updated this revision to Diff 555827.
DavidSpickett added a comment.
In the fallback, only check binary dir + dwo name if the dwo name is relative.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D157609/new/
https://reviews.llvm.org/D157609
Files:
lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
lldb/test/Shell/SymbolFile/DWARF/dwo-debug-file-search-paths-dwoname-absolute-compdir.c
lldb/test/Shell/SymbolFile/DWARF/dwo-debug-file-search-paths-filename-only-absolute-compdir.c
lldb/test/Shell/SymbolFile/DWARF/dwo-debug-file-search-paths-filename-only-relative-compdir.c
lldb/test/Shell/SymbolFile/DWARF/dwo-debug-file-search-paths-relative-compdir.c
lldb/test/Shell/SymbolFile/DWARF/dwo-relative-filename-only-binary-dir.c
Index: lldb/test/Shell/SymbolFile/DWARF/dwo-relative-filename-only-binary-dir.c
===
--- /dev/null
+++ lldb/test/Shell/SymbolFile/DWARF/dwo-relative-filename-only-binary-dir.c
@@ -0,0 +1,21 @@
+/// Check that LLDB can find a relative DWO file next to a binary just using the
+/// filename of that DWO. For example "main.dwo" not "a/b/main.dwo".
+// RUN: rm -rf %t.compdir/
+// RUN: mkdir -p %t.compdir/a/b/
+// RUN: cp %s %t.compdir/a/b/main.c
+// RUN: cd %t.compdir/a/
+/// The produced DWO is named b/main-main.dwo, with a DW_AT_comp_dir of a/.
+// RUN: %clang_host -g -gsplit-dwarf -fdebug-prefix-map=%t.compdir=. b/main.c -o b/main
+// RUN: cd ../..
+/// Move binary and DWO out of expected locations.
+// RUN: mv %t.compdir/a/b/main %t.compdir/
+// RUN: mv %t.compdir/a/b/*.dwo %t.compdir/
+// RUN: %lldb --no-lldbinit %t.compdir/main \
+// RUN: -o "b main" -o "run" -o "p num" --batch 2>&1 | FileCheck %s
+
+// CHECK-NOT: warning: {{.*}}main unable to locate separate debug file (dwo, dwp). Debugging will be degraded.
+// CHECK: (int) 5
+
+int num = 5;
+
+int main(void) { return 0; }
\ No newline at end of file
Index: lldb/test/Shell/SymbolFile/DWARF/dwo-debug-file-search-paths-relative-compdir.c
===
--- /dev/null
+++ lldb/test/Shell/SymbolFile/DWARF/dwo-debug-file-search-paths-relative-compdir.c
@@ -0,0 +1,28 @@
+/// Check that LLDB uses the paths in target.debug-file-search-paths to find
+/// split DWARF files with a relative DW_AT_comp_dir set, when the program file
+/// has been moved and/or we're executing it from another directory.
+// RUN: rm -rf %t.compdir/ %t.e/
+// RUN: mkdir -p %t.compdir/a/b/c/d/
+// RUN: cp %s %t.compdir/a/b/c/d/main.c
+// RUN: cd %t.compdir/a/b/
+/// The produced DWO is named c/d/main-main.dwo, with a DW_AT_comp_dir of a/b.
+// RUN: %clang_host -g -gsplit-dwarf -fdebug-prefix-map=%t.compdir=. c/d/main.c -o c/d/main
+// RUN: cd ../../..
+/// Move only the program, leaving the DWO file in place.
+// RUN: mv %t.compdir/a/b/c/d/main %t.compdir/a/
+/// Debug it from yet another path.
+// RUN: mkdir -p %t.e/
+// RUN: cd %t.e
+/// LLDB won't find the DWO next to the binary or in the current dir, so it
+/// should find the DWO file by doing %t.compdir/ + a/b/ + c/d/main-main.dwo.
+// RUN: %lldb --no-lldbinit %t.compdir/a/main \
+// RUN: -O "settings append target.debug-file-search-paths %t.compdir" \
+// RUN: -o "b main.c:27" -o "run" -o "frame variable" --batch 2>&1 | FileCheck %s
+
+// CHECK-NOT: warning: {{.*}}main unable to locate separate debug file (dwo, dwp). Debugging will be degraded.
+// CHECK: (int) num = 5
+
+int main(void) {
+ int num = 5;
+ return 0;
+}
\ No newline at end of file
Index: lldb/test/Shell/SymbolFile/DWARF/dwo-debug-file-search-paths-filename-only-relative-compdir.c
===
--- /dev/null
+++ lldb/test/Shell/SymbolFile/DWARF/dwo-debug-file-search-paths-filename-only-relative-compdir.c
@@ -0,0 +1,26 @@
+/// Check that when LLDB is looking for a relative DWO it uses the debug search
+/// paths setting. If it doesn't find it by adding the whole relative path to
+/// of DWO it should try adding just the filename (e.g. main.dwo) to each debug
+/// search path.
+// RUN: rm -rf %t.compdir/
+// RUN: mkdir -p %t.compdir/a/b/
+// RUN: cp %s %t.compdir/a/b/main.c
+// RUN: cd %t.compdir/a/
+/// The produced DWO is named /b/main-main.dwo, with a DW_AT_comp_dir of a/.
+// RUN: %clang_host -g -gsplit-dwarf -fdebug-prefix-map=%t.compdir=. b/main.c -o b/main
+// RUN: cd ../..
+/// Move the DWO file away from the expected location.
+// RUN: mv %t.compdir/a/b/*.dwo %t.compdir/
+/// LLDB won't find the DWO next to the binary or by adding the relative path
+/// to any of the search paths. So it should find the DWO file at
+/// %t.compdir/main-main.dwo.
+// RUN: %lldb --no-lldbinit %t.compdir/a/b/main \
+// RUN: -O "settings append target.debug-file-search-paths %t.compdir" \
+// RUN: -o "b main" -o "run" -o "p num" --batch 2>&1 | FileCheck %s
+
+// CHECK-NOT: warning: {{.*}}main unable to
[Lldb-commits] [PATCH] D157609: [lldb] Add more ways to find split DWARF files
DavidSpickett updated this revision to Diff 555822.
DavidSpickett added a comment.
Rename as suggested.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D157609/new/
https://reviews.llvm.org/D157609
Files:
lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
lldb/test/Shell/SymbolFile/DWARF/dwo-debug-file-search-paths-dwoname-absolute-compdir.c
lldb/test/Shell/SymbolFile/DWARF/dwo-debug-file-search-paths-filename-only-absolute-compdir.c
lldb/test/Shell/SymbolFile/DWARF/dwo-debug-file-search-paths-filename-only-relative-compdir.c
lldb/test/Shell/SymbolFile/DWARF/dwo-debug-file-search-paths-relative-compdir.c
lldb/test/Shell/SymbolFile/DWARF/dwo-relative-filename-only-binary-dir.c
Index: lldb/test/Shell/SymbolFile/DWARF/dwo-relative-filename-only-binary-dir.c
===
--- /dev/null
+++ lldb/test/Shell/SymbolFile/DWARF/dwo-relative-filename-only-binary-dir.c
@@ -0,0 +1,21 @@
+/// Check that LLDB can find a relative DWO file next to a binary just using the
+/// filename of that DWO. For example "main.dwo" not "a/b/main.dwo".
+// RUN: rm -rf %t.compdir/
+// RUN: mkdir -p %t.compdir/a/b/
+// RUN: cp %s %t.compdir/a/b/main.c
+// RUN: cd %t.compdir/a/
+/// The produced DWO is named b/main-main.dwo, with a DW_AT_comp_dir of a/.
+// RUN: %clang_host -g -gsplit-dwarf -fdebug-prefix-map=%t.compdir=. b/main.c -o b/main
+// RUN: cd ../..
+/// Move binary and DWO out of expected locations.
+// RUN: mv %t.compdir/a/b/main %t.compdir/
+// RUN: mv %t.compdir/a/b/*.dwo %t.compdir/
+// RUN: %lldb --no-lldbinit %t.compdir/main \
+// RUN: -o "b main" -o "run" -o "p num" --batch 2>&1 | FileCheck %s
+
+// CHECK-NOT: warning: {{.*}}main unable to locate separate debug file (dwo, dwp). Debugging will be degraded.
+// CHECK: (int) 5
+
+int num = 5;
+
+int main(void) { return 0; }
\ No newline at end of file
Index: lldb/test/Shell/SymbolFile/DWARF/dwo-debug-file-search-paths-relative-compdir.c
===
--- /dev/null
+++ lldb/test/Shell/SymbolFile/DWARF/dwo-debug-file-search-paths-relative-compdir.c
@@ -0,0 +1,28 @@
+/// Check that LLDB uses the paths in target.debug-file-search-paths to find
+/// split DWARF files with a relative DW_AT_comp_dir set, when the program file
+/// has been moved and/or we're executing it from another directory.
+// RUN: rm -rf %t.compdir/ %t.e/
+// RUN: mkdir -p %t.compdir/a/b/c/d/
+// RUN: cp %s %t.compdir/a/b/c/d/main.c
+// RUN: cd %t.compdir/a/b/
+/// The produced DWO is named c/d/main-main.dwo, with a DW_AT_comp_dir of a/b.
+// RUN: %clang_host -g -gsplit-dwarf -fdebug-prefix-map=%t.compdir=. c/d/main.c -o c/d/main
+// RUN: cd ../../..
+/// Move only the program, leaving the DWO file in place.
+// RUN: mv %t.compdir/a/b/c/d/main %t.compdir/a/
+/// Debug it from yet another path.
+// RUN: mkdir -p %t.e/
+// RUN: cd %t.e
+/// LLDB won't find the DWO next to the binary or in the current dir, so it
+/// should find the DWO file by doing %t.compdir/ + a/b/ + c/d/main-main.dwo.
+// RUN: %lldb --no-lldbinit %t.compdir/a/main \
+// RUN: -O "settings append target.debug-file-search-paths %t.compdir" \
+// RUN: -o "b main.c:27" -o "run" -o "frame variable" --batch 2>&1 | FileCheck %s
+
+// CHECK-NOT: warning: {{.*}}main unable to locate separate debug file (dwo, dwp). Debugging will be degraded.
+// CHECK: (int) num = 5
+
+int main(void) {
+ int num = 5;
+ return 0;
+}
\ No newline at end of file
Index: lldb/test/Shell/SymbolFile/DWARF/dwo-debug-file-search-paths-filename-only-relative-compdir.c
===
--- /dev/null
+++ lldb/test/Shell/SymbolFile/DWARF/dwo-debug-file-search-paths-filename-only-relative-compdir.c
@@ -0,0 +1,26 @@
+/// Check that when LLDB is looking for a relative DWO it uses the debug search
+/// paths setting. If it doesn't find it by adding the whole relative path to
+/// of DWO it should try adding just the filename (e.g. main.dwo) to each debug
+/// search path.
+// RUN: rm -rf %t.compdir/
+// RUN: mkdir -p %t.compdir/a/b/
+// RUN: cp %s %t.compdir/a/b/main.c
+// RUN: cd %t.compdir/a/
+/// The produced DWO is named /b/main-main.dwo, with a DW_AT_comp_dir of a/.
+// RUN: %clang_host -g -gsplit-dwarf -fdebug-prefix-map=%t.compdir=. b/main.c -o b/main
+// RUN: cd ../..
+/// Move the DWO file away from the expected location.
+// RUN: mv %t.compdir/a/b/*.dwo %t.compdir/
+/// LLDB won't find the DWO next to the binary or by adding the relative path
+/// to any of the search paths. So it should find the DWO file at
+/// %t.compdir/main-main.dwo.
+// RUN: %lldb --no-lldbinit %t.compdir/a/b/main \
+// RUN: -O "settings append target.debug-file-search-paths %t.compdir" \
+// RUN: -o "b main" -o "run" -o "p num" --batch 2>&1 | FileCheck %s
+
+// CHECK-NOT: warning: {{.*}}main unable to locate separate debug file (dwo, dwp). Debugging will be
