Re: [PATCH 2/2] libopcodes: extend the styling within the i386 disassembler

[Jan Beulich <jbeulich@suse.com>]

On 29.04.2022 15:42, Andrew Burgess via Binutils wrote:
> The i386 disassembler is pretty complex.  Most disassembly is done
> indirectly; operands are built into buffers within a struct instr_info
> instance, before finally being printed later in the disassembly
> process.
> 
> Sometimes the operand buffers are built in a different order to the
> order in which they will eventually be printed.
> 
> Each operand can contain multiple components, e.g. multiple registers,
> immediates, other textual elements (commas, brackets, etc).
> 
> When looking for how to apply styling I guess the ideal solution would
> be to move away from the operands being a single string that is built
> up, and instead have each operand be a list of "parts", where each
> part is some text and a style.  Then, when we eventually print the
> operand we would loop over the parts and print each part with the
> correct style.
> 
> But it feels like a huge amount of work to move from where we are
> now to that potentially ideal solution.  Plus, the above solution
> would be pretty complex.
> 
> So, instead I propose a .... different solution here, one that works
> with the existing infrastructure.
> 
> As each operand is built up, piece be piece, we pass through style
> information.  This style information is then encoded into the operand
> buffer (see below for details).  After this the code can continue to
> operate as it does right now in order to manage the set of operand
> buffers.
> 
> Then, as each operand is printed we can split the operand buffer into
> chunks at the style marker boundaries, with each chunk being printed
> in the correct style.
> 
> For encoding the style information I use the format "~%x~".  As far as
> I can tell the '~' is not otherwise used in the i386 disassembler, so
> this should serve as a unique marker.  To speed up writing and then
> reading the style markers, I take advantage of the fact that there are
> less than 16 styles so I know the '%x' will only ever be a single hex
> character.

Like H.J. I'd like to ask that you avoid ~ here (I actually have plans
to use it to make at least some 64-bit constants better recognizable);
I'm not sure about using non-ASCII though, as that may cause issues with
compilers treating non-ASCII wrong. I'd soften this to non-alnum, non-
operator characters (perhaps more generally non-printable). Otoh I guess
about _any_ character could be used in symbol names, so I'm not
convinced such an escaping model can be generally conflict free.

Jan