Hello,
even though we hashed it out downthread, let me make some additional
remarks:
On Thu, 24 Sep 2020, Borislav Petkov wrote:
> > /* MOVDIR64B [rdx], rax */
This comment is confusing as it uses Intel syntax for the operand forms,
but AT&T order (dest last).
> volatile struct { char _[64]; } *__dst = dst;
>
> ...
>
> : "=m" (__dst)
This and the other occurences in this thread up to now always miss that
the 'm' constraints want the object itself, not the address of the object.
So you want '"m" (*__src)', same for dst, and so on.
> Micha, the instruction is:
>
> MOVDIR64B %(rdx), rax
>
> "Move 64-bytes as direct-store with guaranteed 64-byte write atomicity
> from the source memory operand address to destination memory address
> specified as offset to ES segment in the register operand."
It's unfortunate that the introduction of this mnemonic into binutils
did it wrong already, but what the instruction should really read like in
AT&T mode is:
movdir64b (%rdx), (%rax)
or even
movdir64b (%rdx), es:(%rax)
because both are memory operands really (even though the destination can
only be encoded with a direct register, as these are the constraints of
x86 insn encodings). It's comparable to movs, which, also having two
memory operands is written:
movsb %ds:(%rsi),%es:(%rdi)
Ciao,
Michael.
