Re: [PATCH] x86-64: fix displaced stepping for VEX, XOP, and EVEX encoded insns

["Jan Beulich" <JBeulich at suse dot com>]

>>> On 07.02.19 at 17:09, <palves@redhat.com> wrote:
> On 02/07/2019 02:09 PM, Jan Beulich wrote:
>> Improper decoding has lead to wrong use of onebyte_has_modrm[] in all
>> those cases, leading to misbehavior in the debuggee (wrong data accessed
>> or faults raised) when RIP-relative operands were used. Fix VEX handling
>> and add XOP and EVEX recognition.
>> 
> 
> Thanks!
> 
>> I apologize for this not being accompanied by a testsuite extension, but
>> it was hard enough already to find a couple of hours to investigate and
>> fix the actual issue here.
> 
> I'd be really good to add a testcase though.
> <https://sourceware.org/ml/gdb-patches/2017-11/msg00748.html>
> added gdb.arch/amd64-disp-step-avx.S.  Can we add something there?
> Can you provide examples of instructions that we were getting wrong?

Not a complete set, but

	{evex} vmovaps xmm1, [rip+in]
	vmovdqa	xmm1, [rip+in]
	vmovdqa32 xmm1, [rip+in]
	vmovdqa64 xmm1, [rip+in]

all cause #GP(0) (due to the violated alignment requirement) and

	vmovdqu	xmm1, [rip+in]
	vmovdqu32 xmm1, [rip+in]
	vmovdqu8 xmm1, [rip+in]
	vbroadcasti128 ymm1, [rip+in]
	vbroadcasti32x4 zmm1, [rip+in]
	vbroadcasti64x2 zmm1, [rip+in]
	vbroadcastf32x4 zmm1, [rip+in]
	vpmovzxbw ymm1, [rip+in]

are ones that I had observed to load wrong data. Now that it is
clear what is going on, on criteria (but not necessarily the only
one) is whether a VEX-encoded insn's main opcode byte has the
respective onebyte_has_modrm[] table entry clear (because
that table got wrongly accessed). This for example explains the
(initially) confusing observation that VMOVAPS was fine but
VMOVDQA was not.

> Note that re. EVEX, back in that referenced patch I said:
>  ~~~
>  I think we may need a similar treatment for EVEX-encoded instructions,
>  but I didn't address that simply because I couldn't find any
>  EVEX-encoded RIP-relative instruction in the gas testsuite.
>  ~~~
> since you seem to know about some EVEX-encoded instruction that is
> mishandled today, it'd be really good to add a test for it too.

I think all of them were mishandled, because the EVEX prefix
wasn't skipped before reading the supposed ModR/M byte.
Same for XOP.

In general I have to say that I consider this model rather fragile,
as any new insns (not covered by general rules) allowing for
memory operands will first require a gdb change before they
can be successfully stepped over with a breakpoint set on them.
Was it considered to either disable non-stop mode (and hence
displaced stepping) for single threaded debuggees by default,
or otherwise to use displaced stepping only for positively known
insns?

Jan