DWARF v5 accelerator tables provide a considerable performance
improvement for lldb and will make the default -glldb behavior same on
all targets (right now we emit apple tables on apple targets, but these
are not controlled by -gpubnames, only by -glldb).
Details
- Reviewers
dblaikie - Commits
- rGc1e0c34e4586: Re-commit "Enable DWARF accelerator tables by default when tuning for lldb…
rG5795673ef87b: Enable DWARF accelerator tables by default when tuning for lldb (-glldb =>…
rC341564: Re-commit "Enable DWARF accelerator tables by default when tuning for lldb…
rL341564: Re-commit "Enable DWARF accelerator tables by default when tuning for lldb…
rC341472: Enable DWARF accelerator tables by default when tuning for lldb (-glldb =>…
rL341472: Enable DWARF accelerator tables by default when tuning for lldb (-glldb =>…
Diff Detail
- Repository
- rL LLVM
Event Timeline
This is DWARF5+ only, right? (We shouldn't change the preference of Apple accelerator tables for DWARF 4 and earlier).
The interactions here are a bit weird, but the short answer is no, this will not affect apple tables in any way.
The long answer is: The type of accelerator tables that get generated gets chosen in the back end, based on target triple and dwarf version. If apple tables get chosen, then this patch makes no difference because apple tables ignore the -gpubnames argument. If dwarf tables get chosen, then they will only index the CUs which had the "pubnames" flag set to on (!None). This patch makes it such that we automatically set that flag when tuning for lldb, thereby obtaining the same default behavior as apple tables (indexing all CUs when tuning for lldb).
We want to ensure that both Apple and DWARF5 tables never get generated though. That would waste a lot of space. I would say if DWARF5 tables are enabled, then we need ensure we disable Apple tables.
Actually, we might need to still emit some Apple tables as the objective C and namespace tables might still be needed even with the DWARF5 tables.
That's already taken care of. The back end will always generate at most one kind of accel tables.