This is an archive of the discontinued LLVM Phabricator instance.

[BOLT][DWARF] Handle shared abbrev section
ClosedPublic

Authored by ayermolo on Jan 28 2022, 4:33 PM.

Details

Summary

We can have a scenario where multiple CUs share an abbrev table.
We modify or don't modify one CU, which leads to other CUs having invalid abbrev section.
Example that caused it.
All of CUs shared the same abbrev table. First CU just had compile_unit and sub_program.
It was not modified. Next CU had DW_TAG_lexical_block with
DW_AT_low_pc/DW_AT_high_pc converted to DW_AT_low_pc/DW_AT_ranges.
We used unmodified abbrev section for first and subsequent CUs.
So when parsing subsequent CUs debug info was corrupted.

In this patch we will now duplicate all sections that are modified and are different.
This also means that if .debug_types is present and it shares Abbrev table, and
they usually are, we now can have two Abbrev tables. One for CU that was modified,
and unmodified one for TU.

Diff Detail

Event Timeline

ayermolo created this revision.Jan 28 2022, 4:33 PM
ayermolo requested review of this revision.Jan 28 2022, 4:33 PM
Herald added a project: Restricted Project. · View Herald TranscriptJan 28 2022, 4:33 PM
Amir added a comment.Jan 28 2022, 5:05 PM

Is the input bolt/test/X86/Inputs/dwarfdump-gdbindex-v7.elf-x86-64.yaml still used?

bolt/include/bolt/Core/DebugData.h
722

Better to use llvm::StringMap in this case. It probably doesn't remove the need for llvm::SHA1 Hasher: StringMap will hash the key internally, but still store it.

Is the input bolt/test/X86/Inputs/dwarfdump-gdbindex-v7.elf-x86-64.yaml still used?

No

ayermolo updated this revision to Diff 404201.Jan 28 2022, 5:25 PM

addressed comment

maksfb accepted this revision.Jan 31 2022, 9:59 AM

LGTM

This revision is now accepted and ready to land.Jan 31 2022, 9:59 AM
This revision was landed with ongoing or failed builds.Jan 31 2022, 11:10 AM
This revision was automatically updated to reflect the committed changes.
ayermolo marked an inline comment as done.