[obj2yaml,yaml2obj] - Read and dump the "Content" key of the RawContentSection section as array.

[grimar]

Summary

For all of custom sections we have we use Optional<yaml::BinaryRef> for
describing Content. A BinaryRef is a specialized YAMLIO scalar type for
representing a binary blob. Because of this we dump a content as a single string.

This string is dumped in a one line and there is no way to split it and
add proper comments for each part.
I was asked today about possibility of writing a custom
number of bytes and commenting the each group of them. It is useful for
crafting new types of sections.

I was surprised that we unable to do something like:

## Comment 0.
Content: [ 0xfe, 0xfe, 0xfe, 0xfe,
## Comment 1.
0xfe, 0xfe,
## Comment 2.
0xfe, 0xfe ]

In this patch I did a change for RawContentSection for start,
now it accepts and prints the vector of bytes for a Content which
is now Optional<std::vector<uint8_t>>.
How does the idea of such change sound?

[MaskRay]

Just wanted to flag up a concern: "feff" -> [ 0xFE, 0xFF ] can make an opaque section content longer.

## Comment 1.
0xfe, 0xfe,
## Comment 2.
0xfe, 0xfe ]

Sometimes there may be a need to describe a little-endian 32-bit value, for example. Is the proposal to use 0x01, 0x00, 0x00, 0x00 for a little-endian 1?

~180 tests in test/tools/llvm-{objcopy,xray,objdump,elfabi,ar,dwarfdump} test/Object test/DebugInfo lld/test/ELF need an update, too. If we support both "0001" and [ 0x00, 0x01 ], we don't have to update those tests.

[grimar]

In D75123#1891658, @MaskRay wrote:

Just wanted to flag up a concern: "feff" -> [ 0xFE, 0xFF ] can make an opaque section content longer.

## Comment 1.
0xfe, 0xfe,
## Comment 2.
0xfe, 0xfe ]

Sometimes there may be a need to describe a little-endian 32-bit value, for example. Is the proposal to use 0x01, 0x00, 0x00, 0x00 for a little-endian 1?

Currently you can do:

---- !ELF
FileHeader:
  Class:   ELFCLASS32
  Data:    ELFDATA2MSB
  Type:    ET_REL
  Machine: EM_386
Sections:
  - Name: .foo
    Type: SHT_PROGBITS
    Content: "01000000"

It does not matter if you use ELFDATA2MSB or ELFDATA2LSB. The output will be the same:

SectionData (
  0000: 01000000 
)

And the same happens when this patch is used with Content: [ 0x01, 0x00, 0x00, 0x00 ]:
we have the same result with LSB/MSB, so nothing really changed here.

~180 tests in test/tools/llvm-{objcopy,xray,objdump,elfabi,ar,dwarfdump} test/Object test/DebugInfo lld/test/ELF need an update, too.

Hmm that's right, thanks for spotting. Seems I was too focused in yaml2obj/obj2yaml tests and forgot to run others. I am OK to update them though.

If we support both "0001" and [ 0x00, 0x01 ], we don't have to update those tests.

I see next problems here:

1. I am not sure how to make yaml2obj and obj2yaml to support both ways. Perhaps it is possible, I need to investigate how much hard to do this. But anyways it should be more complicated than the current approach, which is trivial. I.e. I'd like to be sure we want to try to go this way before I actually try.
2. What should be the default output for obj2yaml? Should it print [ 0x00, 0x01 ]? Then people will probably often use the output from obj2yaml as a sample and will ignore "0011" form probably. Also "0011" form does not allow to use large peice of a content nicely as it prints it in a single line and makes almost improssible to comment those bytes properly.
3. Using large chunk of raw bytes is a bad practice. Should we care much about keeping a shorter way to describe it?

[grimar]

This need an update for the rest of test cases + I'd like to wait for the result of the discussion in this thread before doing anything.

[jhenderson]

In D75123#1892941, @grimar wrote:

3. Using large chunk of raw bytes is a bad practice. Should we care much about keeping a shorter way to describe it?

I think this is the key question to me. We shouldn't be encouraging large binary blobs, and if we get a situation where one is needed, perhaps the test needs simplifying/converting to assembly, or obj2yaml/yaml2obj needs extending. In other words, I don't think this change is particularly useful, as blobs should be kept to very short amounts (circa 32 bytes I reckon at most).

[MaskRay]

How about the following plan?

1. This patch: supporting both [0,1] and "3031" (hex pairs) in yaml2obj. Support [0x00, 0x01] in obj2yaml. Only obj2yaml tests need to be updated. There are only a few.
2. A future change: change "3031" (hex pairs) to "01" (strings) in yaml2obj. ~180 tests need to be migrated. This can probably be done mechanically with a dedicated tool.

