[Lldb-commits] [lldb] LLDB Debuginfod tests and a fix or two (PR #90622)
kevinfrei wrote: Thanks for the diagnostics & fix. I really appreciate it. I'm on vacation this week, so I'll get this ready & relanded next Monday. 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)
DavidSpickett wrote: I've fixed the underlying issue on Arm, you do not need to make any changes to this code to fix it. It should "just work" now. I see some unresolved comments about other test failures, and if I reland this I'll get all the buildbot emails and have no clue what to do to fix them. So instead I think it's best if you go over those, make any changes you need to and post a new PR to reland this. 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)
@@ -87,8 +105,15 @@ SymbolVendorELF::CreateInstance(const lldb::ModuleSP
_sp,
FileSpecList search_paths = Target::GetDefaultDebugFileSearchPaths();
FileSpec dsym_fspec =
PluginManager::LocateExecutableSymbolFile(module_spec, search_paths);
- if (!dsym_fspec)
-return nullptr;
+ if (!dsym_fspec || IsDwpSymbolFile(module_sp, dsym_fspec)) {
+// If we have a stripped binary or if we got a DWP file, we should prefer
+// symbols in the executable acquired through a plugin.
+ModuleSpec unstripped_spec =
+PluginManager::LocateExecutableObjectFile(module_spec);
+if (!unstripped_spec)
+ return nullptr;
+dsym_fspec = unstripped_spec.GetFileSpec();
+ }
DavidSpickett wrote:
That PR is in, so at least Arm Linux is happy for this to go back in.
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)
@@ -87,8 +105,15 @@ SymbolVendorELF::CreateInstance(const lldb::ModuleSP
_sp,
FileSpecList search_paths = Target::GetDefaultDebugFileSearchPaths();
FileSpec dsym_fspec =
PluginManager::LocateExecutableSymbolFile(module_spec, search_paths);
- if (!dsym_fspec)
-return nullptr;
+ if (!dsym_fspec || IsDwpSymbolFile(module_sp, dsym_fspec)) {
+// If we have a stripped binary or if we got a DWP file, we should prefer
+// symbols in the executable acquired through a plugin.
+ModuleSpec unstripped_spec =
+PluginManager::LocateExecutableObjectFile(module_spec);
+if (!unstripped_spec)
+ return nullptr;
+dsym_fspec = unstripped_spec.GetFileSpec();
+ }
DavidSpickett wrote:
https://github.com/llvm/llvm-project/pull/91585 fixes the underlying issue,
if/when that's proven to work, I'll put this PR back in.
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)
@@ -87,8 +105,15 @@ SymbolVendorELF::CreateInstance(const lldb::ModuleSP
_sp,
FileSpecList search_paths = Target::GetDefaultDebugFileSearchPaths();
FileSpec dsym_fspec =
PluginManager::LocateExecutableSymbolFile(module_spec, search_paths);
- if (!dsym_fspec)
-return nullptr;
+ if (!dsym_fspec || IsDwpSymbolFile(module_sp, dsym_fspec)) {
+// If we have a stripped binary or if we got a DWP file, we should prefer
+// symbols in the executable acquired through a plugin.
+ModuleSpec unstripped_spec =
+PluginManager::LocateExecutableObjectFile(module_spec);
+if (!unstripped_spec)
+ return nullptr;
+dsym_fspec = unstripped_spec.GetFileSpec();
+ }
DavidSpickett wrote:
This is what I've figured out so far. It's like the previous issue I mentioned,
except it's related to the program file, not `ld.so`.
If we look at the memory regions before this PR we see:
```
[0xf7fe2000-0xf7fe9000) ---
[0xf7fe9000-0xf7fea000) rw-
[0xf7fea000-0xf7feb000) r-- objc_imageinfo
[0xf7feb000-0xf7fec000) r-x .text
```
After we just have:
```
[0xf7fe2000-0xf7fec000) ---
```
Which means we have lost, or never loaded, the section information for this
program file. Which makes sense given that it's compiled without debug
information. We'll ask a plugin for the debug info and none of those will have
it, so we exit early.
Problem is, Arm has 2 execution modes. Arm and Thumb. To know how to break
properly in different code we look at markers on the sections. These set the
`AddressClass` of the address value in LLDB to the right value.
In this case, we need to call `mmap`. This is in a Thumb section in `ld.so`,
and we have it's section information. We don't need to break here though, only
set the control register (cpsr) bit to indicate we want to run in Thumb mode,
then write the PC to point to this location.
For the end of `mmap`, we need to return somewhere. So lldb says, why not
`_start`, it's something we can count on existing on Linux. So LLDB needs to
set the link register to that address, then place a breakpoint on the address
to catch the program just as `mmap` finishes.
Problem is, after this PR we don't have section information to tell us that
this area is Thumb. This means that `Platform::GetSoftwareBreakpointTrapOpcode`
chooses an Arm breakpoint code. Now I don't know exactly what goes wrong there,
I think in Thumb mode the program sees this encoding as some kind of backwards
branch, and it ends up basically in the zero page and segfaults from there.
This is why the call to `mmap` fails and we fall back to the interpreter.
So ideally we want to split the two concepts of 1. Section information and 2.
Symbol file. So that we can load both without resetting the other. I'm going to
look into that next.
And for some context, I think Arm is the only platform this section information
is crucial. Potentially MIPS but also we dropped Linux MIPS support, and I
don't know if those platforms mixed modes ever. So it's not surprising you
didn't see this testing on more modern platforms.
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)
@@ -87,8 +105,15 @@ SymbolVendorELF::CreateInstance(const lldb::ModuleSP
_sp,
FileSpecList search_paths = Target::GetDefaultDebugFileSearchPaths();
FileSpec dsym_fspec =
PluginManager::LocateExecutableSymbolFile(module_spec, search_paths);
- if (!dsym_fspec)
-return nullptr;
+ if (!dsym_fspec || IsDwpSymbolFile(module_sp, dsym_fspec)) {
+// If we have a stripped binary or if we got a DWP file, we should prefer
+// symbols in the executable acquired through a plugin.
+ModuleSpec unstripped_spec =
+PluginManager::LocateExecutableObjectFile(module_spec);
+if (!unstripped_spec)
+ return nullptr;
+dsym_fspec = unstripped_spec.GetFileSpec();
+ }
kevinfrei wrote:
@DavidSpickett if there's anything I can do to help, please ping me. Feel free
to use my github handle at hotmail to ping me, as I'm going to be on a "doing
nothing in nicer weather" vacation next week.
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)
@@ -87,8 +105,15 @@ SymbolVendorELF::CreateInstance(const lldb::ModuleSP
_sp,
FileSpecList search_paths = Target::GetDefaultDebugFileSearchPaths();
FileSpec dsym_fspec =
PluginManager::LocateExecutableSymbolFile(module_spec, search_paths);
- if (!dsym_fspec)
-return nullptr;
+ if (!dsym_fspec || IsDwpSymbolFile(module_sp, dsym_fspec)) {
+// If we have a stripped binary or if we got a DWP file, we should prefer
+// symbols in the executable acquired through a plugin.
+ModuleSpec unstripped_spec =
+PluginManager::LocateExecutableObjectFile(module_spec);
+if (!unstripped_spec)
+ return nullptr;
+dsym_fspec = unstripped_spec.GetFileSpec();
+ }
DavidSpickett wrote:
We try to allocate memory to JIT the expression and calling `mmap` fails with a
signal. In https://github.com/llvm/llvm-project/issues/68987 this was because
we had lost the section info that told us whether to call it as Thumb or Arm,
if we get that wrong it causes a SIGILL, so it could be the same thing again.
I will look into it more next week and assuming I find a fix, reland the
changes for you.
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/DavidSpickett 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)
@@ -87,8 +105,15 @@ SymbolVendorELF::CreateInstance(const lldb::ModuleSP
_sp,
FileSpecList search_paths = Target::GetDefaultDebugFileSearchPaths();
FileSpec dsym_fspec =
PluginManager::LocateExecutableSymbolFile(module_spec, search_paths);
- if (!dsym_fspec)
-return nullptr;
+ if (!dsym_fspec || IsDwpSymbolFile(module_sp, dsym_fspec)) {
+// If we have a stripped binary or if we got a DWP file, we should prefer
+// symbols in the executable acquired through a plugin.
+ModuleSpec unstripped_spec =
+PluginManager::LocateExecutableObjectFile(module_spec);
+if (!unstripped_spec)
+ return nullptr;
+dsym_fspec = unstripped_spec.GetFileSpec();
+ }
DavidSpickett wrote:
Something about this if block has broken `Expr/TestStringLiteralExpr.test` on
Arm 32 bit, a platform that has been sensitive to changes in this area in the
past. The test is built without debug info and something happens when the test
file comes through here. For ld.so and the libc it's all the same as before.
```
(lldb) expr "hello there"
lldb ProcessGDBRemote::DoAllocateMemory no direct stub support for
memory allocation, and InferiorCallMmap also failed - is stub missing register
context save/restore capability?
```
Last time this happened it was because we lost the symbols that let us call
`mmap`, but those are in ld.so usually so I'm not sure what's the problem this
time.
This means we fall back the interpreter, which we didn't need to do before.
```
error: Can't evaluate the expression without a running target due to:
Interpreter doesn't handle one of the expression's operands
```
I've reverted this
(https://github.com/llvm/llvm-project/commit/327bfc971e4dce3f6798843c92406cda95c07ba1)
and the follow up while I investigate locally.
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/labath 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)
@@ -0,0 +1,183 @@
+import os
+import shutil
+import tempfile
+
+import lldb
+from lldbsuite.test.decorators import *
+import lldbsuite.test.lldbutil as lldbutil
+from lldbsuite.test.lldbtest import *
+
+
+"""
+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
+"""
+
+
+class DebugInfodTests(TestBase):
+# No need to try every flavor of debug inf.
+NO_DEBUG_INFO_TESTCASE = True
+
+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)
+"""
+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.unstripped")
+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.unstripped")
+self.try_breakpoint(True)
+
+def test_debuginfod_okd_symbols(self):
+"""
+Test behavior with the 'only-keep-debug' symbols available from
Debuginfod.
+"""
+test_root = self.config_test(["a.out"], "a.out.debug")
+self.try_breakpoint(True)
+
+def try_breakpoint(self, should_have_loc):
+"""
+This function creates a target from self.aout, sets a function-name
+breakpoint, and checks to see if we have a file/line location,
+as a way to validate that the symbols have been loaded.
+should_have_loc specifies if we're testing that symbols have or
+haven't been loaded.
+"""
+target = self.dbg.CreateTarget(self.aout)
+self.assertTrue(target and target.IsValid(), "Target is valid")
+
+bp = target.BreakpointCreateByName("func")
+self.assertTrue(bp and bp.IsValid(), "Breakpoint is valid")
+self.assertEqual(bp.GetNumLocations(), 1)
+
+loc = bp.GetLocationAtIndex(0)
+self.assertTrue(loc and loc.IsValid(), "Location is valid")
+addr = loc.GetAddress()
+self.assertTrue(addr and addr.IsValid(), "Loc address is valid")
+line_entry = addr.GetLineEntry()
+self.assertEqual(
+should_have_loc,
+line_entry != None and line_entry.IsValid(),
+"Loc line entry is valid",
+)
+if should_have_loc:
+self.assertEqual(line_entry.GetLine(), 4)
+self.assertEqual(
+line_entry.GetFileSpec().GetFilename(),
+self.main_source_file.GetFilename(),
+)
+self.dbg.DeleteTarget(target)
+shutil.rmtree(self.tmp_dir)
+
+def config_test(self, local_files, debuginfo=None, executable=None):
+"""
+Set up a test with local_files[] copied to a different location
+so that we control which files are, or are not, found in the file
system.
+Also, create a stand-alone file-system 'hosted' debuginfod server with
the
+provided debuginfo and executable files (if they exist)
+
+Make the filesystem look like:
+
+/tmp//test/[local_files]
+
+/tmp//cache (for lldb to use as a temp cache)
+
+/tmp//buildid//executable ->
+/tmp//buildid//debuginfo ->
+Returns the /tmp/ path
+"""
+
+self.build()
+
+uuid = self.getUUID("a.out")
+if not uuid:
+self.fail("Could not get UUID for a.out")
+return
+self.main_source_file = lldb.SBFileSpec("main.c")
+self.tmp_dir = tempfile.mkdtemp()
+test_dir = os.path.join(self.tmp_dir, "test")
+os.makedirs(test_dir)
+
+self.aout = ""
+# Copy the files used by the test:
+for f in local_files:
+shutil.copy(self.getBuildArtifact(f), test_dir)
+# The first item is the binary to be used for the test
+if self.aout == "":
[Lldb-commits] [lldb] LLDB Debuginfod tests and a fix or two (PR #90622)
@@ -0,0 +1,183 @@
+import os
+import shutil
+import tempfile
+
+import lldb
+from lldbsuite.test.decorators import *
+import lldbsuite.test.lldbutil as lldbutil
+from lldbsuite.test.lldbtest import *
+
+
+"""
+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
+"""
+
+
+class DebugInfodTests(TestBase):
+# No need to try every flavor of debug inf.
+NO_DEBUG_INFO_TESTCASE = True
+
+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)
+"""
+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.unstripped")
+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.unstripped")
+self.try_breakpoint(True)
+
+def test_debuginfod_okd_symbols(self):
+"""
+Test behavior with the 'only-keep-debug' symbols available from
Debuginfod.
+"""
+test_root = self.config_test(["a.out"], "a.out.debug")
+self.try_breakpoint(True)
+
+def try_breakpoint(self, should_have_loc):
+"""
+This function creates a target from self.aout, sets a function-name
+breakpoint, and checks to see if we have a file/line location,
+as a way to validate that the symbols have been loaded.
+should_have_loc specifies if we're testing that symbols have or
+haven't been loaded.
+"""
+target = self.dbg.CreateTarget(self.aout)
+self.assertTrue(target and target.IsValid(), "Target is valid")
+
+bp = target.BreakpointCreateByName("func")
+self.assertTrue(bp and bp.IsValid(), "Breakpoint is valid")
+self.assertEqual(bp.GetNumLocations(), 1)
+
+loc = bp.GetLocationAtIndex(0)
+self.assertTrue(loc and loc.IsValid(), "Location is valid")
+addr = loc.GetAddress()
+self.assertTrue(addr and addr.IsValid(), "Loc address is valid")
+line_entry = addr.GetLineEntry()
+self.assertEqual(
+should_have_loc,
+line_entry != None and line_entry.IsValid(),
+"Loc line entry is valid",
+)
+if should_have_loc:
+self.assertEqual(line_entry.GetLine(), 4)
+self.assertEqual(
+line_entry.GetFileSpec().GetFilename(),
+self.main_source_file.GetFilename(),
+)
+self.dbg.DeleteTarget(target)
+shutil.rmtree(self.tmp_dir)
+
+def config_test(self, local_files, debuginfo=None, executable=None):
+"""
+Set up a test with local_files[] copied to a different location
+so that we control which files are, or are not, found in the file
system.
+Also, create a stand-alone file-system 'hosted' debuginfod server with
the
+provided debuginfo and executable files (if they exist)
+
+Make the filesystem look like:
+
+/tmp//test/[local_files]
+
+/tmp//cache (for lldb to use as a temp cache)
+
+/tmp//buildid//executable ->
+/tmp//buildid//debuginfo ->
+Returns the /tmp/ path
+"""
+
+self.build()
+
+uuid = self.getUUID("a.out")
+if not uuid:
+self.fail("Could not get UUID for a.out")
+return
+self.main_source_file = lldb.SBFileSpec("main.c")
+self.tmp_dir = tempfile.mkdtemp()
+test_dir = os.path.join(self.tmp_dir, "test")
+os.makedirs(test_dir)
+
+self.aout = ""
+# Copy the files used by the test:
+for f in local_files:
+shutil.copy(self.getBuildArtifact(f), test_dir)
+# The first item is the binary to be used for the test
+if self.aout == "":
[Lldb-commits] [lldb] LLDB Debuginfod tests and a fix or two (PR #90622)
@@ -44,6 +44,10 @@ lldb_build_intel_pt = '@LLDB_BUILD_INTEL_PT@'
if lldb_build_intel_pt == '1':
config.enabled_plugins.append('intel-pt')
+llvm_enable_curl = '@LLVM_ENABLE_CURL@'
labath wrote:
Emulating the curses dependency approach would probably be more consistent
(grep for `skipIfCursesSupportMissing`). Intel-pt does something different
because it lives outside of (lib)lldb.
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)
labath wrote: f8fedfb6802173372ec923f99f31d4af810fbcb0 ought to fix `TestSharedLibStrippedSymbols.py`. The rest might be due to the test being too strict with what it expects of a UUID. 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)
Prabhuk wrote: I am starting to see test failures in our toolchain builders after this patch: https://luci-milo.appspot.com/ui/p/fuchsia/builders/toolchain.ci/clang-linux-x64/b8749027826743254513/overview 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)
@@ -44,6 +44,10 @@ lldb_build_intel_pt = '@LLDB_BUILD_INTEL_PT@'
if lldb_build_intel_pt == '1':
config.enabled_plugins.append('intel-pt')
+llvm_enable_curl = '@LLVM_ENABLE_CURL@'
kevinfrei wrote:
I validated that this works correctly (had the same work). The *reason* it
works is because I added LLVM_ENABLE_CURL to the list in
`llvm_canonicalize_cmake_booleans` found in lldb/test/CMakeLists.txt.
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)
@@ -44,6 +44,10 @@ lldb_build_intel_pt = '@LLDB_BUILD_INTEL_PT@'
if lldb_build_intel_pt == '1':
config.enabled_plugins.append('intel-pt')
+llvm_enable_curl = '@LLVM_ENABLE_CURL@'
nico wrote:
Is this correct? Won't this expand to 'NO' which is truthy when expanded with
it off? Maybe you want this without quotes?
(Looks ike LLDB_BUILD_INTEL_PT gets this wrong too.)
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/clayborg closed 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/JDevlieghere approved this pull request. 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)
kevinfrei wrote: Can someone please approve this, so I can yet again see if one of the weird buildbot configurations I don't have the ability to try out fails on these tests? The C++ code really ought to ship, as it fixes some egregious issues that were regressed several months ago (due to lack of tests...) 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)
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 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
