[ObjectYAML][ELF] Add support for emitting the .debug_gnu_pubnames/pubtypes sections.

[Higuoxing]

Summary

This patch helps add support for emitting the .debug_gnu_pubnames and .debug_gnu_pubtypes sections.

The .debug_gnu_pub* sections is verified by llvm-dwarfdump.

Known issues:

• Doesn't support emitting multiple pub-tables.

[jhenderson]

My understanding of the .debug_gun_pubnames table is that it is a slightly different format to the .debug_pubnames table. The output of yaml2obj here is not consistent with the parsing code for GNU style, as far as I can tell, because of this and the bug you mentioned. I don't think we should add support for the section unless it is actually formatted correctly, as it is likely to cause confusion, should anybody attempt to use it in its seemingly-working-but-broken state.

[Higuoxing]

In D82367#2108887, @jhenderson wrote:

My understanding of the .debug_gun_pubnames table is that it is a slightly different format to the .debug_pubnames table. The output of yaml2obj here is not consistent with the parsing code for GNU style, as far as I can tell, because of this and the bug you mentioned. I don't think we should add support for the section unless it is actually formatted correctly, as it is likely to cause confusion, should anybody attempt to use it in its seemingly-working-but-broken state.

Got it! I will try to fix it later.

[Higuoxing]

Update.

[jhenderson]

LGTM, with one suggestion.

llvm/test/tools/yaml2obj/ELF/DWARF/debug-gnu-pubtypes.yaml

110

Probably missed this elsewhere, but can't this be SIZE-NEXT?

[dblaikie]

llvm/test/tools/yaml2obj/ELF/DWARF/debug-gnu-pubnames.yaml

9–10

