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

["boudewijn83 at gmail dot com" <sourceware-bugzilla@sourceware.org>]

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.