public inbox for gdb-prs@sourceware.org help / color / mirror / Atom feed
From: "amonakov at gmail dot com" <sourceware-bugzilla@sourceware.org> To: gdb-prs@sourceware.org Subject: [Bug tdep/28999] New: amd64_get_insn_details wrong for some AVX instructions Date: Thu, 24 Mar 2022 21:57:15 +0000 [thread overview] Message-ID: <bug-28999-4717@http.sourceware.org/bugzilla/> (raw) https://sourceware.org/bugzilla/show_bug.cgi?id=28999 Bug ID: 28999 Summary: amd64_get_insn_details wrong for some AVX instructions Product: gdb Version: unknown Status: UNCONFIRMED Severity: normal Priority: P2 Component: tdep Assignee: unassigned at sourceware dot org Reporter: amonakov at gmail dot com Target Milestone: --- Trying breakpointing on 'f' in typedef unsigned char u8v16 __attribute__((vector_size(16))); __attribute__((weak)) u8v16 f(void) { return (u8v16){-1}; } int main() { f(); } which gcc -O2 -mavx compiles to f: vmovdqa .LC0(%rip), %xmm0 ret you'll see that 'cont' or 'si' after hitting the breakpoint results in SIGSEGV, even though the program is correct and runs just fine without the breakpoint. Printing $_siginfo is not helpful, but the reason for the segfault is that behind the scenes vmovdqa is moved to another address, but its RIP-relative displacement field is unchanged: (gdb) set debug displaced on (gdb) c Continuing. displaced: stepping process 29476 now displaced: saved 0x401002: f9 6f 05 f7 0f 00 00 0f 0b 00 00 00 00 00 00 00 displaced: copy 0x401001->0x401002: c5 f9 6f 05 f7 0f 00 00 0f 0b 00 00 00 00 00 00 displaced: displaced pc to 0x401002 displaced: run 0x401002: c5 f9 6f 05 displaced: restored process 29476 0x401002 Program received signal SIGSEGV, Segmentation fault. If you hand-edit the assembly, replacing 'vmovdqa' with 'movdqa' or 'movaps', gdb correctly detects presence of RIP-relative addressing. The logic in amd64_get_insn_details is such that after skipping any prefixes, including the VEX prefix, it looks up presence of ModRM field via the onebyte_has_modrm table, but this opcode map from year 1999 is not applicable if VEX prefix was present. In other circumstances, the breakpointed instruction could have allowed unaligned access, and would read/write wrong data instead of segfaulting, like in this bugreport: https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/1850258. Happy debugging! -- You are receiving this mail because: You are on the CC list for the bug.
next reply other threads:[~2022-03-24 21:57 UTC|newest] Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-03-24 21:57 amonakov at gmail dot com [this message] 2022-06-10 18:12 ` [Bug tdep/28999] " cebtenzzre at gmail dot com
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-28999-4717@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=gdb-prs@sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
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).