This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] x86-64: fix displaced stepping for VEX, XOP, and EVEX encoded insns
>>> 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