This is the mail archive of the gdb-prs@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug server/13392] New: JMP insn in jump pad is not correct whenoffset exceeds integer limit


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]