[grimar]

In D75123#1896131, @MaskRay wrote:

How about the following plan?

1. This patch: supporting both [0,1] and "3031" (hex pairs) in yaml2obj. Support [0x00, 0x01] in obj2yaml. Only obj2yaml tests need to be updated. There are only a few.
2. A future change: change "3031" (hex pairs) to "01" (strings) in yaml2obj. ~180 tests need to be migrated. This can probably be done mechanically with a dedicated tool.

I did not understand it I think.
Currectly we support hex pairs, like "00112233". This patch suggests "[0x00, 0x01]" instead. Not sure I understand what do you mean by "strings" in (2)? I.e. what is the difference with "pairs" we have?

[jhenderson]

In D75123#1897411, @grimar wrote:

In D75123#1896131, @MaskRay wrote:

How about the following plan?

1. This patch: supporting both [0,1] and "3031" (hex pairs) in yaml2obj. Support [0x00, 0x01] in obj2yaml. Only obj2yaml tests need to be updated. There are only a few.
2. A future change: change "3031" (hex pairs) to "01" (strings) in yaml2obj. ~180 tests need to be migrated. This can probably be done mechanically with a dedicated tool.

I did not understand it I think.
Currectly we support hex pairs, like "00112233". This patch suggests "[0x00, 0x01]" instead. Not sure I understand what do you mean by "strings" in (2)? I.e. what is the difference with "pairs" we have?

I might be completely misreading this, but i think @MaskRay is suggesting to get something like the string "foo" in a string table, for example, writing literally that instead of 666f6f.

[grimar]

In D75123#1897567, @jhenderson wrote:

In D75123#1897411, @grimar wrote:

In D75123#1896131, @MaskRay wrote:

How about the following plan?

1. This patch: supporting both [0,1] and "3031" (hex pairs) in yaml2obj. Support [0x00, 0x01] in obj2yaml. Only obj2yaml tests need to be updated. There are only a few.
2. A future change: change "3031" (hex pairs) to "01" (strings) in yaml2obj. ~180 tests need to be migrated. This can probably be done mechanically with a dedicated tool.

I did not understand it I think.
Currectly we support hex pairs, like "00112233". This patch suggests "[0x00, 0x01]" instead. Not sure I understand what do you mean by "strings" in (2)? I.e. what is the difference with "pairs" we have?

I might be completely misreading this, but i think @MaskRay is suggesting to get something like the string "foo" in a string table, for example, writing literally that instead of 666f6f.

Looks true. I did not get that 0x30 is 1 and 0x31 is 2 from ASCII.
(And it is very far from what this patch initially suggested.)

I am not sure why we might want strings. Usually we describe a binary context of
sections isn't? e,g. custom symbol tables, custom text sections (with broken instructions) for broken test cases etc.

[grimar]

In D75123#1895005, @jhenderson wrote:

In D75123#1892941, @grimar wrote:

3. Using large chunk of raw bytes is a bad practice. Should we care much about keeping a shorter way to describe it?

I think this is the key question to me. We shouldn't be encouraging large binary blobs, and if we get a situation where one is needed, perhaps the test needs simplifying/converting to assembly, or obj2yaml/yaml2obj needs extending. In other words, I don't think this change is particularly useful, as blobs should be kept to very short amounts (circa 32 bytes I reckon at most).

There are cases where using yaml2obj is preferable over llvm-mc, but you may have blobs that are not little. Imagine you prototype a new section and want to write a test
for a dumper tool for example. It is not always reasonable to teach yaml2obj about a new section type. So you still might want to use Content, but want to comment bytes well.
It is currently impossible to split Content data to leave multi-line comments.

An idea:
What if we introduce a one more YAML key: "ContentBytes"? I.e. we keep Optional<yaml::BinaryRef> Content as is,
but also add Optional<std::vector<uint8_t>> ContentBytes for those who would like to comment group of bytes
and use [ 0x1, 0x2 ] style for whatever reason is.

[jhenderson]

In D75123#1897851, @grimar wrote:

There are cases where using yaml2obj is preferable over llvm-mc, but you may have blobs that are not little. Imagine you prototype a new section and want to write a test
for a dumper tool for example. It is not always reasonable to teach yaml2obj about a new section type. So you still might want to use Content, but want to comment bytes well.
It is currently impossible to split Content data to leave multi-line comments.

FWIW, I actually disagree with the statement that it is not always reasonable to teach yaml2obj about a new section type. I think if a binary blob is large enough that it needs commenting, it should be added to yaml2obj instead.

That being said, I could imagine a limited set of cases involving malformed inputs where even if the section is implemented in yaml2obj, you might need to use raw Content.

