[PATCH] opcodes/x86: fix minor missed styling case
Jan Beulich
jbeulich@suse.com
Wed Jul 24 08:46:36 GMT 2024
On 24.07.2024 10:42, Cui, Lili wrote:
>> On 24.07.2024 04:31, Cui, Lili wrote:
>>>>> I noticed that the x86 instruction:
>>>>>
>>>>> sar $0x1,%rsi
>>>>>
>>>>> would fail to style the '$0x1' as an immediate. This commit fixes that case.
>>>>>
>>>
>>> I'm afraid it is not a bug, it is to distinguish between the two formats below.
>>>
>>> sar r/m8, 1
>>> sar r/m8, imm8
>>
>> It is a bug, but it also is a bug to change 1 to 0x1, as that way said distinction
>> goes away. (I also don't immediately see how the code change alone would
>> pass the testsuite; I'm pretty sure we have expectations which would have
>> required adjustment, which would have made more obvious that the change
>> wants doing differently.)
>>
> Jan, do you have any suggestions on how to distinguish between IMM1 and IMM8? It seems that the current distinction can easily cause confusion.
>
> Currently,
> Intel format: disassembler prints 1 for Imm1 and 0x1 for Imm8.
> ATT format: disassembler prints $1 for Imm1 and $0x1 for Imm8.
And that's fine. It's just that the Imm1 case also wants styling as
immediate (without the prepending any 0x). If and when we move to not
always emitting 0x for immediates in general (which is a plan I have
been having for quite some time), your question would actually become
relevant. Provided we actually continue to think there is a need to
distinguish the two forms in disassembly. I don't think we make
recognizable which encoding is in use in a number of other cases
where multiple encodings exist.
Jan
More information about the Binutils
mailing list