Skip to content

[lldb/crashlog] Fix module binary resolution #91631

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged

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 <[email protected]>
@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
4 checks passed
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 <[email protected]>
(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