An idea:
What if we introduce a one more YAML key: "ContentBytes"? I.e. we keep Optional<yaml::BinaryRef> Content as is,
but also add Optional<std::vector<uint8_t>> ContentBytes for those who would like to comment group of bytes
and use [ 0x1, 0x2 ] style for whatever reason is.

This could possibly work, but I suspect people might be confused as to when to use one instead of the other. We probably need to update the yaml2obj/obj2yaml documentation. I might also suggest ContentArray as a name instead perhaps?

[MaskRay]

In D75123#1897585, @grimar wrote:

I am not sure why we might want strings. Usually we describe a binary context of
sections isn't? e,g. custom symbol tables, custom text sections (with broken instructions) for broken test cases etc.

I just feel that the current "3031" (hex pairs) representation is not conventional. C string literals may meet users' intuition.

In D75123#1900469, @jhenderson wrote:

In D75123#1897851, @grimar wrote:

There are cases where using yaml2obj is preferable over llvm-mc, but you may have blobs that are not little. Imagine you prototype a new section and want to write a test
for a dumper tool for example. It is not always reasonable to teach yaml2obj about a new section type. So you still might want to use Content, but want to comment bytes well.
It is currently impossible to split Content data to leave multi-line comments.

FWIW, I actually disagree with the statement that it is not always reasonable to teach yaml2obj about a new section type. I think if a binary blob is large enough that it needs commenting, it should be added to yaml2obj instead.

That being said, I could imagine a limited set of cases involving malformed inputs where even if the section is implemented in yaml2obj, you might need to use raw Content.

An idea:
What if we introduce a one more YAML key: "ContentBytes"? I.e. we keep Optional<yaml::BinaryRef> Content as is,
but also add Optional<std::vector<uint8_t>> ContentBytes for those who would like to comment group of bytes
and use [ 0x1, 0x2 ] style for whatever reason is.

This could possibly work, but I suspect people might be confused as to when to use one instead of the other. We probably need to update the yaml2obj/obj2yaml documentation. I might also suggest ContentArray as a name instead perhaps?

I don't have a strong opinion. ContentArray looks fine. obj2yaml does not know the nature of the content (strings or blob), should it continue dumping to Content by default? (I'll vote for yes; no strong opinion) If yes, ContentArray will be a key only known by yaml2obj.

[grimar]

In D75123#1901346, @MaskRay wrote:

This could possibly work, but I suspect people might be confused as to when to use one instead of the other. We probably need to update the yaml2obj/obj2yaml documentation. I might also suggest ContentArray as a name instead perhaps?

I don't have a strong opinion. ContentArray looks fine. obj2yaml does not know the nature of the content (strings or blob), should it continue dumping to Content by default? (I'll vote for yes; no strong opinion) If yes, ContentArray will be a key only known by yaml2obj.

Yeah, I'd leave it only known by yaml2obj and continue dumping to Content.

[grimar]

I've posted D82366 instead.

llvm/include/llvm/ObjectYAML/ELFYAML.h

struct DynamicSection : Section {
   Optional<yaml::BinaryRef> Content;
 
   DynamicSection() : Section(ChunkKind::Dynamic) {}
 
