[Lldb-commits] [lldb] ObjectFileJSON and Section changes to support section.address field i… (PR #101062)

[Ilhan Raja via lldb-commits]

YungRaj wrote:

> > > I was hoping to fix everything in one Pull Request so that it at least becomes usable once this merges.
> > 
> > 
> > The LLVM project generally [prefers](https://llvm.org/docs/CodeReview.html#code-reviews-speed-and-reciprocity) smaller patches as they're easier to review. We'll definitely want to fix the end-to-end issue and have a test, but the deserialization issue can stand on its own and deserves its own PR.
> 
> Sounds good. Will divide the pull requests into many of them.
> 
> So I tried to get symbolicating backtraces working, however, this is a bit more challenging, because LLDB doesn't have a good intuition of building a `AddressRange` e.g. the start to finish of a function. It's not that I couldn't get addresses to symbolicate, but many functions that get symbolicated are actually from functions before it that had the subsequent function unsymbolicated. Thus the symbols clash and the backtraces are low accuracy.
> 
> @JDevlieghere do you believe there is a way to fix LLDB's intuition of the proper bounds of functions based on function prologues (e.g. `BTI`, `PACIBSP`, `STP X29, X30, [SP, #-offset]!` on arm64) and epilogues (`RET`, `RETAB`, etc on arm64) ? Technically, decompilers are able to effectively build this intuition, but the metadata for that doesn't get exported into the linker map files. Is this non-trivial in general? Could lifting via IR be effective here (even though I doubt the LLDB source supports that)?
> 
> If this is not achievable, what would it take to get type information supported by `ObjectFileJSON`? This isn't a strict requirement of mine, but it'd be a nice to reduce the quantity of things that I would need to do by hand.

It looks like the best way to do this is force the decompiler to produce the end address in a symbol file. This is not supported by linker map files, but can be procured using a IDAPython script.

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