[Lldb-commits] [lldb] [lldb/crashlog] Fix module binary resolution (PR #91631)
https://github.com/medismailben closed https://github.com/llvm/llvm-project/pull/91631 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb/crashlog] Fix module binary resolution (PR #91631)
https://github.com/bulbazord approved this pull request. https://github.com/llvm/llvm-project/pull/91631 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb/crashlog] Fix module binary resolution (PR #91631)
https://github.com/medismailben updated
https://github.com/llvm/llvm-project/pull/91631
>From 1f63d6807bc8a6b1e04cb96cbc7e4fd1572553e4 Mon Sep 17 00:00:00 2001
From: Med Ismail Bennani
Date: Thu, 9 May 2024 12:51:39 -0700
Subject: [PATCH] [lldb/crashlog] Fix module binary resolution
This patch fixes a bug in when resolving and loading modules from the
binary image list.
When loading a module, we would first use the UUID from the binary image
list with `dsymForUUID` to fetch the dSYM bundle from our remote build
records and copy the executable locally.
If we failed to find a matching dSYM bundle for that UUID on the build
record, let's say if that module was built locally, we use Spotlight
(`mdfind`) to find the dSYM bundle once again using the UUID.
Prior to this patch, we would set the image path to be the same as the
symbol file. This resulted in trying to load the dSYM as a module in
lldb, which isn't allowed.
This patch address that by looking for a binary matching the image
identifier, next to the dSYM bundle and try to load that instead.
rdar://127433616
Signed-off-by: Med Ismail Bennani
---
lldb/examples/python/crashlog.py | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/lldb/examples/python/crashlog.py b/lldb/examples/python/crashlog.py
index eb9af6ed3d95..2919b9c76e68 100755
--- a/lldb/examples/python/crashlog.py
+++ b/lldb/examples/python/crashlog.py
@@ -418,9 +418,20 @@ def locate_module_and_debug_symbols(self):
with print_lock:
print('falling back to binary inside "%s"' % dsym)
self.symfile = dsym
-for filename in os.listdir(dwarf_dir):
-self.path = os.path.join(dwarf_dir, filename)
-if self.find_matching_slice():
+# Look for the executable next to the dSYM bundle.
+parent_dir = os.path.dirname(dsym)
+executables = []
+for root, _, files in os.walk(parent_dir):
+for file in files:
+abs_path = os.path.join(root, file)
+if os.path.isfile(abs_path) and os.access(
+abs_path, os.X_OK
+):
+executables.append(abs_path)
+for binary in executables:
+basename = os.path.basename(binary)
+if basename == self.identifier:
+self.path = binary
found_matching_slice = True
break
if found_matching_slice:
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb/crashlog] Fix module binary resolution (PR #91631)
@@ -418,9 +418,20 @@ def locate_module_and_debug_symbols(self):
with print_lock:
print('falling back to binary inside "%s"' % dsym)
self.symfile = dsym
-for filename in os.listdir(dwarf_dir):
-self.path = os.path.join(dwarf_dir, filename)
-if self.find_matching_slice():
+# Look for the executable next to the dSYM bundle.
+parent_dir = os.path.dirname(dsym)
+executables = []
+for root, dirs, files in os.walk(parent_dir):
+for file in files:
+abs_path = os.path.join(root, file)
+if os.path.isfile(abs_path) and os.access(
medismailben wrote:
It could be block device or another file type fwiw.
https://github.com/llvm/llvm-project/pull/91631
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb/crashlog] Fix module binary resolution (PR #91631)
@@ -418,9 +418,20 @@ def locate_module_and_debug_symbols(self):
with print_lock:
print('falling back to binary inside "%s"' % dsym)
self.symfile = dsym
-for filename in os.listdir(dwarf_dir):
-self.path = os.path.join(dwarf_dir, filename)
-if self.find_matching_slice():
+# Look for the executable next to the dSYM bundle.
+parent_dir = os.path.dirname(dsym)
+executables = []
+for root, dirs, files in os.walk(parent_dir):
JDevlieghere wrote:
Let's use `_` instead of `dirs` as it's unused.
https://github.com/llvm/llvm-project/pull/91631
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb/crashlog] Fix module binary resolution (PR #91631)
https://github.com/JDevlieghere edited https://github.com/llvm/llvm-project/pull/91631 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb/crashlog] Fix module binary resolution (PR #91631)
https://github.com/JDevlieghere approved this pull request. https://github.com/llvm/llvm-project/pull/91631 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb/crashlog] Fix module binary resolution (PR #91631)
@@ -418,9 +418,20 @@ def locate_module_and_debug_symbols(self):
with print_lock:
print('falling back to binary inside "%s"' % dsym)
self.symfile = dsym
-for filename in os.listdir(dwarf_dir):
-self.path = os.path.join(dwarf_dir, filename)
-if self.find_matching_slice():
+# Look for the executable next to the dSYM bundle.
+parent_dir = os.path.dirname(dsym)
+executables = []
+for root, dirs, files in os.walk(parent_dir):
+for file in files:
+abs_path = os.path.join(root, file)
+if os.path.isfile(abs_path) and os.access(
bulbazord wrote:
This must necessarily be a file right? It's in the `files` output of `os.walk`.
Could it be something else?
https://github.com/llvm/llvm-project/pull/91631
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb/crashlog] Fix module binary resolution (PR #91631)
https://github.com/medismailben updated
https://github.com/llvm/llvm-project/pull/91631
>From b849720f6559392f91c54be5987beeb8c8c3fe21 Mon Sep 17 00:00:00 2001
From: Med Ismail Bennani
Date: Thu, 9 May 2024 12:39:01 -0700
Subject: [PATCH] [lldb/crashlog] Fix module binary resolution
This patch fixes a bug in when resolving and loading modules from the
binary image list.
When loading a module, we would first use the UUID from the binary image
list with `dsymForUUID` to fetch the dSYM bundle from our remote build
records and copy the executable locally.
If we failed to find a matching dSYM bundle for that UUID on the build
record, let's say if that module was built locally, we use Spotlight
(`mdfind`) to find the dSYM bundle once again using the UUID.
Prior to this patch, we would set the image path to be the same as the
symbol file. This resulted in trying to load the dSYM as a module in
lldb, which isn't allowed.
This patch address that by looking for a binary matching the image
identifier, next to the dSYM bundle and try to load that instead.
rdar://127433616
Signed-off-by: Med Ismail Bennani
---
lldb/examples/python/crashlog.py | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/lldb/examples/python/crashlog.py b/lldb/examples/python/crashlog.py
index eb9af6ed3d95c..124351f4d754b 100755
--- a/lldb/examples/python/crashlog.py
+++ b/lldb/examples/python/crashlog.py
@@ -418,9 +418,20 @@ def locate_module_and_debug_symbols(self):
with print_lock:
print('falling back to binary inside "%s"' % dsym)
self.symfile = dsym
-for filename in os.listdir(dwarf_dir):
-self.path = os.path.join(dwarf_dir, filename)
-if self.find_matching_slice():
+# Look for the executable next to the dSYM bundle.
+parent_dir = os.path.dirname(dsym)
+executables = []
+for root, dirs, files in os.walk(parent_dir):
+for file in files:
+abs_path = os.path.join(root, file)
+if os.path.isfile(abs_path) and os.access(
+abs_path, os.X_OK
+):
+executables.append(abs_path)
+for binary in executables:
+basename = os.path.basename(binary)
+if basename == self.identifier:
+self.path = binary
found_matching_slice = True
break
if found_matching_slice:
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb/crashlog] Fix module binary resolution (PR #91631)
https://github.com/medismailben updated
https://github.com/llvm/llvm-project/pull/91631
>From e2cd9670c20daac3f6a5f75806c7f48ed7b2ccd9 Mon Sep 17 00:00:00 2001
From: Med Ismail Bennani
Date: Thu, 9 May 2024 11:38:03 -0700
Subject: [PATCH] [lldb/crashlog] Fix module binary resolution
This patch fixes a bug in when resolving and loading modules from the
binary image list.
When loading a module, we would first use the UUID from the binary image
list with `dsymForUUID` to fetch the dSYM bundle from our remote build
records and copy the executable locally.
If we failed to find a matching dSYM bundle for that UUID on the build
record, let's say if that module was built locally, we use Spotlight
(`mdfind`) to find the dSYM bundle once again using the UUID.
Prior to this patch, we would set the image path to be the same as the
symbol file. This resulted in trying to load the dSYM as a module in
lldb, which isn't allowed.
This patch address that by looking for a binary matching the image
identifier, next to the dSYM bundle and try to load that instead.
rdar://127433616
Signed-off-by: Med Ismail Bennani
---
lldb/examples/python/crashlog.py | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/lldb/examples/python/crashlog.py b/lldb/examples/python/crashlog.py
index eb9af6ed3d95..4e79c718c9ea 100755
--- a/lldb/examples/python/crashlog.py
+++ b/lldb/examples/python/crashlog.py
@@ -418,9 +418,20 @@ def locate_module_and_debug_symbols(self):
with print_lock:
print('falling back to binary inside "%s"' % dsym)
self.symfile = dsym
-for filename in os.listdir(dwarf_dir):
-self.path = os.path.join(dwarf_dir, filename)
-if self.find_matching_slice():
+# Look for the executable next to the dSYM bundle.
+parent_dir = os.path.dirname(dsym)
+executables = []
+for root, dirs, files in os.walk(os.getcwd()):
+for file in files:
+abs_path = os.path.join(root, file)
+if os.path.isfile(abs_path) and os.access(
+abs_path, os.X_OK
+):
+executables.append(abs_path)
+for binary in executables:
+basename = os.path.basename(binary)
+if os.path.exists(abs_path) and basename ==
self.identifier:
+self.path = abs_path
found_matching_slice = True
break
if found_matching_slice:
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb/crashlog] Fix module binary resolution (PR #91631)
@@ -418,9 +418,22 @@ def locate_module_and_debug_symbols(self):
with print_lock:
print('falling back to binary inside "%s"' % dsym)
self.symfile = dsym
-for filename in os.listdir(dwarf_dir):
-self.path = os.path.join(dwarf_dir, filename)
-if self.find_matching_slice():
+# Look for the executable next to the dSYM bundle.
+parent_dir = os.path.dirname(dsym)
+find_results = (
+subprocess.check_output(
+'/usr/bin/find "%s" -type f \( -perm -u=x -o
-perm -g=x -o -perm -o=x \)'
+% parent_dir,
+shell=True,
+)
+.decode("utf-8")
+.splitlines()
+)
+for binary in find_results:
+abs_path = os.path.abspath(binary)
+basename = os.path.basename(binary)
+if os.path.exists(abs_path) and basename ==
self.identifier:
bulbazord wrote:
Do we expect `abs_path` to not exist after the call to `find`?
https://github.com/llvm/llvm-project/pull/91631
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb/crashlog] Fix module binary resolution (PR #91631)
@@ -418,9 +418,22 @@ def locate_module_and_debug_symbols(self):
with print_lock:
print('falling back to binary inside "%s"' % dsym)
self.symfile = dsym
-for filename in os.listdir(dwarf_dir):
-self.path = os.path.join(dwarf_dir, filename)
-if self.find_matching_slice():
+# Look for the executable next to the dSYM bundle.
+parent_dir = os.path.dirname(dsym)
+find_results = (
+subprocess.check_output(
+'/usr/bin/find "%s" -type f \( -perm -u=x -o
-perm -g=x -o -perm -o=x \)'
JDevlieghere wrote:
Rather than shelling out to find, can you use `os.walk`?
https://github.com/llvm/llvm-project/pull/91631
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb/crashlog] Fix module binary resolution (PR #91631)
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Med Ismail Bennani (medismailben)
Changes
This patch fixes a bug in when resolving and loading modules from the binary
image list.
When loading a module, we would first use the UUID from the binary image list
with `dsymForUUID` to fetch the dSYM bundle from our remote build records and
copy the executable locally.
If we failed to find a matching dSYM bundle for that UUID on the build record,
let's say if that module was built locally, we use Spotlight (`mdfind`) to find
the dSYM bundle once again using the UUID.
Prior to this patch, we would set the image path to be the same as the symbol
file. This resulted in trying to load the dSYM as a module in lldb, which isn't
allowed.
This patch address that by looking for a binary matching the image identifier,
next to the dSYM bundle and try to load that instead.
rdar://127433616
---
Full diff: https://github.com/llvm/llvm-project/pull/91631.diff
1 Files Affected:
- (modified) lldb/examples/python/crashlog.py (+16-3)
``diff
diff --git a/lldb/examples/python/crashlog.py b/lldb/examples/python/crashlog.py
index eb9af6ed3d95..3e3fa1d6ed3c 100755
--- a/lldb/examples/python/crashlog.py
+++ b/lldb/examples/python/crashlog.py
@@ -418,9 +418,22 @@ def locate_module_and_debug_symbols(self):
with print_lock:
print('falling back to binary inside "%s"' % dsym)
self.symfile = dsym
-for filename in os.listdir(dwarf_dir):
-self.path = os.path.join(dwarf_dir, filename)
-if self.find_matching_slice():
+# Look for the executable next to the dSYM bundle.
+parent_dir = os.path.dirname(dsym)
+find_results = (
+subprocess.check_output(
+'/usr/bin/find "%s" -type f \( -perm -u=x -o
-perm -g=x -o -perm -o=x \)'
+% parent_dir,
+shell=True,
+)
+.decode("utf-8")
+.splitlines()
+)
+for binary in find_results:
+abs_path = os.path.abspath(binary)
+basename = os.path.basename(binary)
+if os.path.exists(abs_path) and basename ==
self.identifier:
+self.path = abs_path
found_matching_slice = True
break
if found_matching_slice:
``
https://github.com/llvm/llvm-project/pull/91631
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb/crashlog] Fix module binary resolution (PR #91631)
https://github.com/medismailben created
https://github.com/llvm/llvm-project/pull/91631
This patch fixes a bug in when resolving and loading modules from the binary
image list.
When loading a module, we would first use the UUID from the binary image list
with `dsymForUUID` to fetch the dSYM bundle from our remote build records and
copy the executable locally.
If we failed to find a matching dSYM bundle for that UUID on the build record,
let's say if that module was built locally, we use Spotlight (`mdfind`) to find
the dSYM bundle once again using the UUID.
Prior to this patch, we would set the image path to be the same as the symbol
file. This resulted in trying to load the dSYM as a module in lldb, which isn't
allowed.
This patch address that by looking for a binary matching the image identifier,
next to the dSYM bundle and try to load that instead.
rdar://127433616
>From 13497173bbcc1007bb1ad01820237b934c9a88f4 Mon Sep 17 00:00:00 2001
From: Med Ismail Bennani
Date: Thu, 9 May 2024 09:52:38 -0700
Subject: [PATCH] [lldb/crashlog] Fix module binary resolution
This patch fixes a bug in when resolving and loading modules from the
binary image list.
When loading a module, we would first use the UUID from the binary image
list with `dsymForUUID` to fetch the dSYM bundle from our remote build
records and copy the executable locally.
If we failed to find a matching dSYM bundle for that UUID on the build
record, let's say if that module was built locally, we use Spotlight
(`mdfind`) to find the dSYM bundle once again using the UUID.
Prior to this patch, we would set the image path to be the same as the
symbol file. This resulted in trying to load the dSYM as a module in
lldb, which isn't allowed.
This patch address that by looking for a binary matching the image
identifier, next to the dSYM bundle and try to load that instead.
rdar://127433616
Signed-off-by: Med Ismail Bennani
---
lldb/examples/python/crashlog.py | 19 ---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/lldb/examples/python/crashlog.py b/lldb/examples/python/crashlog.py
index eb9af6ed3d95c..3e3fa1d6ed3c7 100755
--- a/lldb/examples/python/crashlog.py
+++ b/lldb/examples/python/crashlog.py
@@ -418,9 +418,22 @@ def locate_module_and_debug_symbols(self):
with print_lock:
print('falling back to binary inside "%s"' % dsym)
self.symfile = dsym
-for filename in os.listdir(dwarf_dir):
-self.path = os.path.join(dwarf_dir, filename)
-if self.find_matching_slice():
+# Look for the executable next to the dSYM bundle.
+parent_dir = os.path.dirname(dsym)
+find_results = (
+subprocess.check_output(
+'/usr/bin/find "%s" -type f \( -perm -u=x -o
-perm -g=x -o -perm -o=x \)'
+% parent_dir,
+shell=True,
+)
+.decode("utf-8")
+.splitlines()
+)
+for binary in find_results:
+abs_path = os.path.abspath(binary)
+basename = os.path.basename(binary)
+if os.path.exists(abs_path) and basename ==
self.identifier:
+self.path = abs_path
found_matching_slice = True
break
if found_matching_slice:
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
