clayborg wrote:
> Will this now work with .dwp files not having UUID?
I actually added a test for this and it works just fine if the main executable
(`a.out`) has a UUID and the debug info file (`a.out.debug`) also has the UUID,
but the .dwp file doesn't, we _are_ able to load the .dwp file ju
https://github.com/clayborg updated
https://github.com/llvm/llvm-project/pull/81067
>From 3c2f6039cf0e253d78b5193098b311028daaea72 Mon Sep 17 00:00:00 2001
From: Greg Clayton
Date: Wed, 7 Feb 2024 16:43:50 -0800
Subject: [PATCH 1/4] Add more ways to find the .dwp file.
When using split DWARF w
github-actions[bot] wrote:
:warning: C/C++ code formatter, clang-format found issues in your code.
:warning:
You can test this locally with the following command:
``bash
git-clang-format --diff c13e271a38363d354294e2af1651470bed8facb3
9d58f41457fc2c9e54b1409c64f3028fdaededf1 --
https://github.com/clayborg updated
https://github.com/llvm/llvm-project/pull/81067
>From 3c2f6039cf0e253d78b5193098b311028daaea72 Mon Sep 17 00:00:00 2001
From: Greg Clayton
Date: Wed, 7 Feb 2024 16:43:50 -0800
Subject: [PATCH 1/3] Add more ways to find the .dwp file.
When using split DWARF w
https://github.com/clayborg updated
https://github.com/llvm/llvm-project/pull/81067
>From 3c2f6039cf0e253d78b5193098b311028daaea72 Mon Sep 17 00:00:00 2001
From: Greg Clayton
Date: Wed, 7 Feb 2024 16:43:50 -0800
Subject: [PATCH 1/2] Add more ways to find the .dwp file.
When using split DWARF w
clayborg wrote:
> FWIW, I think we should be opinionated (& consistent with whatever gdb does,
> if it has some precedent here - if it is less opinionated, then maybe we have
> to be accepting) when it comes to whether x.debug goes with x.dwp or
> x.debug.dwp - we shouldn't support both unless
dwblaikie wrote:
> If the DWO ID is just a hash of the file path or something that isn't
> guaranteed to be unique with each new build, then we need the UUID in the
> .dwp file.
Nah, the DWO ID, as per spec, is a semantic hash of the DWARF contents. It
should change, generally, if any part of
clayborg wrote:
> > > Will this now work with .dwp files not having UUID?
> >
> >
> > No. If binairies have UUIDs (GNU build IDs), they need to match right now.
> > That is larger fix that involves adding a "enum UUIDFlavor" to the UUIDs so
> > we can ensure we aren't comparing two different
dwblaikie wrote:
FWIW, I think we should be opinionated (& consistent with whatever gdb does, if
it has some precedent here - if it is less opinionated, then maybe we have to
be accepting) when it comes to whether x.debug goes with x.dwp or x.debug.dwp -
we shouldn't support both unless there'
@@ -69,6 +83,19 @@
// RUN: -o "statistics dump" \
// RUN: %t.dwarf4 -b | FileCheck %s -check-prefix=CACHED
+// Make sure that if we load the "%t.dwarf4.debug" file, that we can find and
+// load the .dwo file from the .dwp when it is "%t.dwarf4.dwp"
+// RUN: %lldb %t.dwarf
@@ -4349,26 +4349,53 @@ SymbolFileDWARFDebugMap
*SymbolFileDWARF::GetDebugMapSymfile() {
const std::shared_ptr &SymbolFileDWARF::GetDwpSymbolFile()
{
llvm::call_once(m_dwp_symfile_once_flag, [this]() {
+// Create a list of files to try and append .dwp to
--
@@ -4349,26 +4349,53 @@ SymbolFileDWARFDebugMap
*SymbolFileDWARF::GetDebugMapSymfile() {
const std::shared_ptr &SymbolFileDWARF::GetDwpSymbolFile()
{
llvm::call_once(m_dwp_symfile_once_flag, [this]() {
+// Create a list of files to try and append .dwp to
+FileSpecL
@@ -4349,26 +4349,53 @@ SymbolFileDWARFDebugMap
*SymbolFileDWARF::GetDebugMapSymfile() {
const std::shared_ptr &SymbolFileDWARF::GetDwpSymbolFile()
{
llvm::call_once(m_dwp_symfile_once_flag, [this]() {
+// Create a list of files to try and append .dwp to
+FileSpecL
ayermolo wrote:
> > Will this now work with .dwp files not having UUID?
>
> No. If binairies have UUIDs (GNU build IDs), they need to match right now.
> That is larger fix that involves adding a "enum UUIDFlavor" to the UUIDs so
> we can ensure we aren't comparing two different things.
>
> Wh
clayborg wrote:
> Will this now work with .dwp files not having UUID?
No. If binairies have UUIDs (GNU build IDs), they need to match right now. That
is larger fix that involves adding a "enum UUIDFlavor" to the UUIDs so we can
ensure we aren't comparing two different things.
What Alexander i
kevinfrei wrote:
> Will this now work with .dwp files not having UUID?
The lack of UUID is kinda why this is so important. The connection is strictly
based on the filename. This just expands the variety of filenames that can be
supported. One thing that's helpful is that the .gnu_debuglink can
ayermolo wrote:
Will this now work with .dwp files not having UUID?
https://github.com/llvm/llvm-project/pull/81067
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/clayborg edited
https://github.com/llvm/llvm-project/pull/81067
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Greg Clayton (clayborg)
Changes
When using split DWARF we can run into many different ways to store debug info:
- lldb loads "" which contains skeleton DWARF and needs to find
".dwp"
- lldb loads "" which is stripped but has
https://github.com/clayborg created
https://github.com/llvm/llvm-project/pull/81067
When using split DWARF we can run into many different ways to store debug info:
- lldb loads "" which contains skeleton DWARF and needs to find ".dwp"
- lldb loads "" which is stripped but has .gnu_debuglink poin
20 matches
Mail list logo
