On Fri, Sep 15, 2023 at 2:45 PM Alexander Yermolovich via Dwarf-discuss <dwarf-discuss@lists.dwarfstd.org> wrote: > > Hello > > I am trying to enable debug names acceleration table with > fdebug-types-sections in LLVM. One part I am not sure about is the local TU > list. It contains an offset into .debug_info section. All the entries have an > index entry that points to the local TU list. DIEs within entry offsets are > relative to the TU entry. > > Linker de-duplicates Type Units using COMDAT. So, the final result will have > less type units. As the result Local Type Unit List will be invalid, and all > the Entries that point to that TU will not be valid either. Even if we Linker > is modified so that somehow when it de-duplicates type sections Local Type > Units will get the right offset, that still leaves all the duplicate entries. > Am I missing something in that linker, specifically LLD, will need to be > aware of context of .debug_names sections when it de-duplicates type sections? > > > It seems to me that to fully support it .debug_names need to be created by > post build tool (or by linker....). > > Thanks.
While DWARF consumers will benefit from a content-aware linking of .debug_names (using one hash table is more efficient than probing hundreds/thousands of small hash tables), I don't believe the spec as-is requires that for correctness. In the case of type units, I'd expect behavior somewhat similar to how linkers behave with inline functions - if the two copies of the function are identical, it's possible that the linker will resolve all relocations to the function to the single copy that remains after linking (so two CUs would both describe the inline function "f1" and both descriptions would have the same start address/length, the two CUs CU-level DW_AT_ranges would overlap/both contain that function's addresses - and neither would use the tombstone address). So in that case, all the duplicate index entries would remain valid (their TU-relative offsets would be correct - since the TUs were bit-wise identical, so the offsets still point to the same things). In the case where a producer produces equivalent but not bitwise-identical TUs, the linker will choose one, drop the rest, and use the tombstone value to resolve the relocation used in the local TUs offset list. A consumer should ignore any entries that reference a tombstone offset in the local TU list (& probably wouldn't hurt to use the same code and ignore any tombstoned CUs too - I can't immediately think of a situation/reason that'd happen, but seems like a good general idea) If a consumer does a semantic aware merge of the indexes, then it should discard (rather than tombstoning) the index entries that reference dead TUs and the dead TUs in the local TU list itself, and also discard any duplicate index entries and duplicate elements in the local TU list. We could document the use of the tombstone in this context. -- Dwarf-discuss mailing list Dwarf-discuss@lists.dwarfstd.org https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
