lkml.org 
[lkml]   [2011]   [May]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: PTRACE_SEIZE should not stop [Re: [PATCH 02/11] ptrace: implement PTRACE_SEIZE]
Hi Tejun,

On Mon, 16 May 2011 10:31:13 +0200, Tejun Heo wrote:
> First of all, I don't think hitting different trap spots would be that
> difficult. Handling different traps after SEIZE might not be easy but
> could just be something which needs to be done anyway. I'm reluctant
> to treat the initial trap differently because it's essentially
> identical to what happens when a program does PTRACE_INTERRUPT. It's
> just something the program should be able to deal with, somewhat like
> read(2) may return shorter amount of data than provided buffer.

If not clear I would like also PTRACE_INTERRUPT to deliver the INTERRUPT event
always as the first one, if it is not clear.

tracer tracee foreign process
--------------- ------ ---------------
attaches tracee
normal run
tkill(tracee, SIGUSR1)
stopped, to report SIGUSR1 to tracer
PTRACE_INTERRUPT (but tracee is already stopped)
waitpid(tracee)

Currently that waitpid will report SIGUSR1 first and then the INTERRUPT trap.

I suggest - if possible - that tracer will get that INTERRUPT trap first.

But you made the optimization that the INTERRUPT gets suppressed in such case.
Which improves performance for the cost of more complicated debuggers.

I guess after PTRACE_SEIZE if the first signal/event is not INTERRUPT there
will not be any INTERRUPT later, as you said.


Thanks,
Jan


\
 
 \ /
  Last update: 2011-05-16 15:23    [W:0.125 / U:11.784 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site