[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