-gdwarf-5 -fdebug-types-section may produce multiple .debug_info sections. All
except one are type units (.debug_types before DWARF v5). When constructing
.gdb_index, we should ignore these type units. We use a simple heuristic: the
compile unit does not have the SHF_GROUP flag. (This needs to be revisited if
people place compile unit .debug_info in COMDAT groups.)
This issue manifests as a data race: because an object file may have multiple
.debug_info sections, we may concurrently construct LLDDwarfObj for the same
file in multiple threads. The threads may access InputSectionBase::data()
concurrently on the same input section. InputSectionBase::data() does a lazy
uncompress() and rewrites the member variable rawData. A thread running zlib
inflate() (transitively called by uncompress()) on a buffer with rawData
tampered by another thread may fail with uncompress failed: zlib error: Z_DATA_ERROR.
Even if no data race occurred in an optimistic run, if there are N .debug_info,
one CU entry and its address ranges will be replicated N times. The result
.gdb_index can be much larger than a correct one.
The new test gdb-index-dwarf5-type-unit.s actually has two compile units. This
cannot be produced with regular approaches (it can be produced with -r
--unique). This is used to demonstrate that the .gdb_index construction code
only considers the last non-SHF_GROUP .debug_info
clang-format suggested style edits found: