[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.

> Hrm :/ I'm not super enthusiastic about either direction. I'm starting to wonder whether this general direction is viable - that some DWARF consumers might not find types that are in type units but aren't referenced from the CUs at all.
>
> Do you have a measure of the debug info size improvement of this direction? If it doesn't end up counting for much, maybe it's not worth trying to create this possibly novel debug info?

For non-pathological cases the saving appears to be negligible. The CTMark projects all have total debug section size savings of less than 0.1% with this patch applied when built with `-fdebug-types-section -gdwarf-5 ` in RelWithDebInfo configuration. Unfortunately, I don't actually have access to the pathological source that prompted this patch. We (@jmorse) only have a binary built with clang with what looks like a load of redundant DIEs in it and I don't think it's likely that we'll be able to get our hands on that source.

> Do you know/could you look to see if there's any case where GCC produces type units without skeleton types that reference them? If there are such cases, that'd be reassuring, and may also help inform how we should behave with pubnames etc.

I've just had a look with gcc 7.5 (because it's what I have installed; I can spend more time getting/building a recent version?). Interestingly, GCC 7.5 doesn't produce CU skeleton DIEs at all when type units are enabled, even when types are used in the CU.

Taking some source from my test in this patch, you can see that the TU for `Ex::Enum` (a type that //is// used) is referenced directly by the DW_AT_type by its signature:

  $ cat test.cpp
  struct Ex { enum Enum { X }; };
  void fun() { Ex::Enum local; }
  
  $ gcc -c -O2 -g -fdebug-types-section -gdwarf-5  test.cpp -o test_gcc
  $ llvm-dwarfdump -v test_gcc --name local
  test_gcc:	file format elf64-x86-64
  
  0x00000052: DW_TAG_variable [11]   (0x00000035)
                DW_AT_name [DW_FORM_strp]	( .debug_str[0x00000028] = "local")
                DW_AT_decl_file [DW_FORM_data1]	("/home/och/dev/bugs/scratch/test.cpp")
                DW_AT_decl_line [DW_FORM_data1]	(2)
                DW_AT_type [DW_FORM_ref_sig8]	(0x22f6e0a3cab4ab3c)

So, gcc appears to omit the CU skeleton DIE entirely when type units are used. That said, llvm-dwarfdump seems unhappy when we throw pubnames into the mix, but I don't know if this is gcc bug or not (see "error" in the output below):

  $ gcc -c -O2 -g -fdebug-types-section -gdwarf-5  test.cpp -o test_gcc_pubnames -gpubnames
  $ llvm-dwarfdump -v test_gcc_pubnames
  ...
  .debug_pubnames contents:
  length = 0x00000016, format = DWARF32, version = 0x0002, unit_offset = 0x00000000, unit_size = 0x00000063
  Offset     Name
  0x00000035 "fun"
  
  .debug_pubtypes contents:
  error: name lookup table at offset 0x0 has a terminator at offset 0x1f before the expected end at 0x26
  length = 0x00000026, format = DWARF32, version = 0x0002, unit_offset = 0x00000000, unit_size = 0x00000063
  Offset     Name
  0x0000002e "unsigned int"



> & have you tested this sort of DWARF (TUs without skeleton type references) with GDB and LLDB, do they seem to find the types well?

Just checked and LLDB (trunk) appears to be able to find types that are only described by TUs (not referenced in the CU at all). i.e. AFAICT it can handle the output of this patch. I don't have a recent GDB installed (the version I have doesn't seem to be able to handle type units at all).

Looking at the DWARFv5 spec while trying to get my head round pubnames, I see that there's a v5 specific section that combines pubnames and pubtypes called debug_names. Sorry if this is a silly question - this part of DWARF is new to me - does clang support emitting debug_names?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115325