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.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D124198/new/

https://reviews.llvm.org/D124198

_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Reply via email to