[Bug breakpoints/31481] New: Certain instructions load the wrong RIP-relative memory after setting a breakpoint

[Bug breakpoints/31481] New: Certain instructions load the wrong RIP-relative memory after setting a breakpoint

[boudewijn83 at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31481

            Bug ID: 31481
           Summary: Certain instructions load the wrong RIP-relative
                    memory after setting a breakpoint
           Product: gdb
           Version: HEAD
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: breakpoints
          Assignee: unassigned at sourceware dot org
          Reporter: boudewijn83 at gmail dot com
  Target Milestone: ---

On Linux, x86-64, using any gdb version from:
  7.10.50.20150930 (commit 398e081380a204e3b9fb4eb4da069ccf471f930e)

Up to and including:
  HEAD

When you set a breakpoint at certain instructions that load RIP-relative
memory, run the program up to this breakpoint, then continue execution (or
single-step through), they will load the wrong memory.

Here's a minimal reproducible example:

  .globl _start

  .data
  .align 32
    unused1: .quad 0xFFFFFFFFFFFFFFFF, 0xFFFFFFFFFFFFFFFF
    number:  .quad 0x1122334455667788, 0xAABBCCDDEEDDCCBB
    unused2: .quad 0xEEEEEEEEEEEEEEEE, 0xEEEEEEEEEEEEEEEE

  .text
    _start:
      vmovq number(%rip), %xmm1
      vpextrq $0, %xmm1, %rdi
      mov $60, %eax
      syscall

Assemble, link, and run in strace:

  $ as -o test.o test.s && ld ./test.o && strace -e x=exit ./a.out

Output is, as expected:

  exit(0x1122334455667788)

Now in gdb:

  $ gdb -ex "b _start" -ex "r" -ex "stepi 2" -ex "print/x \$rdi" ./a.out

  $1 = 0xccbb112233445566

Note how it somehow loaded 2 bytes from the second quad at "number".

Some instructions I found affected are:

  vmovq        number(%rip), %xmm1
  vmovdqu      number(%rip), %ymm1
  vpaddq       number(%rip), %ymm1, %ymm1
  vpxor        number(%rip), %ymm1, %ymm1
  vpbroadcastd number(%rip), %ymm1
  vpbroadcastq number(%rip), %ymm1

Some instructions NOT affected are:

  movq         number(%rip), %xmm1
  movdqu       number(%rip), %xmm1
  vpaddd       number(%rip), %ymm1, %ymm1
  vpblendd     $0xFF, number(%rip), %ymm1, %ymm1
  vpermq       $0x00, number(%rip), %ymm1

The regression seems to have occurred at the commit above, before that commit
everything works as expected.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug breakpoints/31481] Certain instructions load the wrong RIP-relative memory after setting a breakpoint

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31481

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at sourceware dot org

--- Comment #1 from Tom Tromey <tromey at sourceware dot org> ---
Maybe related to bug#28999.

Basically there seem to be some displaced stepping issues.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug breakpoints/31481] Certain instructions load the wrong RIP-relative memory after setting a breakpoint

[boudewijn83 at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31481

--- Comment #2 from Boudewijn <boudewijn83 at gmail dot com> ---
Oh hey, that might be it!

I did some hacking:

At each of the buggy instructions "fixup_displaced_copy" in amd64-tdep.c gets
called with "detail->modrm_offset" still set to -1, even though all the
instructions have a ModRM byte.

And with modrm_offset == -1 it never calls "fixup_riprel".

So I think the fix is to:

- add lookup tables for the VEX-prefixed opcode maps 1-3
- use those in amd64_get_insn_details, whenever vex2_prefix_p(*insn) or
vex3_prefix_p(*insn)

Something like that?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug breakpoints/31481] Certain instructions load the wrong RIP-relative memory after setting a breakpoint

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31481

--- Comment #3 from Tom Tromey <tromey at sourceware dot org> ---
I don't know this code well, but yes, that sounds correct to me.
It's where I would start, anyway.

I wonder if libopcodes has some way to help us out here.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug breakpoints/31481] Certain instructions load the wrong RIP-relative memory after setting a breakpoint

[sam at gentoo dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31481

Sam James <sam at gentoo dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sam at gentoo dot org

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug breakpoints/31481] Certain instructions load the wrong RIP-relative memory after setting a breakpoint

[boudewijn83 at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31481

--- Comment #4 from Boudewijn <boudewijn83 at gmail dot com> ---
Created attachment 15409
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15409&action=edit
Proposed patch, fixes #28999 and #31481

There's actually no need for an extra lookup table.

All (E)VEX prefixed instructions share the same two properties:

- the (explicit part of the) opcode is only 1 byte
- they all have a ModRM byte, except VZEROALL/VZEROUPPER

So when there's an (E)VEX prefix it suffices to test for VZEROALL/VZEROUPPER
(opcode 0x77):

  if (vex2 or vex3 or evex) {
    details->opcode_len = 1;
    need_modrm = (*insn != 0x77);
  } else {
    use the legacy has_modrm tables
  }

I've attached a patch that implements this.

PS: I've tested VEX2/VEX3, but don't have an AVX-512 capable CPU so I'm not
able to test the EVEX handling.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug breakpoints/31481] Certain instructions load the wrong RIP-relative memory after setting a breakpoint

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31481

--- Comment #5 from Tom Tromey <tromey at sourceware dot org> ---
Thank you.  gdb normally doesn't do any patch review in bugzilla.
Instead you can send the patch to the patches list.  Voluminous
instructions here:

https://sourceware.org/gdb/wiki/ContributionChecklist

I don't really know this area, someone else will probably
review the patch.
However I do wonder if a test case is possible.

-- 
You are receiving this mail because:
You are on the CC list for the bug.