[lkml]   [2004]   [May]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: ptrace in 2.6.5

    On Mon, 2004-05-10 at 19:58, Daniel Jacobowitz wrote:
    > On Tue, May 11, 2004 at 07:47:08AM +0900, OGAWA Hirofumi wrote:
    > > OGAWA Hirofumi <> writes:
    > >
    > > > So single-step exception happen *after* executed the "mov ...".
    > > > Probably you need to use the breakpoint instead of single-step.
    > >
    > > Ah, sorry. Just use PTRACE_SYSCALL instead of PTRACE_SINGLESTEP.
    > > It's will stop before/after does syscall.
    > Doing it this way is pretty lousy - you have to inspect the code after
    > every step to see if it's an int $0x80. Is there some reason not to
    > report a trap on the syscall return path if single-stepping?

    Strange thing. When entering a syscall, the int 0x80 does clear the
    trap, but first it is saved into the stack. When the iret is executed,
    the eflags is restored from the stack, thus single stepping is

    The question is: the int 0x80 can be seen as complex instructions that
    is only completed after the iret. This way, I do not see why a debug
    trap is not generated afer the int 0x80 and BEFORE the mov.

    I reinvented the wheel and built a module that did the same thing as
    a singlestep ptrace, and a the trap WAS generated after the int 0x80
    completed, before the mov.

    So I think it has sth to do with the debug trap handler.

    I DO NOT BELIEVE THIS BEAVIOUR is right, since if it is not stopping
    after the int 0x80, ptrace is not TRULLY singlestepping.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:03    [W:0.021 / U:60.780 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site