[lld] [llvm] [Symbolizer] Support for Missing Line Numbers. (PR #82240)

via llvm-commits llvm-commits at lists.llvm.org
Wed Apr 24 02:22:35 PDT 2024


bd1976bris wrote:

Hi All!

>From Sony's POV the primary issue that we would like to solve is reporting effective line numbers when symbolizing stack traces. Currently, we have customers manually decrementing addresses when 0 is reported as the line number to try to get a useful line number reported. Customers report that they are generally happy with understanding their stack traces when they do this manually. Therefore, we would like to see a feature to improve on the customer doing this manually or scripting it up themselves.

This PR meets our criteria and we would be happy to see it (or an equivalent implementation) merged:

1. Utility - this PR reports satisfactory line numbers for problem stack walks we have had reported.
 
2. Potential for confusion - this PR is opt-in (via '-approximate-line-info=<before/after>') and clearly labels the line numbers produced as guesses by appending the string "(approximate)" to the output, this seems adequate to address the problem of potentially confusing users.
 
3. Provide an advantage over a simple script - this PR tries to limit the address range tried using the high/low PC and the presence of basic_block/prologue_end instructions. This is better than just trying decremented addresses until a non-zero line is found. This would also be reasonably difficult to implement in a script which parses the output from the binutils we provide, so including the functionality in symbolizer makes sense.

As to the best implementation I don't have a firm opinion yet. I will try to poke at this and provide some feedback. One open question I would like to understand is: How misleading/confusing could the approximate line numbers be? An answer to that would be useful in evaluating different implementations. In Sony's case we are really interested in the answer to the previous question when we restrict it to the case of symbolizing stack traces. I also wonder if function inlining can pose/exacerbate any correctness issues? 


https://github.com/llvm/llvm-project/pull/82240


More information about the llvm-commits mailing list