This patch adds support for emitting custom operands for range list.
It might be nice to call these U8, U16 etc, to make them nice and concise.
Maybe we should just treat this case as having no operands automatically?
I think you can just delete "their" here.
Looks fine to me either.
Does it make sense to print the number of types and values in the message?
"the number of operands (5) should match the number of their types (4)"
Do you need a cast here?
What about adding a test with mismatching types/values.
Types: [ Unsigned8 ] Values: [ 0x1234567890abcdef ]
Pretty much what I said already. This might be a nice way to test parsing of unknown/invalid DW_LLE constants, but there's only so many of those kinds of tests that we need, so it seems unnecessary.
Furthermore, once we're down in the invalid input land, it becomes very important to know how the bytes are laid out exactly in order to understand what the parser will do/has done. This becomes a (small) obstacle in that because I have to reason about the actual byte sequence that will be produced by this yaml -- I would prefer if I just had the bytes directly.
But if you do want to have this, I'm not going to stop you...
The biggest advantage I see in that approach is that it would enable obj2yaml to describe (chunks of) invalid debug_rnglists sections. So the way I would do this is to approach this from the other end -- look at how obj2yaml does its parsing. The point where it would need to "give up" because of a parsing error is a good place to insert a Contents attribute with a hex string. Here, one good such place seems to be the level which describes a single range list -- if one range list doesn't parse, we just insert a binary blob and then try again with the next list.
This looks like the "default label in a fully covered switch" warning, except that technically the switch is *not* fully covered without the default case. C++ is weird...