[PATCH] D50213: DebugInfo: Add metadata support for disabling DWARF pub sections

David Blaikie via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Aug 10 12:13:56 PDT 2018


dblaikie added a comment.

In https://reviews.llvm.org/D50213#1191902, @labath wrote:

> In https://reviews.llvm.org/D50213#1191664, @dblaikie wrote:
>
> > Actually - potentially we could merge the accelerator table options into this too, to promote them to an IR feature as well. But it looks like they aren't really supported on a per-CU basis, but are across the whole compilation only. (read the spec of debug_names - I see, best to emit the widest entry possible (ie: bad idea to emit one table per CU if we're emitting multiple CUs in a single object file (LTO) - and no need not to emit it if it's been requested, I suppose - though I guess a user might reasonably request no accelerator table for /some/ CUs they expect not to debug much/are OK with the debugger indexing slowly later on if they do)). But Apple's names don't support multiple CUs at all, so they can't be unified there anyway.
>
>
> I got lost a bit when trying to parse this, but I just wanted to confirm that debug_names tables are capable indexing only a subset of CUs in the LTO case (multiple CUs in one object file), and even without emitting one table per each indexed CU -- you would just list the CUs that you index in the single uber-table. (Not that I have an idea why would anyone want to do that). You are correct in saying that apple tables do not allow this.


Yeah, it was a bit rambly - thanks for that. I've implemented it so that 'nameTable: None' disables debug_names for that CU (but doesn't modify the behavior for the Apple names tables).

In https://reviews.llvm.org/D50213#1187570, @probinson wrote:

> How does this interact with v5 .debug_names?


Originally the patch had no effect on debug_names - I've now renamed the property to "nameTable" and "None" causes debug_names not to be emitted for that CU (test case shows that this works correctly for LTO situations where some CUs disable nameTable and some do not - or if they all disable nameTable then no debug_names section is produced at all).

(I'm going to write a follow-up patch to disable pubnames in DWARFv5 & clang patches with some flags to enable/disable debug_names/pubnames/gnu_pubnames from the clang driver)

In https://reviews.llvm.org/D50213#1187506, @JDevlieghere wrote:

> Regarding the naming: I like `PubnameKind` because of the aforementioned consistency (we also have `AccelTableKind`).


How's the change now - using "NameTableKind" since this now applies to debug_names as well.

> Can't we use an `enum class` to prevent collisions?

It's doable - just needed a few casts in places & fully qualify things in a few other places - so I've used "None, Default, GNU" as the enumerator names now.


Repository:
  rL LLVM

https://reviews.llvm.org/D50213





More information about the llvm-commits mailing list