public inbox for archer@sourceware.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Roland McGrath <roland@redhat.com>
Cc: Project Archer <archer@sourceware.org>
Subject: Re: ptrace improvement: PTRACE_O_INHERIT
Date: Tue, 15 Feb 2011 13:16:00 -0000	[thread overview]
Message-ID: <20110215130805.GA30742@redhat.com> (raw)
In-Reply-To: <20110215003551.BC1EA1802A2@magilla.sf.frob.com>

On 02/14, Roland McGrath wrote:
>
> > I meant, I do not agree that it never makes sense to trace, say, a
> > single thread from the thread group. But since we are talking about
> > gdb my noncompliance is off-topic.
>
> We are also talking about what makes sense for a kernel interface, so it's
> certainly apropos to share our thoughts on the general subject.  Please
> elaborate on why you think this makes sense.  It's certainly true that it
> makes sense to have your tracing details different for one thread than for
> others (stopping on more events, etc.)

No, I didn't mean this (but I agree this is true).

> but that's quite a different thing
> from saying it really makes sense to have a debugging interface structured
> to consider tracing an individual thread as unrelated to tracing all the
> threads in the same process,

Yes, and I can't understand why this doesn't make sense.

I do not have any good example in mind. But if I want to know what this
particular thread does, why should I trace the whole process? Not to
mention, with the current ptrace interface it is never "free" to ptrace
the threads you do not care about.

If nothing else. I like the fact "strace -p" can trace the individual
thread without disturbing the whole thread group.


And in fact I don't really understand why WCLONNED doesn't make sense
in general. OK, probably gdb doesn't need it. As you said,

	It supplies no new information, only mentions the tracee earlier.

sure. IOW, the new thread doesn't exist (from gdb pov) until it reports
something interesting.

OK, but I think PTRACE_O_INHERIT is useful in general, not only for gdb.
And it looks a bit strange the tracer can't know what it traces. Especially
because the current API is per-thread.

Suppose that debugger uses PTRACE_O_INHERIT and then it decides to detach
gracefully. It should detach per-thread, but how? /proc is very unconvenient.
Even if we traced all threads, we do not trace them all after we detach
the first thread, and that thread can clone the new threads after detach.

Oleg.

  reply	other threads:[~2011-02-15 13:16 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-03 22:39 ptrace improvement ideas Roland McGrath
2011-02-04 18:56 ` Oleg Nesterov
2011-02-04 18:58   ` Roland McGrath
2011-02-07 21:11 ` Jan Kratochvil
2011-02-08  1:58   ` Roland McGrath
2011-02-08 20:41     ` Jan Kratochvil
2011-02-09  2:48       ` Roland McGrath
2011-02-08 21:07     ` Oleg Nesterov
2011-02-08 23:18       ` hw_breakpoint userland interface Roland McGrath
2011-02-10 21:03         ` Oleg Nesterov
2011-02-10 21:14           ` Roland McGrath
2011-02-11 20:17             ` Oleg Nesterov
2011-02-10 20:00 ` ptrace improvement: PTRACE_O_INHERIT Oleg Nesterov
2011-02-11 19:24   ` Roland McGrath
2011-02-11 20:46     ` Oleg Nesterov
2011-02-12  0:59       ` Roland McGrath
2011-02-12 19:11         ` Oleg Nesterov
2011-02-14 19:31           ` Roland McGrath
2011-02-14 19:46             ` Oleg Nesterov
2011-02-15  0:36               ` Roland McGrath
2011-02-15 13:16                 ` Oleg Nesterov [this message]
2011-02-15 21:43                   ` Jan Kratochvil
2011-02-15 21:56                     ` Roland McGrath
2011-02-16 19:42                       ` Oleg Nesterov
2011-02-16 19:45                         ` Roland McGrath
2011-02-16 20:09                           ` Oleg Nesterov
2011-02-16 20:16                             ` Roland McGrath
2011-02-19 19:48                             ` Jan Kratochvil
2011-02-19 20:37                               ` Oleg Nesterov
2011-02-20  8:18                                 ` Jan Kratochvil
2011-02-20 21:05                                   ` Oleg Nesterov
2011-02-21 19:54                                 ` Roland McGrath
2011-02-22 19:39                                   ` Oleg Nesterov
2011-02-22 20:49                                     ` Roland McGrath
2011-02-22 21:10                                       ` Oleg Nesterov
2011-02-22 22:16                                         ` Roland McGrath
2011-02-21 19:44                               ` Roland McGrath
2011-02-15 22:02                     ` Roland McGrath
2011-02-16 16:02                       ` Jan Kratochvil
2011-02-16 18:28                         ` Roland McGrath
2011-02-16 20:00                           ` Oleg Nesterov
2011-02-16 20:07                             ` Roland McGrath
2011-02-16 20:32                               ` Oleg Nesterov
2011-02-16 19:48                       ` Oleg Nesterov
2011-02-16 20:02                         ` Roland McGrath
2011-02-16 20:15                           ` Oleg Nesterov
2011-02-16 20:31                             ` Roland McGrath
2011-02-16 21:04                               ` Oleg Nesterov
2011-02-16 21:51                                 ` Roland McGrath
2011-02-16 19:38                     ` Oleg Nesterov
2011-02-16 19:40                       ` Roland McGrath
2011-02-15 22:17                   ` Roland McGrath
2011-02-16 20:48                     ` Oleg Nesterov
2011-02-16 11:31 ` ptrace improvement ideas (QPassSignals) Jan Kratochvil
2011-02-16 18:36   ` Roland McGrath
2011-02-16 20:21     ` Oleg Nesterov
2011-02-18 20:24       ` Oleg Nesterov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110215130805.GA30742@redhat.com \
    --to=oleg@redhat.com \
    --cc=archer@sourceware.org \
    --cc=roland@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).