public inbox for gdb-prs@sourceware.org help / color / mirror / Atom feed
From: "qiyao at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org> To: gdb-prs@sourceware.org Subject: [Bug server/13392] New: JMP insn in jump pad is not correct when offset exceeds integer limit Date: Tue, 08 Nov 2011 03:49:00 -0000 [thread overview] Message-ID: <bug-13392-4717@http.sourceware.org/bugzilla/> (raw) http://sourceware.org/bugzilla/show_bug.cgi?id=13392 Bug #: 13392 Summary: JMP insn in jump pad is not correct when offset exceeds integer limit Product: gdb Version: HEAD Status: NEW Severity: normal Priority: P2 Component: server AssignedTo: unassigned@sourceware.org ReportedBy: qiyao@gcc.gnu.org Classification: Unclassified In current gdbserver code, linux-x86-low.c:amd64_install_fas_tracepoint_jump_pad, /* The jump pad is now built. Wire in a jump to our jump pad. This is always done last (by our caller actually), so that we can install fast tracepoints with threads running. This relies on the agent's atomic write support. */ offset = *jump_entry - (tpaddr + sizeof (jump_insn)); memcpy (buf, jump_insn, sizeof (jump_insn)); memcpy (buf + 1, &offset, 4); memcpy (jjump_pad_insn, buf, sizeof (jump_insn)); *jjump_pad_insn_size = sizeof (jump_insn); static unsigned char jump_insn[] = { 0xe9, 0, 0, 0, 0 }; We are using relative jump and assume that 32-bit displacement is large enough, however, it is not correct in some cases. In my case below, jump pad is quite far, and unable to jump via relative jump insn that we are using. We compose a wrong jmp insn, write back to original insn place, and cause a SIGSEGV. (gdb) ftrace set_tracepoint Fast tracepoint 2 at 0x400756: file ../../../gdb/gdb/testsuite/gdb.trace/change-loc.h, line 35. (2 locations) (gdb) tstart (gdb) c Continuing. Program received signal SIGSEGV, Segmentation fault. func4 () at ../../../gdb/gdb/testsuite/gdb.trace/change-loc.h:35 35 asm (" .global " SYMBOL(set_tracepoint) "\n" (gdb) p/x $pc $1 = 0x7ffff79d556e (gdb) disassemble Dump of assembler code for function func4: 0x00007ffff79d556a <+0>: push %rbp 0x00007ffff79d556b <+1>: mov %rsp,%rbp => 0x00007ffff79d556e <+4>: callq 0x7ffff79d5564 <func5> 0x00007ffff79d5573 <+9>: leaveq 0x00007ffff79d5574 <+10>: retq End of assembler dump. (gdb) info tracepoints Num Type Disp Enb Address What 2 fast tracepoint keep y <MULTIPLE> 2.1 y 0x0000000000400756 in func4 at ../../../gdb/gdb/testsuite/gdb.trace/change-loc.h:35 2.2 y 0x00007ffff79d556e in func4 at ../../../gdb/gdb/testsuite/gdb.trace/change-loc.h:35 -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
next reply other threads:[~2011-11-08 3:49 UTC|newest] Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top 2011-11-08 3:49 qiyao at gcc dot gnu.org [this message] 2011-11-08 4:09 ` [Bug server/13392] " qiyao at gcc dot gnu.org 2012-03-09 3:47 ` cvs-commit at gcc dot gnu.org 2012-03-09 3:56 ` qiyao at gcc dot gnu.org
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-13392-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).