Add AMD znver5 RMPREAD instruction

[Kalvakuntla, Umesh]

Jan,
I have started with rmpupdate instruction and faced few issues.
I have the following doubts.
In the x86_64_table entry,
We have tried couple of ways to get the constrained segment register. 
Using combinations of rCX_reg and { OP_EM, OP_SEG }.
We thought G addressing code might also be relevant in this case. But since 
there is no implementation of OP_GM, didn't try that further. 
Both didn't work as expected. And it is probably because of the issues in 
Opcode table entry being problematic. 

What is the right way to specify the constrained register in Modrm operation?
Ex: rmpupdate, 0xf20f01fe, SNP&x64, Modrm|AddrPrefixOpReg|NoSuf, { Unspecified|BaseIndex, Acc|Qword }
In the above example, using Acc|Reg64 caused error saying Internal error in build_modrm_byte. 
But using just Reg64, there was no error in compilation.
Should the build_modrm_byte function be updated, or the way we are trying to describe is incorrect?

We have tried understanding from movq implementation using 
Ex: movq %ss:(%rdi), %rax.
The disassembled opcode was 36 48 8b 07. We couldn't find 0x8b07 opcode in i386-opc.tbl. Can you help 
us where to look for in such cases. Are there any other files where the opcode description is written?

Also, I couldn't find much information online to debug. if there's any documentation that we are missing, 
can you please point me to it.

Regards,
Umesh



1. what addressing method codes are relevant here? 

> -----Original Message-----
> From: Jan Beulich <jbeulich@suse.com>
> Sent: Wednesday, January 15, 2025 7:56 PM
> To: Kalvakuntla, Umesh <Umesh.Kalvakuntla@amd.com>
> Cc: Gopalasubramanian, Ganesh <Ganesh.Gopalasubramanian@amd.com>;
> binutils@sourceware.org
> Subject: Re: Add AMD znver5 RMPREAD instruction
> 
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
> 
> 
> On 15.01.2025 12:31, Kalvakuntla, Umesh wrote:
> > [Public]
> >
> >> Hmm, maybe you misunderstood: This is a question towards the spec. We
> >> first need to know what the intentions are. Then we can sort out how
> >> to arrange for this in gas (and further consider whether to permit improved
> syntax also for other insns).
> >> The answer to the spec question may very well be "do it like it was
> >> always done, as we don't care", but really I'd hope for a better one.
> >>
> >> Taking Intel syntax, I'd expect ordinary memory operands to be
> >> spelled like such, even if they require a fixed register:
> >>
> >>         rmpread [rcx], rax
> >>
> >> And then similarly for the older RMPUPDATE:
> >>
> >>         rmpupdate rax, [rcx]
> >>
> >> And alike for AT&T syntax:
> >>
> >>         rmpread %rax, (%rcx)
> >>         rmpupdate (%rcx), %rax
> >>
> >> Then adding segment overrides becomes simple, as they would naturally
> >> go on the memory operands. Yet there may of course be reasons why
> >> this syntax wasn't used originally, and hence why it shouldn't be used either for
> RMPREAD.
> >>
> >> Following the spec to the letter would mean no operands at all to
> >> these and several other insns. That's undesirable, too, as it makes
> >> it harder to spell out
> >> (assembly) or distinguish (disassembly) forms with and without
> >> overrides (segment and/or address). Hence why _some_ form of operands
> >> was introduced in gas, short of the specs (Intel's included) making this explicit.
> >>
> >> I'd like to further note that I question the correctness of the
> >> RMPUPDATE handling in gas (and then likely also in objdump; didn't
> >> check yet): I just can't see how an address size override could
> >> affect %rax (holding a physical address), rather than %rcx (holding
> >> an effective address). This wants confirming, and the mistake (if
> >> there is one) not repeating here, but rather correcting for RMPUPDATE
> >> then, too. If otoh that _is_ how hardware behaves, then it surely
> >> warrants a comment next to the respective RMPUPDATE entry in our
> >> opcode table. (I notice I didn't pay close enough attention to this
> >> also when originally reviewing the SNP patch, and when then fixing
> >> things in c0e54661f755.)
> >
> > The suggestion from the spec is to update these SNP instructions the way you
> suggested.
> > Spell ordinary memory operands as they are. It is a mistake in the
> > specification document, and hence the previous implementations of it.
> > The specification documents need to be updated too (it might take time for this).
> >
> > The current expectation is:
> > Default:
> >         rmpread [rcx], rax
> > With segment override:
> >         rmpread ds:[rcx], rax
> >
> > The suggestion also mentions not to support the syntax without operands.
> >
> > Please let me know if you have any questions, and if I can work on
> > these updates and send the patch.
> 
> Please go ahead. As long as the (public) doc wasn't updated yet, in the patch
> description be sure to provide enough detail on the plans to do so.
> 
> Jan