[llvm] [llvm][DebugInfo] Encode DW_AT_object_pointer on method declarations with DW_FORM_implicit_const (PR #124790)

[David Blaikie via llvm-commits]

dwblaikie wrote:

A little more detail in the description explaining that this implicit_const would be the index of the parameter that is the object pointer would be good - and that this is an extension/not the way the spec says to use this attribute.

Even though we're only using this as an lldb extension, might be worth getting some buy-in from Sony (@jmorse) and maybe @adrian-prantl or @JDevlieghere could take a look, just so we're all on the same page. (@labath - any thoughts on this?)

But all that pending the further investigation of the cost you mentioned here: https://github.com/llvm/llvm-project/pull/122742#issuecomment-2619650292

I'll see about sending a revert cl in the mean time.

(also, if this impact isn't because of bugs, but just the direct implementation of object_pointer on declarations - it makes me wonder about other ways to reduce the size of member function declarations. Like usually the file name is the same as the class's file name, so could we have an implicit_const value (-1?) to specify that the member function's file is the same as the class's file (could generalize to "-N" for N scopes back if that was useful) - could be used on local variables or other entities where their filename matches their scope's filename
Also formal parameters - have a type or an abstract origin, both of which are 4 byte refs - maybe a generalized sleb128 relative DIE offset would be helpful (bit difficult to implement in LLVM's output, since the LEB128 encoding would depend on the size of other DWARF encodings, etc, and we currently compute that all up-front, but if we switched to label-based output, we could let the assembler handle that complexity & have more legible/hand-modifiable DWARF assembly, since it wouldn't contain so many hard coded constants))

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