[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110303202246.GB32152@redhat.com>
Date: Thu, 3 Mar 2011 21:22:46 +0100
From: Oleg Nesterov <oleg@...hat.com>
To: Tejun Heo <tj@...nel.org>
Cc: Roland McGrath <roland@...hat.com>, jan.kratochvil@...hat.com,
Denys Vlasenko <vda.linux@...glemail.com>,
linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
akpm@...ux-foundation.org
Subject: Re: [RFC] Proposal for ptrace improvements
On 03/03, Oleg Nesterov wrote:
>
> I'll ask the questions later.
Right now I do not see any holes (but I'll try more ;)
One question, to ensure I really understand you. To simplify,
consider this particular example.
Tracee:
int main(void)
{
kill(SIGSTOP, getpid());
printf("I am running\n");
for (;;)
;
}
To simplify again, suppose that the debugger attaches when it is
already stopped, then it does PTRACE_CONT(0).
In this case the tracee remains SIGNAL_STOP_STOPPED but prints
"I am running" and enters the endless loop.
(the new debugger can do PTRACE_SEIZE after that and "return"
it to the stopped state without affecting jctl state).
Now, if SIGCONT comes (from anywhere) it clears SIGNAL_STOP_STOPPED,
the tracee traps and reports this event to debugger.
Correct?
And, once again. In the mt case, I assume that SIGCONT makes
every traced thread to report this event individually, right?
(I am talking about the case when the group-stop was finished,
iow "every" probably means the threads which participated and
reported CLD_STOPPED to the debugger).
In both cases, later then this SIGCONT will be reported again
as any "normal" signal when some thread dequeues it.
Is my understanding correct?
Thanks,
Oleg.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists