This is an archive of the discontinued LLVM Phabricator instance.

Enable DWARF accelerator tables by default when tuning for lldb (-glldb => -gpubnames)
ClosedPublic

Authored by labath on Sep 2 2018, 3:34 AM.

Diff Detail

Repository
rL LLVM

Event Timeline

labath created this revision.Sep 2 2018, 3:34 AM

This is DWARF5+ only, right? (We shouldn't change the preference of Apple accelerator tables for DWARF 4 and earlier).

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.

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.

That's already taken care of. The back end will always generate at most one kind of accel tables.

The interactions here are a bit weird, but the short answer is no, this will not affect apple tables in any way.

Then I have no problem with this patch :-)

dblaikie accepted this revision.Sep 4 2018, 1:47 PM

Looks good to me & the answers to others various questions seem well addressed.

This revision is now accepted and ready to land.Sep 4 2018, 1:47 PM
This revision was automatically updated to reflect the committed changes.