-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
So, you need this to read the flags from the sh_flags field of a section header in the initial object.
And you can't just use sec->flags, because we drop the SHF_GROUP flag much earlier.
I do not know a simpler way to access initial flags. Though probably it worth adding an assert to check that the number
of sections in obj->getObj().sections() == the number of them in obj->getSections() and a comment
about SHT_GROUP flag? That way we will not forget to simplify this loop back later when will stop relying on SHF_GROUP flag.