[llvm] [LLVM][DWARF] Add support for monolithic types in .debug_names (PR #68131)

[Greg Clayton via llvm-commits]

clayborg wrote:

> > > (not sure where it was recorded - maybe just in-person at LLVM dev)
> > > @ayermolo did manage to find some data showing maybe a 10% memory regression for an IR->object compilation (where the backend memory usage isn't overshadowed by the frontend's peak) & I think is looking into it.
> > 
> > 
> > Yep. It's in the one of the threads in this PR. github is just hiding it under "load more". Plan is to re-factor not to rely on DIE post PR, pot that, and then update this code.
> 
> Not to duplicate conversations all over the place, but another thought I've had in other threads:
> 
> What if .debug_names entries referencing type units didn't have a `DW_IDX_die_offset` at all & relied on the type unit header to reference the type in the type unit? (is there anything else in a type unit we could be referencing? I don't think so... )

LLDB really wants all types indexed in the type unit, not just the main type. STL classes have many internal typedef types contained in the type itself ("iterator", "const_iterator", "size_type", "pointer_type", etc) and LLDB would like to be able to use these types in expressions. If we went with the above solution where we just index the type unit type only, then we would only be able to use these contained types if code from a CU needed to reference any of these types and had a copy in the CU that was indexed.

So I would vote for a complete index of the TU, or don't emit anything at all for the TU and LLDB will manually index it. 

LLDB currently tracks which CUs and TUs have a .debug_names entry. For any CUs or TUs that don't have index entries, then we will manually index only the CUs and TUs that are not in any .debug_names. We needed to do this because many times you have mixed DWARF4 and DWARF5 object files that get compiled into the final executable.

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