Should this be tested via llvm-dwarfdump instead? (perhaps there's already lots of precedent/reasons that yaml2obj is being tested via readobj?)

[Higuoxing]

llvm/test/tools/yaml2obj/ELF/DWARF/debug-gnu-pubnames.yaml

9–10

Because some tests in llvm-dwarfdump are using yaml2obj to generate DWARF sections, e.g., llvm-dwarfdump/X86/verify_overlapping_cu_ranges.yaml, llvm-dwarfdump/X86/Inputs/i386_macho_with_debug.yaml, etc. We don't want to create a circular dependency. Does it make sense?

[dblaikie]

llvm/test/tools/yaml2obj/ELF/DWARF/debug-gnu-pubnames.yaml

9–10

Hmm, fair enough. Not sure what the right call is there - I would've thought assembly would be easier to read than hex object dumps? Case in point with these hex dumps and multiline ASCII art comments, compared to assembly with comments & appropriate-width values, symbolic expressions, etc.

(so using assembly tests for llvm-dwarfdump and then llvm-dwarfdump for tests of obj2yaml, rather than obj2yaml tests of llvm-dwarfdump and objdump tests of obj2yaml)

[jhenderson]

llvm/test/tools/yaml2obj/ELF/DWARF/debug-gnu-pubnames.yaml

9–10

(just in case you missed it, this is a yaml2obj test). The intent longer term with @Higuoxing's project is to get yaml2obj DWARF support to a good enough state that it makes it much easier to craft tests for llvm-dwarfdump etc without needing to specify all the fine details that assembly currently requires (just consider how much assembly some of the exisiting llvm-dwarfdump tests require for example). Assembly would probably still work well for creating broken inputs, but yaml2obj would be better for the higher-level testing.

The problem of course with using yaml2obj to test llvm-dwarfdump is that we can't use the reverse. Somewhere, we have to test either hex output or use assembly (or YAML + raw content hex) input. Whilst I agree assembly input would be easier to read than this hex output, it rather defeats the point of the project, and it doesn't scale well (in theory, the testing here can be kept fairly small, so the costs of having hex aren't too great).

Once we have basic testing in place for all the DWARF sections, it should be possible to use llvm-dwarfdump to verify the higher level auto-generation of things by yaml2obj that is intended for later in the project.

[Higuoxing]

llvm/test/tools/yaml2obj/ELF/DWARF/debug-gnu-pubnames.yaml

9–10

Oops, I missed @dblaikie 's previous comments. Thank you @jhenderson for clarifying this for me!

[dblaikie]

llvm/test/tools/yaml2obj/ELF/DWARF/debug-gnu-pubnames.yaml

9–10

Whilst I agree assembly input would be easier to read than this hex output, it rather defeats the point of the project, and it doesn't scale well (in theory, the testing here can be kept fairly small, so the costs of having hex aren't too great).

Not sure - why is it likely that the yaml2obj+hexdump tests scale better than the assembly+llvm-dwarfdump tests directly? Seems like we'd have to test maybe as many weird cases of DWARF emission to get a nice legible format for writing dwarfdump tests as we would for the dwarfdump tests themselves? It's starting to feel a bit "turtles all the way down" to me.

Something like yaml2obj could be handy for testing lldb, for instance - constructing arbitrarily interesting inputs. But for the yaml2obj<>llvm-dwarfdump circularity, I'm not so sure.

[jhenderson]

llvm/test/tools/yaml2obj/ELF/DWARF/debug-gnu-pubnames.yaml

9–10

By "scale" I meant the auto-generation aspects probably don't need to be tested using hex dumps, so can be tested using llvm-dwarfdump, but honestly I'm not sure either way too.

[dblaikie]

llvm/test/tools/yaml2obj/ELF/DWARF/debug-gnu-pubnames.yaml

9–10

By "scale" I meant the auto-generation aspects probably don't need to be tested using hex dumps, so can be tested using llvm-dwarfdump, but honestly I'm not sure either way too.

What do you mean by "auto-generation aspects"?

But, yeah, I'm not holding this patch up over this direction that's already got precedent, etc - but raising the question at least for consideration/thinking about over time.

[jhenderson]

llvm/test/tools/yaml2obj/ELF/DWARF/debug-gnu-pubnames.yaml

9–10

At the moment, to use yaml2obj to generate DWARF, you have to specify pretty much every detail of the DWARF, including the details of the abbrev table and the string table for example. Ideally, we should be able to describe the DWARF in a higher level manner (e.g. by just specifying the attributes and values in the .debug_info description, letting yaml2obj do all the leg work of selecting a form, populating the abbrev and string tables etc). You'll see details of this in @Higuoxing's mailing list posts about his GSOC project.

We can use the basic-level testing for "bootstrapping". yaml2obj can generate valid raw sections, tested via hex -> allows testing of llvm-dwarfdump section dumping -> allows testing of yaml2obj higher-level functionality (because we know that llvm-dwarfdump section dumping now works).

[dblaikie]

llvm/test/tools/yaml2obj/ELF/DWARF/debug-gnu-pubnames.yaml

9–10

That seems like it's going to be fairly subtle/hard to maintain the separation here - if some yaml2obj tests use hex dumping but others can use llvm-dwarfdump - if/when/that's happening, might be worth separate directories for the two kinds of tests and some fairly specific documentation about how to determine which tests go where.

[Higuoxing]

llvm/test/tools/yaml2obj/ELF/DWARF/debug-gnu-pubnames.yaml

9–10

What do you think of making elf2yaml support dumping DWARF sections? In the future, we can use raw assembly to test elf2yaml and use elf2yaml to test yaml2elf.

[dblaikie]

llvm/test/tools/yaml2obj/ELF/DWARF/debug-gnu-pubnames.yaml

9–10

Probably useful that elf2yaml and yaml2elf roundtrip/support the same features (would make it easier to create yaml files to work with/pare down, etc).

But as for testing - not sure - seems like it adds another layer of indirection (then we'd use raw assembly+llvm-mc to test elf2yaml, to test yaml2elf, to test llvm-dwarfdump - when we could've been using raw assembly to test llvm-dwarfdump) & not sure how much it improves/streamlines the testing matrix.

All that said, we did used to test llvm-dwarfdump with checked in object files - then we accepted that assembly + llvm-mc didn't especially reduce the test quality despite increasing the surface area of the test by using llvm-mc. Though I think the more DWARF-specific the functionality gets the less that sort of line of reasoning applies (ie: Once we're generating all of DWARF - we're reaching the same complexity as the parsing logic and have now written a whole other DWARF representation with all the risk of bugs, etc).

But really - I don't have any particular action/takeaway from these thoughts right now, but I think they're worth keeping in mind/thinking about as this work continues.

[clayborg]

Is ".debug_gnu_pubtypes" different and/or better than the old ".debug_pubtypes" in terms of contents? AFAIK all debuggers completely ignore these sections as they don't contain all types (only public types). I did a quick web search for ".debug_gnu_pubtypes" and didn't find any docs or anything documenting this format.

[dblaikie]

In D82367#3133081, @clayborg wrote:

Is ".debug_gnu_pubtypes" different and/or better than the old ".debug_pubtypes" in terms of contents? AFAIK all debuggers completely ignore these sections as they don't contain all types (only public types). I did a quick web search for ".debug_gnu_pubtypes" and didn't find any docs or anything documenting this format.

My general understanding is that GCC/GDB folks implemented .debug_gnu_pubnames(/types) because of the lack of guarantees in debug_pubnames(/types) - GCC does consume/rely on these sections (& gold can produce .gdb_index from these gnu_pub* sections - which is /necessary/ for correctness of gdb when using Split DWARF, in fact).

I'm guessing like lots of stuff, it's probably basically defined by the agreement between GCC and GDB - and Clang/LLVM just tries to implement gnu_pub* to be as compatible as possible with that.

[clayborg]

In D82367#3133132, @dblaikie wrote:

In D82367#3133081, @clayborg wrote:

Is ".debug_gnu_pubtypes" different and/or better than the old ".debug_pubtypes" in terms of contents? AFAIK all debuggers completely ignore these sections as they don't contain all types (only public types). I did a quick web search for ".debug_gnu_pubtypes" and didn't find any docs or anything documenting this format.

My general understanding is that GCC/GDB folks implemented .debug_gnu_pubnames(/types) because of the lack of guarantees in debug_pubnames(/types) - GCC does consume/rely on these sections (& gold can produce .gdb_index from these gnu_pub* sections - which is /necessary/ for correctness of gdb when using Split DWARF, in fact).

I'm guessing like lots of stuff, it's probably basically defined by the agreement between GCC and GDB - and Clang/LLVM just tries to implement gnu_pub* to be as compatible as possible with that.

Was there any documentation on this where the contents of this new format are detailed? Sounds promising and I would love to have LLDB to not have to manually index DWARF on all linux/android targets if at all possible.

[Higuoxing]

The GCC doc mentions that the "-ggnu-pubnames" option is only useful with a linker that can produce GDB@ index version 7.

@item -ggnu-pubnames
@opindex ggnu-pubnames
Generate @code{.debug_pubnames} and @code{.debug_pubtypes} sections in a format
suitable for conversion into a GDB@ index.  This option is only useful
with a linker that can produce GDB@ index version 7.

See: https://raw.githubusercontent.com/gcc-mirror/gcc/master/gcc/doc/invoke.texi (This file is large, searching key word "ggnu-pubnames" may help)

[dblaikie]

In D82367#3133152, @clayborg wrote:

In D82367#3133132, @dblaikie wrote:

In D82367#3133081, @clayborg wrote:

Is ".debug_gnu_pubtypes" different and/or better than the old ".debug_pubtypes" in terms of contents? AFAIK all debuggers completely ignore these sections as they don't contain all types (only public types). I did a quick web search for ".debug_gnu_pubtypes" and didn't find any docs or anything documenting this format.

My general understanding is that GCC/GDB folks implemented .debug_gnu_pubnames(/types) because of the lack of guarantees in debug_pubnames(/types) - GCC does consume/rely on these sections (& gold can produce .gdb_index from these gnu_pub* sections - which is /necessary/ for correctness of gdb when using Split DWARF, in fact).

I'm guessing like lots of stuff, it's probably basically defined by the agreement between GCC and GDB - and Clang/LLVM just tries to implement gnu_pub* to be as compatible as possible with that.

Was there any documentation on this where the contents of this new format are detailed?

Not that I know of.

Sounds promising and I would love to have LLDB to not have to manually index DWARF on all linux/android targets if at all possible.

Presumably LLDB should probably be looking at the newer .debug_names format that's been standardized/documented, and derived from the apple names accelerator tables.

[clayborg]

In D82367#3135210, @dblaikie wrote:

In D82367#3133152, @clayborg wrote:

In D82367#3133132, @dblaikie wrote:

In D82367#3133081, @clayborg wrote:

Is ".debug_gnu_pubtypes" different and/or better than the old ".debug_pubtypes" in terms of contents? AFAIK all debuggers completely ignore these sections as they don't contain all types (only public types). I did a quick web search for ".debug_gnu_pubtypes" and didn't find any docs or anything documenting this format.

My general understanding is that GCC/GDB folks implemented .debug_gnu_pubnames(/types) because of the lack of guarantees in debug_pubnames(/types) - GCC does consume/rely on these sections (& gold can produce .gdb_index from these gnu_pub* sections - which is /necessary/ for correctness of gdb when using Split DWARF, in fact).

I'm guessing like lots of stuff, it's probably basically defined by the agreement between GCC and GDB - and Clang/LLVM just tries to implement gnu_pub* to be as compatible as possible with that.

Was there any documentation on this where the contents of this new format are detailed?

Not that I know of.

Sounds promising and I would love to have LLDB to not have to manually index DWARF on all linux/android targets if at all possible.

Presumably LLDB should probably be looking at the newer .debug_names format that's been standardized/documented, and derived from the apple names accelerator tables.

We have support already and we do look at that. Not many compilers enable DWARF5 at the moment, so we rarely see the .debug_names in any binaries, but LLDB is ready for these. It is hard to control and change the toolchains that people build with. My idea was to write a post processing tool that can add the .debug_names to binaries, like maybe llvm-objcopy or other tool.

[dblaikie]

In D82367#3135300, @clayborg wrote:

In D82367#3135210, @dblaikie wrote:

In D82367#3133152, @clayborg wrote:

In D82367#3133132, @dblaikie wrote:

In D82367#3133081, @clayborg wrote:

Is ".debug_gnu_pubtypes" different and/or better than the old ".debug_pubtypes" in terms of contents? AFAIK all debuggers completely ignore these sections as they don't contain all types (only public types). I did a quick web search for ".debug_gnu_pubtypes" and didn't find any docs or anything documenting this format.

My general understanding is that GCC/GDB folks implemented .debug_gnu_pubnames(/types) because of the lack of guarantees in debug_pubnames(/types) - GCC does consume/rely on these sections (& gold can produce .gdb_index from these gnu_pub* sections - which is /necessary/ for correctness of gdb when using Split DWARF, in fact).

I'm guessing like lots of stuff, it's probably basically defined by the agreement between GCC and GDB - and Clang/LLVM just tries to implement gnu_pub* to be as compatible as possible with that.

Was there any documentation on this where the contents of this new format are detailed?

Not that I know of.

Sounds promising and I would love to have LLDB to not have to manually index DWARF on all linux/android targets if at all possible.

Presumably LLDB should probably be looking at the newer .debug_names format that's been standardized/documented, and derived from the apple names accelerator tables.

We have support already and we do look at that. Not many compilers enable DWARF5 at the moment, so we rarely see the .debug_names in any binaries, but LLDB is ready for these. It is hard to control and change the toolchains that people build with. My idea was to write a post processing tool that can add the .debug_names to binaries, like maybe llvm-objcopy or other tool.

Yep, a post-processing tool to add .debug_names could be nice. Given folks have to add extra flags to get gnu (or non-gnu) pubnames (-ggnu-pubnames in both GCC and Clang) with GCC and Clang - they could instead switch to DWARFv5 "just as easily" (not quite, but close) - though certainly the ecosystem issues if they need to support tools that can't consume DWARFv5, etc. (perhaps .debug_names could be supported in pre-v5 modes as a backwards/partial compatibility mode - rather than having to produce gnu_pubnames)

Though producing gnu_pubnames/plain pubnames and linking those into .debug_names in the linker wouldn't be a bad thing to support either (though maybe has the problem of "this doesn't have all the names it needs to have" which is the general problem with all this).

llvm/lib/ObjectYAML/DWARFYAML.cpp

SetVector<StringRef> DWARFYAML::Data::getUsedSectionNames() const {
   if (!DebugLines.empty())
     SecNames.insert("debug_line");
   if (!DebugAddr.empty())
     SecNames.insert("debug_addr");
   if (!AbbrevDecls.empty())
     SecNames.insert("debug_abbrev");
   if (!CompileUnits.empty())
     SecNames.insert("debug_info");
+  if (GNUPubNames)
+    SecNames.insert("debug_gnu_pubnames");
+  if (GNUPubTypes)
+    SecNames.insert("debug_gnu_pubtypes");
   return SecNames;
 }
 
 namespace yaml {
 
 void MappingTraits<DWARFYAML::Data>::mapping(IO &IO, DWARFYAML::Data &DWARF) {
   auto oldContext = IO.getContext();
   IO.setContext(&DWARF);
void MappingTraits<DWARFYAML::Ranges>::mapping(IO &IO,
   IO.mapOptional("Offset", DebugRanges.Offset);
   IO.mapOptional("AddrSize", DebugRanges.AddrSize);
   IO.mapRequired("Entries", DebugRanges.Entries);
 }
 
 void MappingTraits<DWARFYAML::PubEntry>::mapping(IO &IO,
                                                  DWARFYAML::PubEntry &Entry) {
   IO.mapRequired("DieOffset", Entry.DieOffset);
+  // FIXME: 'Descriptor' cannot be mapped into Entry.Descriptor
+  // since the context is missing.
   if (reinterpret_cast<DWARFYAML::PubSection *>(IO.getContext())->IsGNUStyle)
     IO.mapRequired("Descriptor", Entry.Descriptor);
   IO.mapRequired("Name", Entry.Name);
 }
 
 void MappingTraits<DWARFYAML::PubSection>::mapping(
     IO &IO, DWARFYAML::PubSection &Section) {
   auto OldContext = IO.getContext();

llvm/lib/ObjectYAML/ELFEmitter.cpp

Expected<uint64_t> emitDWARF(typename ELFT::Shdr &SHeader, StringRef Name,
   else if (Name == ".debug_line")
     Err = DWARFYAML::emitDebugLine(*OS, DWARF);
   else if (Name == ".debug_addr")
     Err = DWARFYAML::emitDebugAddr(*OS, DWARF);
   else if (Name == ".debug_abbrev")
     Err = DWARFYAML::emitDebugAbbrev(*OS, DWARF);
   else if (Name == ".debug_info")
     Err = DWARFYAML::emitDebugInfo(*OS, DWARF);
+  else if (Name == ".debug_gnu_pubnames")
+    Err = DWARFYAML::emitPubSection(*OS, *DWARF.GNUPubNames,
+                                    DWARF.IsLittleEndian);
+  else if (Name == ".debug_gnu_pubtypes")
+    Err = DWARFYAML::emitPubSection(*OS, *DWARF.GNUPubTypes,
+                                    DWARF.IsLittleEndian);
   else
     llvm_unreachable("unexpected emitDWARF() call");
 
   if (Err)
     return std::move(Err);
 
   return CBA.tell() - BeginOffset;
 }

llvm/test/tools/yaml2obj/ELF/DWARF/debug-gnu-pubnames.yaml

+## Test that yaml2obj emits .debug_gnu_pubnames section.
+
+## a) Generate the '.debug_gnu_pubnames' section from the 'DWARF' entry.
+
+## Generate and verify a 32-bit little endian .debug_gnu_pubnames section.
+
+# RUN: yaml2obj --docnum=1 -DENDIAN=ELFDATA2LSB %s -o %t1.le.o
+# RUN: llvm-readobj --sections --section-data %t1.le.o | \
+# RUN:   FileCheck -DSIZE=30 -DADDRALIGN=1 %s --check-prefixes=SHDR,DWARF32-LE
+
+#            SHDR: Index: 1
+#       SHDR-NEXT: Name: .debug_gnu_pubnames (1)
+#       SHDR-NEXT: Type: SHT_PROGBITS (0x1)
+#       SHDR-NEXT: Flags [ (0x0)
+#       SHDR-NEXT: ]
+#       SHDR-NEXT: Address: 0x0
+#       SHDR-NEXT: Offset: 0x40
+#       SHDR-NEXT: Size: [[SIZE]]
+#       SHDR-NEXT: Link: 0
+#       SHDR-NEXT: Info: 0
+#       SHDR-NEXT: AddressAlignment: [[ADDRALIGN]]
+#       SHDR-NEXT: EntrySize: 0
+# DWARF32-LE-NEXT: SectionData (
+# DWARF32-LE-NEXT:   0000: 34120000 02003412 00002143 00007856 |4.....4...!C..xV|
+##                         ^-------                            unit_length (4-byte)
+##                                  ^---                       version (2-byte)
+##                                      ^--------              debug_info_offset (4-byte)
+##                                               ^--------     debug_info_length (4-byte)
+##                                                        ^--- offset (4-byte)
+##
+# DWARF32-LE-NEXT:   0010: 34126162 63002143 65876465 6600     |4.abc.!Ce.def.|
+##                         ----
+##                             ^--------                       name "abc\0"
+##                                      ^--------              offset (4-byte)
+##                                               ^--------     name "def\0"
+# DWARF32-LE-NEXT: )
+
+--- !ELF
+FileHeader:
+  Class:   ELFCLASS64
+  Data:    [[ENDIAN]]
+  Type:    ET_EXEC
+  Machine: EM_X86_64
+DWARF:
+  debug_gnu_pubnames:
+    Length:
+      TotalLength: 0x1234
+    Version:    2
+    UnitOffset: 0x1234
+    UnitSize:   0x4321
+    Entries:
+      - DieOffset: 0x12345678
+        Name:      abc
+      - DieOffset: 0x87654321
+        Name:      def
+
+## Generate and verify a 32-bit big endian .debug_gnu_pubnames section.
+
+# RUN: yaml2obj --docnum=1 -DENDIAN=ELFDATA2MSB %s -o %t1.be.o
+# RUN: llvm-readobj --sections --section-data %t1.be.o | \
+# RUN:   FileCheck -DSIZE=30 -DADDRALIGN=1 %s --check-prefixes=SHDR,DWARF32-BE
+
+# DWARF32-BE-NEXT: SectionData (
+# DWARF32-BE-NEXT:   0000: 00001234 00020000 12340000 43211234 |...4.....4..C!.4|
+##                         ^-------                            unit_length (4-byte)
+##                                  ^---                       version (2-byte)
+##                                      ^--------              debug_info_offset (4-byte)
+##                                               ^--------     debug_info_length (4-byte)
+##                                                        ^--- offset (4-byte)
+##
+# DWARF32-BE-NEXT:   0010: 56786162 63008765 43216465 6600     |Vxabc..eC!def.|
+##                         ----
+##                             ^--------                       name "abc\0"
+##                                      ^--------              offset (4-byte)
+##                                               ^--------     name "def\0"
+# DWARF32-BE-NEXT: )
+
+## b) Generate the .debug_gnu_pubnames section from raw section content.
+
+# RUN: yaml2obj --docnum=2 %s -o %t2.o
+# RUN: llvm-readobj --sections --section-data %t2.o | \
+# RUN:   FileCheck %s -DADDRALIGN=0 -DSIZE=3 --check-prefixes=SHDR,ARBITRARY-CONTENT
+
+#      ARBITRARY-CONTENT: SectionData (
+# ARBITRARY-CONTENT-NEXT:   0000: 112233
+# ARBITRARY-CONTENT-NEXT: )
+
+--- !ELF
+FileHeader:
+  Class:   ELFCLASS64
+  Data:    ELFDATA2LSB
+  Type:    ET_EXEC
+  Machine: EM_X86_64
+Sections:
+  - Name:    .debug_gnu_pubnames
+    Type:    SHT_PROGBITS
+    Content: "112233"
+
+## c) Generate the .debug_gnu_pubnames section when the "Size" is specified.
+
+# RUN: yaml2obj --docnum=3 %s -o %t3.o
+# RUN: llvm-readobj --sections --section-data %t3.o | \
+# RUN:   FileCheck -DSIZE=16 -DADDRALIGN=0 %s --check-prefixes=SHDR,SIZE
+
+#      SIZE: SectionData (
+# SIZE-NEXT:   0000: 00000000 00000000 00000000 00000000  |................|
+# SIZE-NEXT: )
+
+--- !ELF
+FileHeader:
+  Class:   ELFCLASS64
+  Data:    ELFDATA2LSB
+  Type:    ET_EXEC
+  Machine: EM_X86_64
+Sections:
+  - Name: .debug_gnu_pubnames
+    Type: SHT_PROGBITS
+    Size: 0x10
+
+## d) Test that yaml2obj emits an error message when both the "Size" and the
+## "debug_gnu_pubnames" entry are specified at the same time.
+
+# RUN: not yaml2obj --docnum=4 %s 2>&1 | FileCheck %s --check-prefix=ERROR
+
+# ERROR: yaml2obj: error: cannot specify section '.debug_gnu_pubnames' contents in the 'DWARF' entry and the 'Content' or 'Size' in the 'Sections' entry at the same time
+
+--- !ELF
+FileHeader:
+  Class:   ELFCLASS64
+  Data:    ELFDATA2LSB
+  Type:    ET_EXEC
+  Machine: EM_X86_64
+Sections:
+  - Name: .debug_gnu_pubnames
+    Type: SHT_PROGBITS
+    Size: 0x10
+DWARF:
+  debug_gnu_pubnames:
+    Length:
+      TotalLength: 0x1234
+    Version:    2
+    UnitOffset: 0x1234
+    UnitSize:   0x4321
+    Entries:    []
+
+## e) Test that yaml2obj emits an error message when both the "Content" and the
+## "debug_gnu_pubnames" entry are specified at the same time.
+
+# RUN: not yaml2obj --docnum=5 %s 2>&1 | FileCheck %s --check-prefix=ERROR
+
+--- !ELF
+FileHeader:
+  Class:   ELFCLASS64
+  Data:    ELFDATA2LSB
+  Type:    ET_EXEC
+  Machine: EM_X86_64
+Sections:
+  - Name:    .debug_gnu_pubnames
+    Type:    SHT_PROGBITS
+    Content: "00"
+DWARF:
+  debug_gnu_pubnames:
+    Length:
+      TotalLength: 0x1234
+    Version:    2
+    UnitOffset: 0x1234
+    UnitSize:   0x4321
+    Entries:    []
+
+## f) Test that all the properties can be overridden by the section header when
+## the "debug_gnu_pubnames" entry doesn't exist.
+
+# RUN: yaml2obj --docnum=6 %s -o %t6.o
+# RUN: llvm-readelf --sections %t6.o | FileCheck %s --check-prefix=OVERRIDDEN
+
+#      OVERRIDDEN: [Nr] Name                Type   Address          Off    Size   ES Flg Lk Inf Al
+#      OVERRIDDEN: [ 1] .debug_gnu_pubnames STRTAB 0000000000002020 000050 00000e 01   A  2   1  2
+# OVERRIDDEN-NEXT: [ 2] .sec                STRTAB 0000000000000000 00005e 000000 00      0   0  0
+
+--- !ELF
+FileHeader:
+  Class:   ELFCLASS64
+  Data:    ELFDATA2LSB
+  Type:    ET_EXEC
+  Machine: EM_X86_64
+Sections:
+  - Name:         .debug_gnu_pubnames
+    Type:         SHT_STRTAB  ## SHT_PROGBITS by default.
+    Flags:        [SHF_ALLOC] ## 0 by default.
+    Link:         .sec        ## 0 by default.
+    EntSize:      1           ## 0 by default.
+    Info:         1           ## 0 by default.
+    AddressAlign: 2           ## 0 by default.
+    Address:      0x2020      ## 0x00 by default.
+    Offset:       0x50        ## 0x40 for the first section.
+    Size:         0x0e        ## Set the "Size" so that we can reuse the check tag "OVERRIDDEN".
+  - Name:         .sec        ## Linked by .debug_gnu_pubnames.
+    Type:         SHT_STRTAB
+
+## g) Test that all the properties can be overridden by the section header when
+## the "debug_gnu_pubnames" entry exists.
+
+# RUN: yaml2obj --docnum=7 %s -o %t7.o
+# RUN: llvm-readelf --sections %t7.o | FileCheck %s --check-prefix=OVERRIDDEN
+
+--- !ELF
+FileHeader:
+  Class:   ELFCLASS64
+  Data:    ELFDATA2LSB
+  Type:    ET_EXEC
+  Machine: EM_X86_64
+Sections:
+  - Name:         .debug_gnu_pubnames
+    Type:         SHT_STRTAB  ## SHT_PROGBITS by default.
+    Flags:        [SHF_ALLOC] ## 0 by default.
+    Link:         .sec        ## 0 by default.
+    EntSize:      1           ## 0 by default.
+    Info:         1           ## 0 by default.
+    AddressAlign: 2           ## 1 by default.
+    Address:      0x2020      ## 0x00 by default.
+    Offset:       0x50        ## 0x40 for the first section.
+  - Name:         .sec        ## Linked by .debug_gnu_pubnames.
+    Type:         SHT_STRTAB
+DWARF:
+  debug_gnu_pubnames:
+    Length:
+      TotalLength: 0x1234
+    Version:    2
+    UnitOffset: 0x1234
+    UnitSize:   0x4321
+    Entries:    []

llvm/test/tools/yaml2obj/ELF/DWARF/debug-gnu-pubtypes.yaml

+## Test that yaml2obj emits .debug_gnu_pubtypes section.
+
+## a) Generate the '.debug_gnu_pubtypes' section from the 'DWARF' entry.
+
+## Generate and verify a 32-bit little endian .debug_gnu_pubtypes section.
+
+# RUN: yaml2obj --docnum=1 -DENDIAN=ELFDATA2LSB %s -o %t1.le.o
+# RUN: llvm-readobj --sections --section-data %t1.le.o | \
+# RUN:   FileCheck -DSIZE=30 -DADDRALIGN=1 %s --check-prefixes=SHDR,DWARF32-LE
+
+#            SHDR: Index: 1
+#       SHDR-NEXT: Name: .debug_gnu_pubtypes (1)
+#       SHDR-NEXT: Type: SHT_PROGBITS (0x1)
+#       SHDR-NEXT: Flags [ (0x0)
+#       SHDR-NEXT: ]
+#       SHDR-NEXT: Address: 0x0
+#       SHDR-NEXT: Offset: 0x40
+#       SHDR-NEXT: Size: [[SIZE]]
+#       SHDR-NEXT: Link: 0
+#       SHDR-NEXT: Info: 0
+#       SHDR-NEXT: AddressAlignment: [[ADDRALIGN]]
+#       SHDR-NEXT: EntrySize: 0
+# DWARF32-LE-NEXT: SectionData (
+# DWARF32-LE-NEXT:   0000: 34120000 02003412 00002143 00007856 |4.....4...!C..xV|
+##                         ^-------                            unit_length (4-byte)
+##                                  ^---                       version (2-byte)
+##                                      ^--------              debug_info_offset (4-byte)
+##                                               ^--------     debug_info_length (4-byte)
+##                                                        ^--- offset (4-byte)
+##
+# DWARF32-LE-NEXT:   0010: 34126162 63002143 65876465 6600     |4.abc.!Ce.def.|
+##                         ----
+##                             ^--------                       name "abc\0"
+##                                      ^--------              offset (4-byte)
+##                                               ^--------     name "def\0"
+# DWARF32-LE-NEXT: )
+
+--- !ELF
+FileHeader:
+  Class:   ELFCLASS64
+  Data:    [[ENDIAN]]
+  Type:    ET_EXEC
+  Machine: EM_X86_64
+DWARF:
+  debug_gnu_pubtypes:
+    Length:
+      TotalLength: 0x1234
+    Version:    2
+    UnitOffset: 0x1234
+    UnitSize:   0x4321
+    Entries:
+      - DieOffset: 0x12345678
+        Name:      abc
+      - DieOffset: 0x87654321
+        Name:      def
+
+## Generate and verify a 32-bit big endian .debug_gnu_pubtypes section.
+
+# RUN: yaml2obj --docnum=1 -DENDIAN=ELFDATA2MSB %s -o %t1.be.o
+# RUN: llvm-readobj --sections --section-data %t1.be.o | \
+# RUN:   FileCheck -DSIZE=30 -DADDRALIGN=1 %s --check-prefixes=SHDR,DWARF32-BE
+
+# DWARF32-BE-NEXT: SectionData (
+# DWARF32-BE-NEXT:   0000: 00001234 00020000 12340000 43211234 |...4.....4..C!.4|
+##                         ^-------                            unit_length (4-byte)
+##                                  ^---                       version (2-byte)
+##                                      ^--------              debug_info_offset (4-byte)
+##                                               ^--------     debug_info_length (4-byte)
+##                                                        ^--- offset (4-byte)
+##
+# DWARF32-BE-NEXT:   0010: 56786162 63008765 43216465 6600     |Vxabc..eC!def.|
+##                         ----
+##                             ^--------                       name "abc\0"
+##                                      ^--------              offset (4-byte)
+##                                               ^--------     name "def\0"
+# DWARF32-BE-NEXT: )
+
+## b) Generate the .debug_gnu_pubtypes section from raw section content.
+
+# RUN: yaml2obj --docnum=2 %s -o %t2.o
+# RUN: llvm-readobj --sections --section-data %t2.o | \
+# RUN:   FileCheck %s -DADDRALIGN=0 -DSIZE=3 --check-prefixes=SHDR,ARBITRARY-CONTENT
+
+#      ARBITRARY-CONTENT: SectionData (
+# ARBITRARY-CONTENT-NEXT:   0000: 112233
+# ARBITRARY-CONTENT-NEXT: )
+
+--- !ELF
+FileHeader:
+  Class:   ELFCLASS64
+  Data:    ELFDATA2LSB
+  Type:    ET_EXEC
+  Machine: EM_X86_64
+Sections:
+  - Name:    .debug_gnu_pubtypes
+    Type:    SHT_PROGBITS
+    Content: "112233"
+
+## c) Generate the .debug_gnu_pubtypes section when the "Size" is specified.
+
+# RUN: yaml2obj --docnum=3 %s -o %t3.o
+# RUN: llvm-readobj --sections --section-data %t3.o | \
+# RUN:   FileCheck -DSIZE=16 -DADDRALIGN=0 %s --check-prefixes=SHDR,SIZE
+
+#      SIZE: SectionData (
+# SIZE-NEXT:   0000: 00000000 00000000 00000000 00000000  |................|
+# SIZE-NEXT: )
+
+--- !ELF
+FileHeader:
+  Class:   ELFCLASS64
+  Data:    ELFDATA2LSB
+  Type:    ET_EXEC
+  Machine: EM_X86_64
+Sections:
+  - Name: .debug_gnu_pubtypes
+    Type: SHT_PROGBITS
+    Size: 0x10
+
+## d) Test that yaml2obj emits an error message when both the "Size" and the
+## "debug_gnu_pubtypes" entry are specified at the same time.
+
+# RUN: not yaml2obj --docnum=4 %s 2>&1 | FileCheck %s --check-prefix=ERROR
+
+# ERROR: yaml2obj: error: cannot specify section '.debug_gnu_pubtypes' contents in the 'DWARF' entry and the 'Content' or 'Size' in the 'Sections' entry at the same time
+
+--- !ELF
+FileHeader:
+  Class:   ELFCLASS64
+  Data:    ELFDATA2LSB
+  Type:    ET_EXEC
+  Machine: EM_X86_64
+Sections:
+  - Name: .debug_gnu_pubtypes
+    Type: SHT_PROGBITS
+    Size: 0x10
+DWARF:
+  debug_gnu_pubtypes:
+    Length:
+      TotalLength: 0x1234
+    Version:    2
+    UnitOffset: 0x1234
+    UnitSize:   0x4321
+    Entries:    []
+
+## e) Test that yaml2obj emits an error message when both the "Content" and the
+## "debug_gnu_pubtypes" entry are specified at the same time.
+
+# RUN: not yaml2obj --docnum=5 %s 2>&1 | FileCheck %s --check-prefix=ERROR
+
+--- !ELF
+FileHeader:
+  Class:   ELFCLASS64
+  Data:    ELFDATA2LSB
+  Type:    ET_EXEC
+  Machine: EM_X86_64
+Sections:
+  - Name:    .debug_gnu_pubtypes
+    Type:    SHT_PROGBITS
+    Content: "00"
+DWARF:
+  debug_gnu_pubtypes:
+    Length:
+      TotalLength: 0x1234
+    Version:    2
+    UnitOffset: 0x1234
+    UnitSize:   0x4321
+    Entries:    []
+
+## f) Test that all the properties can be overridden by the section header when
+## the "debug_gnu_pubtypes" entry doesn't exist.
+
+# RUN: yaml2obj --docnum=6 %s -o %t6.o
+# RUN: llvm-readelf --sections %t6.o | FileCheck %s --check-prefix=OVERRIDDEN
+
+#      OVERRIDDEN: [Nr] Name                Type   Address          Off    Size   ES Flg Lk Inf Al
+#      OVERRIDDEN: [ 1] .debug_gnu_pubtypes STRTAB 0000000000002020 000050 00000e 01   A  2   1  2
+# OVERRIDDEN-NEXT: [ 2] .sec                STRTAB 0000000000000000 00005e 000000 00      0   0  0
+
+--- !ELF
+FileHeader:
+  Class:   ELFCLASS64
+  Data:    ELFDATA2LSB
+  Type:    ET_EXEC
+  Machine: EM_X86_64
+Sections:
+  - Name:         .debug_gnu_pubtypes
+    Type:         SHT_STRTAB  ## SHT_PROGBITS by default.
+    Flags:        [SHF_ALLOC] ## 0 by default.
+    Link:         .sec        ## 0 by default.
+    EntSize:      1           ## 0 by default.
+    Info:         1           ## 0 by default.
+    AddressAlign: 2           ## 0 by default.
+    Address:      0x2020      ## 0x00 by default.
+    Offset:       0x50        ## 0x40 for the first section.
+    Size:         0x0e        ## Set the "Size" so that we can reuse the check tag "OVERRIDDEN".
+  - Name:         .sec        ## Linked by .debug_gnu_pubtypes.
+    Type:         SHT_STRTAB
+
+## g) Test that all the properties can be overridden by the section header when
+## the "debug_gnu_pubtypes" entry exists.
+
+# RUN: yaml2obj --docnum=7 %s -o %t7.o
+# RUN: llvm-readelf --sections %t7.o | FileCheck %s --check-prefix=OVERRIDDEN
+
+--- !ELF
+FileHeader:
+  Class:   ELFCLASS64
+  Data:    ELFDATA2LSB
+  Type:    ET_EXEC
+  Machine: EM_X86_64
+Sections:
+  - Name:         .debug_gnu_pubtypes
+    Type:         SHT_STRTAB  ## SHT_PROGBITS by default.
+    Flags:        [SHF_ALLOC] ## 0 by default.
+    Link:         .sec        ## 0 by default.
+    EntSize:      1           ## 0 by default.
+    Info:         1           ## 0 by default.
+    AddressAlign: 2           ## 1 by default.
+    Address:      0x2020      ## 0x00 by default.
+    Offset:       0x50        ## 0x40 for the first section.
+  - Name:         .sec        ## Linked by .debug_gnu_pubtypes.
+    Type:         SHT_STRTAB
+DWARF:
+  debug_gnu_pubtypes:
+    Length:
+      TotalLength: 0x1234
+    Version:    2
+    UnitOffset: 0x1234
+    UnitSize:   0x4321
+    Entries:    []