[PATCH] D115325: [DWARF] Fix PR51087 Extraneous enum record in DWARF with type units

[Orlando Cazalet-Hyams via Phabricator via llvm-commits]

Orlando added a comment.

Sorry it's taken me a while to get back to you on this - thanks for all that info. Here is a summary of the situation as far as I understand it:

(without any version of these patches applied)

1. When type units are enabled, types that get a TU also get a skeleton CU DIE.
2. Some unused types are retained on purpose.
3. Types that are unreferenced within a CU still get (skeleton) DIEs in the CU, even if type units enabled (what this patch is trying to "fix").

(using pubnames to refer to both pubnames and pubtypes)

4. -gpubnames / .debug_pubnames is not compatible with type units.
5. -ggnu-pubnames / .debug_gnu_pubnames is compatible with type units.
6. .debug_names (DWARFv5) is compatible with type units.

Do you know what the deciding factor is in whether or not one of these kinds of tables is compatible with type units (4, 5, 6)? Naively, I assume that it is whether there provision for referencing a TU directly from the name table? i.e., .debug_gnu_pubnames and .debug_names can both directly reference a TU, but .debug_pubnames cannot. If my assumption is true, then I would think the answer to:

> But doesn't explain how we should create pubnames for types that don't have skeleton references from a CU.

is that we only have to do something special for DWARF v4 name tables (.debug_pubnames). But this seems to contradict "No accelerator tables if type units are enabled, as DWARF v4 type units are not compatible with accelerator tables.", which seems to suggest that we don't emit DWARF v4 accelerator tables at all when type units are enabled (name tables == accelerator tables?). I think I am still missing part of this picture. On that note, I found .debug_pubnames and .debug_names documentation easily (v4 and v5 spec), but I'm struggling to find any for .debug_gnu_pubnames.

In any case, the final point in summary:

7. The complexity we'd introduce in order to adhere to the various constraints makes fixing the issue probably not worth it.

So this should probably be abandoned, at least in it's current form.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D115325/new/

https://reviews.llvm.org/D115325