Change Details

-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.)

-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 reveals as a data race: because an object file may have multiple .debug_info sections, we may concurrently construct LLDDwarfObj for the same file. If InputSectionBase::data() is compressed, when calling `::uncompress` in one thread, this will trigger a race if another thread is also accessing the content.

-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 reveals as a data race: because an object file may have multiple .debug_info sections, we may concurrently construct LLDDwarfObj for the same file. If InputSectionBase::data() is compressed, when calling `::uncompress` in one thread, this will trigger a race if another thread is also accessing the content.