================
@@ -87,8 +105,15 @@ SymbolVendorELF::CreateInstance(const lldb::ModuleSP
&module_sp,
FileSpecList search_paths = Target::GetDefaultDebugFileSearchPaths();
FileSpec dsym_fspec =
PluginManager::LocateExecutableSymbolFile(module_spec, search_paths);
- if (!dsym_fspec)
- return nullptr;
+ if (!dsym_fspec || IsDwpSymbolFile(module_sp, dsym_fspec)) {
+ // If we have a stripped binary or if we got a DWP file, we should prefer
+ // symbols in the executable acquired through a plugin.
+ ModuleSpec unstripped_spec =
+ PluginManager::LocateExecutableObjectFile(module_spec);
+ if (!unstripped_spec)
+ return nullptr;
+ dsym_fspec = unstripped_spec.GetFileSpec();
+ }
----------------
DavidSpickett wrote:
Something about this if block has broken `Expr/TestStringLiteralExpr.test` on
Arm 32 bit, a platform that has been sensitive to changes in this area in the
past. The test is built without debug info and something happens when the test
file comes through here. For ld.so and the libc it's all the same as before.
```
(lldb) expr "hello there"
lldb ProcessGDBRemote::DoAllocateMemory no direct stub support for
memory allocation, and InferiorCallMmap also failed - is stub missing register
context save/restore capability?
```
Last time this happened it was because we lost the symbols that let us call
`mmap`, but those are in ld.so usually so I'm not sure what's the problem this
time.
This means we fall back the interpreter, which we didn't need to do before.
```
error: Can't evaluate the expression without a running target due to:
Interpreter doesn't handle one of the expression's operands
```
I've reverted this
(https://github.com/llvm/llvm-project/commit/327bfc971e4dce3f6798843c92406cda95c07ba1)
and the follow up while I investigate locally.
https://github.com/llvm/llvm-project/pull/90622
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
