[lkml]   [2011]   [Mar]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC] Proposal for ptrace improvements
Hi Tejun,

I didn't read the whole thread yet... perhaps this was already
discussed in more details. IOW, please ignore "I don't understand"
parts, I'll ask the questions later.

On 03/01, Tejun Heo wrote:
> I3. Not well-defined job control behaviors while traced
> In general, jctl behaviors while ptraced aren't well defined.

I'd say it is not defined at all ;) And to me this is the root of
all problems.

So, many thanks for this RFC. This is the first time someone tries
to define the rules.

> * PTRACE_CONT and other requests which resume the tracee overrides, or
> rather works below, jctl stop. If jctl stop takes place on the task
> group a tracee belongs to, the tracee will eventually participate in
> the group stop and its tracer will be notified; however, when
> PTRACE_CONT or other resuming request is made, the tracee will
> resume execution regardless of and without affecting the jctl stop.
> I don't know whether these are by design or just happened as
> by-products of the evolution of task group implementation in the
> kernel, but regardless, in my opinion, both rules are sound and
> useful. They might not be immediately intuitive and the resulting
> behavior might seem quirky but to me it seems to be one of those
> things which looks awkward at first but is ultimately right in its
> usefulness and relative simplicity.
> More importantly, it doesn't matter what I or, for that matter, anyone
> else thinks about them. They're tightly ingrained into the
> userland-visible behavior and actively exploited by the current users
> - for example, dynamic evalution in tracee context in gdb(1).
> Changing behaviors as fundamental as these would impact the current
> applications and debugging behaviors expected by (human) users.

OK. I have to agree. Lets forget the PTRACE_CONT-needs-SIGCONT idea.
Nobody like it, including Jan (even if he didn't nack it explicitly).

> --------
> P1. Always TASK_TRACED while ptraced


> P2. Fix notifications to the real parent
> This pleasantly proved to be the least contentious change to make.
> The usual group stop / continued notifications should be propagated to
> the real parent whether the children are ptraced or not.


> P3. Keep ptrace resume separate from and beneath jctl stop

This is not exactly clear to me... Probably I understand what
you mean, but I am not sure about details.


This is the new request. You know, I'd like to discuss the details
later and separately. Actually, I think the user-space developers
should participate and tell what they need. As for me, I certainly
agree that SIGSTOP from PTRACE_ATTACH is very wrong, and it is very
bad that gdb has to send SIGSTOP if it wants to stop the tracee.
IOW, I agree that something like this is needed and useful. In

> In both cases, jctl state is unaffected.


> P5. "^Z" and "fg" for tracees
> As proposed, when a tracee enters jctl stop, it enters TASK_TRACED
> from which emission of SIGCONT can't resume the tracee. This makes it
> impossible for a tracer to become transparent with respect to jctl.
> For example, after strace(1) is attached to a task, the task can be
> ^Z'd but then can't be fg'd.
> A better way to solve this is simply giving the tracer the capability
> to listen for the end of jctl stop.

Hmm. I don't understand what "the end of jctl stop" actually means.

Since you are talking about WCONTINUED below, I guess it means that
the process is not group-stopped any longer, say, SIGCONT comes.
OK. If the tracer is notified about the end of jctl stop, it can
resume the tracee if it wants. end-of-jctl-stop is per-process, but
I guess the debugger will be notified per-thread. Looks reasonable
to me.

> WCONTINUED is the obvious candidate but I think it is
> better to use STOPPED notification because the task is not really
> resumed. Only its mode of stop changes.


> What state the tracee is in
> can be determined by retriving siginfo using PTRACE_GETSIGINFO.

I don't understand this this details right now... But I guess this
doesn't matter right now.

Either way, debugger should have the ability to know the tracee's
state wrt group-stop. To oversimplify, it should know the state of


 \ /
  Last update: 2011-03-03 18:45    [W:0.273 / U:3.472 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site