[PATCH] D120660: [llvm-symbolizer] Add --approximate-missing-line-numbers Command Line Option

[David Blaikie via Phabricator via llvm-commits]

dblaikie added a comment.

In D120660#3357237 <https://reviews.llvm.org/D120660#3357237>, @probinson wrote:

> The decrementing solution came up because in the cases where we see this in the wild, it's symbolizing a backtrace (or possibly just one return address) and the return address naturally doesn't point to the call instruction, it points one past the call instruction; the instruction after a call might have line 0 for various reasons, the most blatant being that it's a `noreturn` call.  But the call instruction itself nearly always will not have line 0.

Wait, though, that seems like a very different problem from the one described - that seems like an issue of trying to symbolize the wrong address (well, I thought stack trace reports would subtract one from addresses, but it doesn't seem lke LLVM's crash handler does that - so it does give the address/symbolized location of the return address, not the point of the call - I've certainly had discussions with folks internally who get confused by that - but maybe changing it would produce more churn/confusion, even though it's I think what people are more likely to expect in a back trace ("where am I now" not "where will I be when each of these functions return"))

> So, _in practice_, we'll basically decrement once and be done.
>
> Obviously there can be pathological cases and we should avoid those.  But a "try decrementing once only" solution seems like it would solve the practical problem, and avoid the pathological cases.

I'm a bit less sure of this change/direction more generally, given this framing/motivation - like maybe decrementing once before even symbolizing would be better/more reliable/consistent in this use case? (but yeah, maybe more confusing for folks used to/more aware of the nuance of stack traces being where the program is returning to, rather than where it is currently - maybe there are further complications with tail calls, etc, which mean decrementing doesn't actually get you to the call site that reached the callee)

Still, if we're going this way, I'm not super happy with the probing approach - I /think/ it should probably be implemented at some lower level where we can walk backwards through the line table. Though, yeah, maybe that turns out to be silly complicated (especially when dealing with both the line table and the inline info from the debug_info DIEs too)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120660