labath added inline comments.
================ Comment at: lldb/test/Shell/SymbolFile/Breakpad/unwind-via-stack-win-no-memory-info.yaml:13 # CHECK: frame #2: 0x000b1085 unwind-via-stack-win-no-memory-info.exe`main + 5 # CHECK: frame #3: 0x77278494 kernel32.dll # CHECK-NOT: frame ---------------- DavidSpickett wrote: > @labath In this case, without the x86 backend we do get the first 3 frames > just not the kernel32.dll frame. > > ``` > (lldb) target symbols add > ../llvm-project/lldb/test/Shell/SymbolFile/Breakpad/Inputs/unwind-via-raSearch.syms > symbol file > '/home/david.spickett/llvm-project/lldb/test/Shell/SymbolFile/Breakpad/Inputs/unwind-via-raSearch.syms' > has been added to '/home/david.spickett/build-llvm-aarch64/foo/foo.exe' > (lldb) thread backtrace > * thread #1 > * frame #0: 0x000b1092 foo.exe`many_pointer_args + 2 > frame #1: 0x000b1079 foo.exe`call_many + 105 > frame #2: 0x000b1085 foo.exe`main + > ``` > > So my guess is that the last frame requires x86 specific knowledge to work > out. If you think that's not the case or would prefer I investigate first I > can remove it from this patch. Nah, that's fine. I'm pretty sure that is what's happening, and overall, I would actually say lldb should flat out refuse to open binaries/core files/etc. for which it does not have an appropriate back end.... Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D100194/new/ https://reviews.llvm.org/D100194 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
