[Lldb-commits] [PATCH] D124198: [LLDB][Unwind] Add stack scanning as fallback unwind plan if no symbol file is available.

Pavel Labath via Phabricator via lldb-commits lldb-commits at lists.llvm.org
Thu Apr 28 03:05:20 PDT 2022

labath added a comment.

In D124198#3468039 <https://reviews.llvm.org/D124198#3468039>, @clayborg wrote:

> So there is real benefit to doing these checks IMHO as it can help us get back on track in live debug sessions. Core file sessions results will vary depending on it we actually have the original object files or not, many times we do not have this info, in which case we would just enable RA search and we might be able to unwind the PC, but not other registers if we can't actually find the prologue or if we don't have stack frame details from breakpad

I'm not saying we can't do that, but I don't think it has done be done straight in the first version. A lot of these checks are really just heuristics and can have false positives. For example, if we disqualify return addresses pointing to the first instruction of a function, then these  cases won't work:

- noreturn functions (the `call` could be the last instruction in the previous function)
- signal handler frames, where the handler's return address points to the first instruction of the trampoline (because it didn't really call it, but it still knows how to unwind from it)

I think it would be better discuss individual checks independently of the overall infrastructure (and ideally with more data).

That said, it would definitely be nice give some indication of how much do we trust the backtrace that we've computed. A separate command or a setting kind of achieve that, but they're very coarse-grained (you don't know how much trust to put into a particular backtrace), and they need the user to know of their existence. I am wondering whether attaching some kind of flag to a particular frame (similar to how we add `[opt]` for optimized functions) to indicate that it may not be entirely correct could be a better option.

  rG LLVM Github Monorepo



More information about the lldb-commits mailing list