[llvm] [Symbolizer] Compute Nearest Line Info for Address. (PR #71032)

James Henderson via llvm-commits llvm-commits at lists.llvm.org
Wed Nov 8 00:23:20 PST 2023


jh7370 wrote:

> > I no longer am, but keep monitoring upstream anyway
> 
> Ah - somewhat sorry to hear (hope you're working on other good things) - really appreciated your reviews/ownership (& been meaning to suggest maybe formalizing that - putting you down as code owner of llvm-symbolizer, if you think that's suitable) in this area - appreciate your continued investment here, even/especially when it's not your primary work anymore.

Thanks for the apppreciation. It's actually been that way for 2 and a half years, so I expect my activity levels to continue that way for the foreseeable future.  Regarding code ownership, I appreciate the suggestion. However, I don't think I'd be comfortable adopting that role formally, because there will be times due to work priorities when I might not be able to invest the necessary time.

> > 1. The last address before the current one with a non-zero line value.
> > 2. The last line table entry before the one for the specified address, with a non-zero line value.
> 
> Hmm, not sure I understand the difference between these two cases - could you show a small example/describe this in more detail?

It's subtle, I admit. It's based on my memory of the line table structure. IIRC, a line table sequence is a series of increasing address values, and could be roughly equated to a function. Clearly going forward or backward _within_ the sequence would be expected to yield the next/previous address where some usable line info may reside. However, the distinction comes at the edge of these sequences: if you go back/forward within the same table to the previous/next _sequence_, you'd likely jump to the function adjacent to the "real" one in the source file, which might or might not be correct, depending on what the optimizer has done. On the other hand, jumping to the previous/next _address_ might result in a jump to a completely different part of the line table, because the function has somehow been merged with a different function in the source file.

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


More information about the llvm-commits mailing list