This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
[Bug server/13392] New: JMP insn in jump pad is not correct whenoffset exceeds integer limit
- From: "qiyao at gcc dot gnu.org" <sourceware-bugzilla at sourceware dot org>
- To: gdb-prs at sourceware dot org
- Date: Tue, 08 Nov 2011 03:48:25 +0000
- Subject: [Bug server/13392] New: JMP insn in jump pad is not correct whenoffset exceeds integer limit
- Auto-submitted: auto-generated
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.