   static bool classof(const Chunk *S) { return S->Kind == ChunkKind::Dynamic; }
 };
 
 struct RawContentSection : Section {
-  Optional<yaml::BinaryRef> Content;
+  Optional<std::vector<uint8_t>> Content;
   Optional<llvm::yaml::Hex64> Size;
   Optional<llvm::yaml::Hex64> Info;
 
   RawContentSection() : Section(ChunkKind::RawContent) {}
 
   static bool classof(const Chunk *S) {
     return S->Kind == ChunkKind::RawContent;
   }

llvm/lib/ObjectYAML/ELFEmitter.cpp

static uint64_t writeContent(raw_ostream &OS,
 
   if (!Size)
     return ContentSize;
 
   OS.write_zeros(*Size - ContentSize);
   return *Size;
 }
 
+static uint64_t writeContent(raw_ostream &OS,
+                             const Optional<std::vector<uint8_t>> &Content,
+                             const Optional<llvm::yaml::Hex64> &Size) {
+  size_t ContentSize = 0;
+  if (Content) {
+    OS.write((const char *)Content->data(), Content->size());
+    ContentSize = Content->size();
+  }
+
+  if (!Size)
+    return ContentSize;
+
+  OS.write_zeros(*Size - ContentSize);
+  return *Size;
+}
+
 template <class ELFT>
 std::vector<typename ELFT::Sym>
 ELFState<ELFT>::toELFSymbols(ArrayRef<ELFYAML::Symbol> Symbols,
                              const StringTableBuilder &Strtab) {
   std::vector<Elf_Sym> Ret;
   Ret.resize(Symbols.size() + 1);
 
   size_t I = 0;

llvm/lib/ObjectYAML/ELFYAML.cpp

else
       sectionMapping(IO, *cast<ELFYAML::StackSizesSection>(Section.get()));
   }
 }
 
 StringRef MappingTraits<std::unique_ptr<ELFYAML::Chunk>>::validate(
     IO &io, std::unique_ptr<ELFYAML::Chunk> &C) {
   if (const auto *RawSection = dyn_cast<ELFYAML::RawContentSection>(C.get())) {
     if (RawSection->Size && RawSection->Content &&
-        (uint64_t)(*RawSection->Size) < RawSection->Content->binary_size())
+        (uint64_t)(*RawSection->Size) < RawSection->Content->size())
       return "Section size must be greater than or equal to the content size";
     if (RawSection->Flags && RawSection->ShFlags)
       return "ShFlags and Flags cannot be used together";
     return {};
   }
 
   if (const auto *SS = dyn_cast<ELFYAML::StackSizesSection>(C.get())) {
     if (!SS->Entries && !SS->Content && !SS->Size)

llvm/test/tools/obj2yaml/elf-null-section.yaml

 # SECOND-SEC-NEXT:   - Name:         .foo
 # SECOND-SEC-NEXT:     Type:         SHT_PROGBITS
 # SECOND-SEC-NEXT:   - Type:         SHT_NULL
 # SECOND-SEC-NEXT:     Flags:        [ SHF_ALLOC ]
 # SECOND-SEC-NEXT:     Address:      0x0000000000000006
 # SECOND-SEC-NEXT:     Link:         .foo
 # SECOND-SEC-NEXT:     AddressAlign: 0x0000000000000003
 # SECOND-SEC-NEXT:     EntSize:      0x0000000000000005
-# SECOND-SEC-NEXT:     Content:      '00000000'
+# SECOND-SEC-NEXT:     Content:      [ 0, 0, 0, 0 ]
 # SECOND-SEC-NEXT:     Info:         0x0000000000000002
 # SECOND-SEC-NEXT: ...
 
 --- !ELF
 FileHeader:
   Class:   ELFCLASS64
   Data:    ELFDATA2LSB
   Type:    ET_REL

llvm/test/tools/obj2yaml/invalid-section-name.yaml

FileHeader:
   Data:    ELFDATA2LSB
   Type:    ET_REL
   Machine: EM_X86_64
 Sections:
   - Name: foo
     Type: SHT_PROGBITS
   - Name: .shstrtab
     Type: SHT_STRTAB
-    Content: "00FEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFE00"
+    Content: [ 0x00, 0xFE, 0xFE, 0xFE, 0xFE, 0xFE, 0xFE, 0xFE, 0xFE,
+               0xFE, 0xFE, 0xFE, 0xFE, 0xFE, 0xFE, 0xFE, 0xFE, 0xFE,
+               0xFE, 0xFE, 0xFE, 0xFE, 0xFE, 0xFE, 0xFE, 0xFE, 0xFE,
+               0xFE, 0xFE, 0xFE, 0xFE, 0x00 ]

llvm/test/tools/yaml2obj/ELF/custom-fill.yaml

FileHeader:
   Type:    ET_DYN
   Machine: EM_X86_64
 Sections:
   - Type:    Fill
     Pattern: "AABB"
     Size:    0x3
   - Name:    .foo
     Type:    SHT_PROGBITS
-    Content: "1122"
+    Content: [ 0x11, 0x22 ]
   - Type:    Fill
     Name:    unusedName
     Pattern: "CCDD"
     Size:    4
   - Name:    .bar
     Type:    SHT_PROGBITS
-    Content: "FF"
+    Content: [ 0xFF ]
   - Type:    Fill
     Pattern: "EE"
     Size:    1
 
 ## Check we can have no explicit regular sections in the YAML description, and can
 ## describe the content with the use of fills only.
 ## Check that "Size" can be less than the pattern data size.
 

llvm/test/tools/yaml2obj/ELF/dynsymtab-implicit-sections-size-content.yaml

 FileHeader:
   Class:   ELFCLASS64
   Data:    ELFDATA2LSB
   Type:    ET_DYN
   Machine: EM_X86_64
 Sections:
   - Name:    .dynsym
     Type:    SHT_DYNSYM
-    Content: "00"
+    Content: [ 0x0 ]
   - Name:    .dynsym2
     Type:    SHT_DYNSYM
-    Content: "00"
+    Content: [ 0x0 ]
 DynamicSymbols:
   - Name:    foo
     Binding: STB_GLOBAL
 
 --- !ELF
 FileHeader:
   Class:   ELFCLASS64
   Data:    ELFDATA2LSB
   Type:    ET_DYN
   Machine: EM_X86_64
 Sections:
   - Name:    .dynsym
     Type:    SHT_DYNSYM
-    Content: "00"
+    Content: [ 0x0 ]
   - Name:    .dynsym2
     Type:    SHT_DYNSYM
-    Content: "00"
+    Content: [ 0x0 ]
 DynamicSymbols: []
 
 ## Check we can use just `Content` to emit custom data in the symbol table section.
 # RUN: yaml2obj --docnum=6 %s -o %t4
 # RUN: llvm-readobj --section-data -S %t4 | FileCheck %s --check-prefix=CASE4
 
 # CASE4:      Name: .dynsym
 # CASE4-NEXT: Type: SHT_DYNSYM

 FileHeader:
   Class:   ELFCLASS64
   Data:    ELFDATA2LSB
   Type:    ET_DYN
   Machine: EM_X86_64
 Sections:
   - Name: .dynsym
     Type: SHT_DYNSYM
-    Content: "0123"
+    Content: [ 0x01, 0x23 ]
 
 ## Check we can use just `Size` to emit custom data filled with zeroes
 ## in the symbol table section.
 # RUN: yaml2obj --docnum=7 %s -o %t5
 # RUN: llvm-readobj --section-data -S %t5 | FileCheck %s --check-prefix=CASE5
 
 # CASE5:      Name: .dynsym
 # CASE5-NEXT: Type: SHT_DYNSYM

 FileHeader:
   Class:   ELFCLASS64
   Data:    ELFDATA2LSB
   Type:    ET_DYN
   Machine: EM_X86_64
 Sections:
   - Name: .dynsym
     Type: SHT_DYNSYM
-    Content: "0123"
+    Content: [ 0x01, 0x23 ]
     Size: 4
 
 ## Check we can specify both `Size` and `Content` when size is
 ## equal to content size.
 
 # RUN: yaml2obj --docnum=9 %s -o %t7
 # RUN: llvm-readobj --section-data -S %t7 | FileCheck %s --check-prefix=CASE7
 

 FileHeader:
   Class:   ELFCLASS64
   Data:    ELFDATA2LSB
   Type:    ET_DYN
   Machine: EM_X86_64
 Sections:
   - Name: .dynsym
     Type: SHT_DYNSYM
-    Content: "0123"
+    Content: [ 0x01, 0x23 ]
     Size: 2

llvm/test/tools/yaml2obj/ELF/ent-size.yaml

 # RUN: yaml2obj %s -o %t
 # RUN: llvm-readobj --sections %t | FileCheck %s
 
 !ELF
 FileHeader:
   Class:           ELFCLASS64
   Data:            ELFDATA2LSB
   OSABI:           ELFOSABI_FREEBSD
   Type:            ET_REL
   Machine:         EM_X86_64
 Sections:
   - Type:            SHT_PROGBITS
     Name:            .strings
     Flags:           [ SHF_ALLOC, SHF_MERGE, SHF_STRINGS ]
     AddressAlign:    0x04
-    Content:         "FFFFFFFFFFFFFFFF"
+    Content:         [ 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF ]
     EntSize:         0x1
   - Name:            .mydynamic
     Type:            SHT_DYNAMIC
     EntSize:         0x0
 
 
 ## Check we were able to set entry size for .strings and .mydynamic
 # CHECK:       Name: .strings

llvm/test/tools/yaml2obj/ELF/override-shoffset.yaml

 FileHeader:
   Class:   ELFCLASS64
   Data:    ELFDATA2LSB
   Type:    ET_REL
   Machine: EM_X86_64
 Sections:
   - Name: .foo
     Type: SHT_PROGBITS
-    Content: "fefefefefefefefe"
+    Content: [ 0xfe, 0xfe, 0xfe, 0xfe, 0xfe, 0xfe, 0xfe, 0xfe ]
 
 --- !ELF
 FileHeader:
   Class:   ELFCLASS64
   Data:    ELFDATA2LSB
   Type:    ET_REL
   Machine: EM_X86_64
 Sections:
   - Name: .foo
     Type: SHT_PROGBITS
     ShOffset: 0xFFFF0000
-    Content: "fefefefefefefefe"
+    Content: [ 0xfe, 0xfe, 0xfe, 0xfe, 0xfe, 0xfe, 0xfe, 0xfe ]

llvm/test/tools/yaml2obj/ELF/override-shsize.yaml

 FileHeader:
   Class:   ELFCLASS64
   Data:    ELFDATA2LSB
   Type:    ET_REL
   Machine: EM_X86_64
 Sections:
   - Name: .foo
     Type: SHT_PROGBITS
-    Content: "fefefefefefefefe"
+    Content: [ 0xfe, 0xfe, 0xfe, 0xfe, 0xfe, 0xfe, 0xfe, 0xfe ]
 
 --- !ELF
 FileHeader:
   Class:   ELFCLASS64
   Data:    ELFDATA2LSB
   Type:    ET_REL
   Machine: EM_X86_64
 Sections:
   - Name: .foo
     Type: SHT_PROGBITS
     ShSize: 1
-    Content: "fefefefefefefefe"
+    Content: [ 0xfe, 0xfe, 0xfe, 0xfe, 0xfe, 0xfe, 0xfe, 0xfe ]
 
 ## Check we can define sh_size larger than section content size
 ## and thus create overlaping sections.
 
 # RUN: yaml2obj --docnum=4 %s -o %t4
 # RUN: llvm-readobj --sections --section-data %t4 | FileCheck %s --check-prefix=CASE4
 
 # CASE4:      Name: .foo
 # CASE4:      SectionData (
 # CASE4-NEXT: 0000: AAAABBBB |....|
 # CASE4:      Name: .bar
 # CASE4:      SectionData (
 # CASE4-NEXT: 0000: BBBB |..|
 
 --- !ELF
 FileHeader:
   Class:   ELFCLASS64
   Data:    ELFDATA2LSB
   Type:    ET_REL
   Machine: EM_X86_64
 Sections:
   - Name: .foo
     Type: SHT_PROGBITS
-    Content: "aaaa"
+    Content: [ 0xaa, 0xaa ]
     ShSize: 4
   - Name: .bar
     Type: SHT_PROGBITS
-    Content: "bbbb"
+    Content: [ 0xbb, 0xbb ]
 
 ## Check we can set both Size and ShSize and the number of the actual
 ## bytes written is equal to Size in this case.
 
 # RUN: yaml2obj --docnum=5 %s -o %t5
 # RUN: od -t x1 -v %t5 | FileCheck %s --ignore-case --check-prefix=CASE5
 
 # CASE5: aa aa 00 00 bb bb
 
 --- !ELF
 FileHeader:
   Class:   ELFCLASS64
   Data:    ELFDATA2LSB
   Type:    ET_REL
   Machine: EM_X86_64
 Sections:
   - Name: .foo
     Type: SHT_PROGBITS
-    Content: "aaaa"
+    Content: [ 0xaa, 0xaa ]
   - Name: .bar
     Type: SHT_PROGBITS
     Size: 2
     ShSize: 4
   - Name: .zed
     Type: SHT_PROGBITS
-    Content: "bbbb"
+    Content: [ 0xbb, 0xbb ]

llvm/test/tools/yaml2obj/ELF/program-header-nobits.yaml

 # RUN: yaml2obj %s -o %t
 # RUN: llvm-readobj -l %t | FileCheck %s
 
 !ELF
 FileHeader:
   Class:           ELFCLASS64
   Data:            ELFDATA2LSB
   Type:            ET_EXEC
   Machine:         EM_X86_64
 Sections:
   - Name:            .data
     Type:            SHT_PROGBITS
     Flags:           [ SHF_ALLOC ]
-    Content:         "00000000"
+    Content:         [ 0x0, 0x0, 0x0, 0x0 ]
   - Name:            .after
     Type:            SHT_NOBITS
     Flags:           [ SHF_ALLOC ]
     Size:            64
 ProgramHeaders:
   - Type: PT_LOAD
     Flags: [ PF_R ]
     Sections:

llvm/test/tools/yaml2obj/ELF/program-header.yaml

 # RUN: yaml2obj --docnum=1 %s -o %t
 # RUN: llvm-readobj -l %t | FileCheck %s
 
 --- !ELF
 FileHeader:
   Class:           ELFCLASS64
   Data:            ELFDATA2LSB
   Type:            ET_EXEC
   Machine:         EM_X86_64
 Sections:
   - Name:            .text
     Type:            SHT_PROGBITS
     Flags:           [ SHF_ALLOC, SHF_EXECINSTR ]
     AddressAlign:    0x0000000000001000
-    Content:         "00000000"
+    Content:         [ 0x0, 0x0, 0x0, 0x0 ]
   - Name:            .init
     Type:            SHT_PROGBITS
     Flags:           [ SHF_ALLOC, SHF_EXECINSTR ]
-    Content:         "00000000"
+    Content:         [ 0x0, 0x0, 0x0, 0x0 ]
     AddressAlign:    0x0000000000000010
   - Name:            .data
     Type:            SHT_PROGBITS
     Flags:           [ SHF_ALLOC ]
-    Content:         "00000000"
+    Content:         [ 0x0, 0x0, 0x0, 0x0 ]
     AddressAlign:    0x0000000000001000
 ProgramHeaders:
   - Type: PT_LOAD
     Flags: [ PF_X, PF_R ]
     VAddr: 0xAAAA1000
     PAddr: 0xFFFF1000
     Sections:
       - Section: .text

llvm/test/tools/yaml2obj/ELF/relocation-implicit-symbol-index.yaml

FileHeader:
   Class:           ELFCLASS64
   Data:            ELFDATA2LSB
   Type:            ET_EXEC
   Machine:         EM_X86_64
 Sections:
   - Name:            .text
     Type:            SHT_PROGBITS
     Flags:           [ SHF_ALLOC, SHF_EXECINSTR ]
-    Content:         "00000000"
+    Content:         [ 0x0, 0x0, 0x0, 0x0 ]
   - Name:            .rel.text
     Type:            SHT_REL
     Info:            .text
     Relocations:
       - Offset: 0x1000
         Type:   R_X86_64_RELATIVE
       ## R_X86_64_PC32 should have a non-zero symbol index but we don't error.
       - Offset: 0x1001
         Type:   R_X86_64_PC32

llvm/test/tools/yaml2obj/ELF/section-size-content.yaml

 FileHeader:
   Class:   ELFCLASS64
   Data:    ELFDATA2LSB
   Type:    ET_DYN
   Machine: EM_X86_64
 Sections:
   - Name:    .foo
     Type:    SHT_PROGBITS
-    Content: "FF"
+    Content: [ 0xFF ]
     Size:    0
 
 ## In this case, we have both `Content` and `Size` fields specified and
 ## `Size` is equal to the content size. We check that this is allowed and
 ## that the output section has a correct size value.
 
 # RUN: yaml2obj --docnum=2 %s -o %t2
 # RUN: llvm-readobj --section-data -S %t2 | FileCheck %s --check-prefix=CASE2

 FileHeader:
   Class:   ELFCLASS64
   Data:    ELFDATA2LSB
   Type:    ET_DYN
   Machine: EM_X86_64
 Sections:
   - Name:    .foo
     Type:    SHT_PROGBITS
-    Content: "FF"
+    Content: [ 0xFF ]
     Size:    1
 
 ## Check we can specify only `Content`.
 
 # RUN: yaml2obj --docnum=3 %s -o %t3
 # RUN: llvm-readobj --section-data -S %t3 | FileCheck %s --check-prefix=CASE2
 
 --- !ELF
 FileHeader:
   Class:   ELFCLASS64
   Data:    ELFDATA2LSB
   Type:    ET_DYN
   Machine: EM_X86_64
 Sections:
   - Name:    .foo
     Type:    SHT_PROGBITS
-    Content: "FF"
+    Content: [ 0xFF ]
 
 ## Check we can specify only `Size`.
 
 # RUN: yaml2obj --docnum=4 %s -o %t4
 # RUN: llvm-readobj --section-data -S %t4 | FileCheck %s --check-prefix=CASE3
 
 # CASE3:      Name: .foo
 # CASE3-NEXT: Type: SHT_PROGBITS

 FileHeader:
   Class:   ELFCLASS64
   Data:    ELFDATA2LSB
   Type:    ET_DYN
   Machine: EM_X86_64
 Sections:
   - Name:    .foo
     Type:    SHT_PROGBITS
-    Content: "FF"
+    Content: [ 0xFF ]
     Size:    3
 
 ## Check we emit an empty section if neither 'Content' nor 'Size' were set.
 
 # RUN: yaml2obj --docnum=6 %s -o %t6
 # RUN: llvm-readobj %t6 --sections | FileCheck %s --check-prefix=CASE5
 
 # CASE5:      Name: .foo
FileHeader:
   Class: ELFCLASS64
   Data: ELFDATA2LSB
   Type: ET_REL
   Machine: EM_X86_64
 Sections:
   - Name: .data
     Type: SHT_PROGBITS
     Flags: [ SHF_ALLOC ]
-    Content: 0000000000000000
+    Content: [ 0x11, 0x22, 0x33 ]
     Size: 2
 
 # ERR2:      error: Section size must be greater than or equal to the content size
 # ERR2-NEXT: - Name: .data
 # ERR2-NEXT:   ^
 # ERR2-NEXT: error: failed to parse YAML input

llvm/test/tools/yaml2obj/ELF/strtab-implicit-sections-size-content.yaml

 FileHeader:
   Class:   ELFCLASS64
   Data:    ELFDATA2LSB
   Type:    ET_DYN
   Machine: EM_X86_64
 Sections:
   - Name:    .strtab
     Type:    SHT_STRTAB
-    Content: "0102"
+    Content: [ 1, 2 ]
 ## Used to trigger adding string `foo` to the string table section.
 Symbols:
   - Name:    foo
 
 ## For string table sections, check we can specify both `Size` and `Content`
 ## when size is greater than content size. In this case zeroes are
 ## added as padding after the specified content.
 

 FileHeader:
   Class:   ELFCLASS64
   Data:    ELFDATA2LSB
   Type:    ET_DYN
   Machine: EM_X86_64
 Sections:
   - Name:    .strtab
     Type:    SHT_STRTAB
-    Content: "0102"
+    Content: [ 1, 2 ]
     Size:    3
 ## Used to trigger adding string `foo` to the string table section.
 Symbols:
   - Name:    foo
 
 ## For string table sections, check we can specify both `Size` and `Content`
 ## when size is equal to content size.
 

 FileHeader:
   Class:   ELFCLASS64
   Data:    ELFDATA2LSB
   Type:    ET_DYN
   Machine: EM_X86_64
 Sections:
   - Name:    .strtab
     Type:    SHT_STRTAB
-    Content: "0102"
+    Content: [ 1, 2 ]
     Size:    2
 ## Used to trigger adding string `foo` to the string table section.
 Symbols:
   - Name:    foo

llvm/test/tools/yaml2obj/ELF/symtab-implicit-sections-size-content.yaml

 FileHeader:
   Class:   ELFCLASS64
   Data:    ELFDATA2LSB
   Type:    ET_DYN
   Machine: EM_X86_64
 Sections:
   - Name:    .symtab
     Type:    SHT_SYMTAB
-    Content: "00"
+    Content: [ 0 ]
 Symbols:
   - Name: foo
 
 --- !ELF
 FileHeader:
   Class:   ELFCLASS64
   Data:    ELFDATA2LSB
   Type:    ET_DYN
   Machine: EM_X86_64
 Sections:
   - Name:    .symtab
     Type:    SHT_SYMTAB
-    Content: "00"
+    Content: [ 0 ]
 Symbols: []
 
 ## Check we can use just `Content` to emit custom data in the symbol table section.
 # RUN: yaml2obj --docnum=6 %s -o %t4
 # RUN: llvm-readobj --section-data -S %t4 | FileCheck %s --check-prefix=CASE4
 
 # CASE4:      Name: .symtab
 # CASE4-NEXT: Type: SHT_SYMTAB

 FileHeader:
   Class:   ELFCLASS64
   Data:    ELFDATA2LSB
   Type:    ET_DYN
   Machine: EM_X86_64
 Sections:
   - Name: .symtab
     Type: SHT_SYMTAB
-    Content: "0123"
+    Content: [ 0x01, 0x23 ]
 
 ## Check we can use just `Size` to emit custom data filled with zeroes
 ## in the symbol table section.
 # RUN: yaml2obj --docnum=7 %s -o %t5
 # RUN: llvm-readobj --section-data -S %t5 | FileCheck %s --check-prefix=CASE5
 
 # CASE5:      Name: .symtab (19)
 # CASE5-NEXT: Type: SHT_SYMTAB (0x2)

 FileHeader:
   Class:   ELFCLASS64
   Data:    ELFDATA2LSB
   Type:    ET_DYN
   Machine: EM_X86_64
 Sections:
   - Name: .symtab
     Type: SHT_SYMTAB
-    Content: "0123"
+    Content: [ 0x1, 0x23 ]
     Size: 4
 
 ## Check we can specify both `Size` and `Content` when size is
 ## equal to content size.
 
 # RUN: yaml2obj --docnum=9 %s -o %t7
 # RUN: llvm-readobj --section-data -S %t7 | FileCheck %s --check-prefix=CASE7
 

 FileHeader:
   Class:   ELFCLASS64
   Data:    ELFDATA2LSB
   Type:    ET_DYN
   Machine: EM_X86_64
 Sections:
   - Name: .symtab
     Type: SHT_SYMTAB
-    Content: "0123"
+    Content: [ 0x1, 0x23 ]
     Size: 2

llvm/tools/obj2yaml/elf2yaml.cpp

ELFDumper<ELFT>::dumpContentSection(const Elf_Shdr *Shdr) {
 
   unsigned SecIndex = Shdr - &Sections[0];
   if (SecIndex != 0 || Shdr->sh_type != ELF::SHT_NULL) {
     auto ContentOrErr = Obj.getSectionContents(Shdr);
     if (!ContentOrErr)
       return ContentOrErr.takeError();
     ArrayRef<uint8_t> Content = *ContentOrErr;
     if (!Content.empty())
-      S->Content = yaml::BinaryRef(Content);
+      S->Content = Content;
   } else {
     S->Size = static_cast<llvm::yaml::Hex64>(Shdr->sh_size);
   }
 
   if (Shdr->sh_info)
     S->Info = static_cast<llvm::yaml::Hex64>(Shdr->sh_info);
   return S.release();
 }