Is the disassembled code in att syntax guaranteed to generate the same machine code?

[Jan Beulich]

On 28.04.2021 04:34, Peng Yu via Binutils wrote:
> It seems that there is no such guarantee.
> 
> This is the output from an object file.
>    a:    0f 1f 44 00 00           nopl   0x0(%rax,%rax,1)
>    f:    66 0f 1f 44 00 00        nopw   0x0(%rax,%rax,1)
>   15:    0f 1f 80 00 00 00 00     nopl   0x0(%rax)
>   1c:    0f 1f 84 00 00 00 00 00     nopl   0x0(%rax,%rax,1)
>   24:    66 0f 1f 84 00 00 00 00 00     nopw   0x0(%rax,%rax,1)
> 
> 
> If I take the disassembled code to generate another object file, the
> disassembled code will be something like this, which is not the same
> as the original machine code.
> 
>    a:    0f 1f 04 00              nopl   (%rax,%rax,1)
>    e:    66 0f 1f 04 00           nopw   (%rax,%rax,1)
>   13:    0f 1f 00                 nopl   (%rax)
>   16:    0f 1f 04 00              nopl   (%rax,%rax,1)
>   1a:    66 0f 1f 04 00           nopw   (%rax,%rax,1)
> 
> Should this be considered a bug?

No.

> I'd consider the disassembled code should be able to generate exactly
> the same machine code. Otherwise, the disassembled code should not be
> considered equivalent to the original machine code.

Many instructions have multiple possible encodings (here: without
displacement or with zero 8-bit displacement or with zero 32-/16-
bit displacement). The assembler strives to pick the smallest
possible encoding, albeit there are a number of cases where this
doesn't work quite right yet.

When there's just a single possible encoding, we further _try_ to
make disassembler output and assembler input match as far as
possible. I wouldn't consider it a bug if that's not the case
somewhere, but I'm relatively sure patches to improve individual
cases would be welcome.

Jan