In cases where the debugger load time is a worthwhile tradeoff (or less
costly - such as loading from a DWP instead of a variety of DWOs
(possibly over a high-latency/distributed filesystem)) against object
file size, it can be reasonable to disable pubnames and corresponding
gdb-index creation in the linker.
A backend-flag version of this was implemented for NVPTX in
D44385/r327994 - which was fine for NVPTX which wouldn't mix-and-match
CUs. Now that it's going to be a user-facing option (likely powered by
"-gno-pubnames", the same as GCC) it should be encoded in the
DICompileUnit so it can vary per-CU.
After this, likely the NVPTX support should be migrated to the metadata
& the previous flag implementation should be removed.
(I'm open to ideas on the naming here - whether the field should be called
"pubnames" or "pubnameKind" (to match "emissionKind") & the names of the
parameters (though currently it's a normal enum not an enum class, so the names
are uncscoped within DICompileUnit - so obvious names like "None" cause naming
collissions - hence the slightly awkward "Omitted", which, admittedly, still
isn't great))
I am sorry for not noticing this sooner, but I have a feeling this will break the CU references in the debug_names section in case of CUs with mixed pubnames flags (which I guess only could happen during LTO).
This code was (perhaps lazily) assuming that compile unit "unique IDs" form a continuous sequence from 0 to CUs.size()-1. This is relied upon by the lambda below which simply calls getUniqueID to get the value of the DW_IDX_compile_unit attribute. Now that the unique IDs and the CU lists in the name index don't match, I guess we'll have to create a separate lookup table for that.
(The assert here was meant to catch the case where the UniqueIDs stop being continuous, but I did not anticipate that we would start filtering them ourselves.)