[PATCH] D82366: [yaml2obj] - Support reading a content as an array of bytes using the new 'ContentArray' key.

[George Rimar via Phabricator via llvm-commits]

grimar added a comment.

In D82366#2109569 <https://reviews.llvm.org/D82366#2109569>, @MaskRay wrote:

> This implements `.byte`. Shall we support counterparts of .asciz, .short, and .long?


At first I thought about implementing a `ContentAsm` key and wanted to support .byte, .short, .long and .quad for start.
It could look like the following:

  ContentAsm:
   - .byte:  0x11
   - .short: 0x2233
   - .long: 0x11223344

The problem is that it could require much more code and I wasn't sure how much it is useful given that such sections
are probably supposed to be temporary, for the cases when user wants to create a YAML test, but a particular SHT_* type
is not yet fully supported by yaml2obj. Also I can't say that such syntax looks nice to me.

I see no other way to implement things like ".asciz, .short, and .long". Particularly, even if we had an array of strings to support
.byte, .short, .long and .quad, like:

  ContentArray: [ "0x11", "0x2233", "0x44556677" ...

Then it wouldn't allow to implement `.asciz`, because it is not clear how to distinguish between a string and a hex integer.

> For strings, specifying a string instead of indivial codepoints will be useful.

It is also not clear how to implement null bytes for string values. It would need supporting excape value '\0' probably.

So given that such sections are probably temporary ones, and looking on the concerns above, I'd probably not do something
much more complex here than this patch does.


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

https://reviews.llvm.org/D82366