-
Notifications
You must be signed in to change notification settings - Fork 13.6k
[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
[lldb/crashlog] Fix module binary resolution #91631
Conversation
@llvm/pr-subscribers-lldb Author: Med Ismail Bennani (medismailben) ChangesThis 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 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 ( 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:
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:
|
e2cd967
to
b849720
Compare
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]>
b849720
to
1f63d68
Compare
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)
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