public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
* [Bug breakpoints/31481] New: Certain instructions load the wrong RIP-relative memory after setting a breakpoint
@ 2024-03-14 1:55 boudewijn83 at gmail dot com
2024-03-14 13:01 ` [Bug breakpoints/31481] " tromey at sourceware dot org
` (5 more replies)
0 siblings, 6 replies; 7+ messages in thread
From: boudewijn83 at gmail dot com @ 2024-03-14 1:55 UTC (permalink / raw)
To: gdb-prs
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug breakpoints/31481] Certain instructions load the wrong RIP-relative memory after setting a breakpoint
2024-03-14 1:55 [Bug breakpoints/31481] New: Certain instructions load the wrong RIP-relative memory after setting a breakpoint boudewijn83 at gmail dot com
@ 2024-03-14 13:01 ` tromey at sourceware dot org
2024-03-14 16:35 ` boudewijn83 at gmail dot com
` (4 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: tromey at sourceware dot org @ 2024-03-14 13:01 UTC (permalink / raw)
To: gdb-prs
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug breakpoints/31481] Certain instructions load the wrong RIP-relative memory after setting a breakpoint
2024-03-14 1:55 [Bug breakpoints/31481] New: Certain instructions load the wrong RIP-relative memory after setting a breakpoint boudewijn83 at gmail dot com
2024-03-14 13:01 ` [Bug breakpoints/31481] " tromey at sourceware dot org
@ 2024-03-14 16:35 ` boudewijn83 at gmail dot com
2024-03-14 20:29 ` tromey at sourceware dot org
` (3 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: boudewijn83 at gmail dot com @ 2024-03-14 16:35 UTC (permalink / raw)
To: gdb-prs
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug breakpoints/31481] Certain instructions load the wrong RIP-relative memory after setting a breakpoint
2024-03-14 1:55 [Bug breakpoints/31481] New: Certain instructions load the wrong RIP-relative memory after setting a breakpoint boudewijn83 at gmail dot com
2024-03-14 13:01 ` [Bug breakpoints/31481] " tromey at sourceware dot org
2024-03-14 16:35 ` boudewijn83 at gmail dot com
@ 2024-03-14 20:29 ` tromey at sourceware dot org
2024-03-14 22:43 ` sam at gentoo dot org
` (2 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: tromey at sourceware dot org @ 2024-03-14 20:29 UTC (permalink / raw)
To: gdb-prs
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug breakpoints/31481] Certain instructions load the wrong RIP-relative memory after setting a breakpoint
2024-03-14 1:55 [Bug breakpoints/31481] New: Certain instructions load the wrong RIP-relative memory after setting a breakpoint boudewijn83 at gmail dot com
` (2 preceding siblings ...)
2024-03-14 20:29 ` tromey at sourceware dot org
@ 2024-03-14 22:43 ` sam at gentoo dot org
2024-03-16 11:54 ` boudewijn83 at gmail dot com
2024-03-16 17:39 ` tromey at sourceware dot org
5 siblings, 0 replies; 7+ messages in thread
From: sam at gentoo dot org @ 2024-03-14 22:43 UTC (permalink / raw)
To: gdb-prs
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug breakpoints/31481] Certain instructions load the wrong RIP-relative memory after setting a breakpoint
2024-03-14 1:55 [Bug breakpoints/31481] New: Certain instructions load the wrong RIP-relative memory after setting a breakpoint boudewijn83 at gmail dot com
` (3 preceding siblings ...)
2024-03-14 22:43 ` sam at gentoo dot org
@ 2024-03-16 11:54 ` boudewijn83 at gmail dot com
2024-03-16 17:39 ` tromey at sourceware dot org
5 siblings, 0 replies; 7+ messages in thread
From: boudewijn83 at gmail dot com @ 2024-03-16 11:54 UTC (permalink / raw)
To: gdb-prs
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug breakpoints/31481] Certain instructions load the wrong RIP-relative memory after setting a breakpoint
2024-03-14 1:55 [Bug breakpoints/31481] New: Certain instructions load the wrong RIP-relative memory after setting a breakpoint boudewijn83 at gmail dot com
` (4 preceding siblings ...)
2024-03-16 11:54 ` boudewijn83 at gmail dot com
@ 2024-03-16 17:39 ` tromey at sourceware dot org
5 siblings, 0 replies; 7+ messages in thread
From: tromey at sourceware dot org @ 2024-03-16 17:39 UTC (permalink / raw)
To: gdb-prs
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2024-03-16 17:39 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-03-14 1:55 [Bug breakpoints/31481] New: Certain instructions load the wrong RIP-relative memory after setting a breakpoint boudewijn83 at gmail dot com
2024-03-14 13:01 ` [Bug breakpoints/31481] " tromey at sourceware dot org
2024-03-14 16:35 ` boudewijn83 at gmail dot com
2024-03-14 20:29 ` tromey at sourceware dot org
2024-03-14 22:43 ` sam at gentoo dot org
2024-03-16 11:54 ` boudewijn83 at gmail dot com
2024-03-16 17:39 ` tromey at sourceware dot org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).