Skip to content

Conversation

medismailben
Copy link
Member

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

@medismailben medismailben requested a review from bulbazord May 9, 2024 17:44
@medismailben medismailben requested a review from JDevlieghere as a code owner May 9, 2024 17:44
@llvmbot llvmbot added the lldb label May 9, 2024
@llvmbot
Copy link
Member

llvmbot commented May 9, 2024

@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 --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:

@medismailben medismailben force-pushed the fix-crashlog-executable-resolution branch 2 times, most recently from e2cd967 to b849720 Compare May 9, 2024 19:39
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 <ismail@bennani.ma>
@medismailben medismailben force-pushed the fix-crashlog-executable-resolution branch from b849720 to 1f63d68 Compare May 9, 2024 19:55
@medismailben medismailben merged commit f4a7e1f into llvm:main May 9, 2024
medismailben added a commit to medismailben/llvm-project that referenced this pull request May 14, 2024
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 <ismail@bennani.ma>
(cherry picked from commit f4a7e1f)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants