[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:

> > re: producing the GCC-thing when gdb-tuning. I'd be hesitant to endorse that until someone has a specific gdb behavior/use case for this - it's possible GCC is producing something GDB doesn't need/use (there is precedent for this - view numbering, so far as I understand, is not implemented in gdb, for instance).
> > So, yeah, I'd be OK with the non-standard attr+form combo when tuning for lldb and not changing non-lldb tuning behavior.
> 
> > If we wanted to be more cautious, we could use an LLVM extension attribute for this - though I'd guess it'd produce the same-ish GDB behavior (it'd spit some warning about not knowing what the attribute is - but there'd be less risk that way, since GDB wouldn't be trying to interpret the index as an offset, which could collide, but is unlikely to - because it's always going to be 0)
> 
> Happy to go either way. Though it'd be nice not to have to maintain an LLVM extension which will be made obsolete by one of the ongoing DWARF proposals re. encoding `DW_AT_object_pointer` (be it using index or DIE relative offsets). We can also wait for the DWARF committee discussions to settle since there is no rush with this. It'll be useful for codebases adopting explicit object parameters, but LLDB's support is blocked on a couple of other things, not just this patch.

*nod* If you're not in too much of a rush, would be nice to see how it shakes out.

It's a bit of a stretch ask, but if you happened to have time/interest to gather the data I sort of volunteered to gather, that'd be handy - basically hacking up llvm-dwarfdump to gather data on the number of fixed-size DIEs (DIEs without LEBs, etc - where the size is known by the abbrev alone), how many of those would become non-fixed size if we used a LEB for DIE-to-DIE references (any form of class "reference"), and how many bytes would be saved by using DIE-to-DIE references (looking at the offsets of the referring DIE and the referent DIE, taking the difference and figuring out how long the LEB encoding for that difference is)...  hopefully that'd help inform the design decision.

I do worry that the indexed approach is a bit too niche - expedient, probably fairly benign (because it's niche, doesn't have a large area of effect, at least) - but really only comes up because LLVM hasn't emitted this particular attribute in this particular place before. Otherwise we wouldn't be looking at this particular place as being especially problematic/needing a unique fix.

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