Re: ptrace in 2.6.5

[Fabiano Ramos <ramos_fabiano@yahoo.com.br>]

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 <hirofumi@mail.parknet.co.jp> 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
re-enabled.

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.