From: Daniel Jacobowitz <dan@debian.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>,
Linus Torvalds <torvalds@transmeta.com>,
linux-kernel@vger.kernel.org
Subject: Re: [patch] ptrace-fix-2.5.33-A1
Date: Thu, 5 Sep 2002 18:29:47 -0400 [thread overview]
Message-ID: <20020905222947.GA13667@nevyn.them.org> (raw)
In-Reply-To: <Pine.LNX.4.44.0209060021360.14643-100000@localhost.localdomain>
On Fri, Sep 06, 2002 at 12:25:32AM +0200, Ingo Molnar wrote:
>
> On Thu, 5 Sep 2002, Daniel Jacobowitz wrote:
>
> > Right - let me rephrase. Tasks which are either:
> > - untraced, normal
> > - traced, but traced _by their parent_
> > are on the sibling/children list.
>
> hm, why the distinction along whether the debugger == real parent? What
> wrong can happen if we always move traced tasks to the ptrace list? The
> task will be both in the ptrace list and in the parent's child list, and
> everything should work as expected. This looks a more symmetric and
> simpler thing to me.
Hmm, I like that idea. But I was talking about current implementation.
If we want to do this then we'd need to fix up every ptrace
implementation in every architecture to call the appropriate function;
it's a separate problem.
> > > this splitup of the lists makes it possible for the debugger to do a wait4
> > > that will get events from the debugged task, and for the debugged task to
> > > also be available to the real parent.
> >
> > Great. I'm not exactly sure on how this works right now: sys_wait4 only
> > iterates over ->children, with the exception of the special code in
> > TASK_ZOMBIE. I'm not quite sure when events from a traced process get
> > to the normal parent of that process, or when they're supposed to.
>
> i'm not sure about this either. What happens if an (untraced) parent has
> traced and untraced children, and does a wait4. Would it confuse the
> debugger if the parent could get one of the traced tasks as a result in
> wait4? And how does the debugger solve this problem?
Well, it seems to me that when a traced task has an event, it should be
reported first to the debugger - for signals this happens in do_signal
- and then possibly to the normal parent. But I'm not sure if this
actually happens right now or not. Worth investigating some more.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
next prev parent reply other threads:[~2002-09-05 22:25 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-09-05 22:09 [patch] ptrace-fix-2.5.33-A1 Ingo Molnar
2002-09-05 22:15 ` Daniel Jacobowitz
2002-09-05 22:25 ` Ingo Molnar
2002-09-05 22:29 ` Daniel Jacobowitz [this message]
2002-09-05 22:39 ` Ingo Molnar
2002-09-05 22:50 ` Daniel Jacobowitz
2002-09-05 22:58 ` Ingo Molnar
2002-09-06 15:27 ` OGAWA Hirofumi
2002-09-06 15:45 ` Daniel Jacobowitz
2002-09-06 15:57 ` Ingo Molnar
2002-09-06 20:44 ` OGAWA Hirofumi
2002-09-05 22:41 ` Ingo Molnar
2002-09-05 22:52 ` Daniel Jacobowitz
2002-09-05 22:35 ` Ingo Molnar
2002-09-05 23:02 ` Daniel Jacobowitz
2002-09-05 23:08 ` Ingo Molnar
-- strict thread matches above, loose matches on Subject: below --
2002-09-05 22:10 Ingo Molnar
2002-09-05 15:35 Ingo Molnar
2002-09-05 17:08 ` OGAWA Hirofumi
2002-09-05 18:36 ` Daniel Jacobowitz
2002-09-05 20:06 ` Ingo Molnar
2002-09-05 21:44 ` Daniel Jacobowitz
2002-09-05 22:12 ` Daniel Jacobowitz
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=20020905222947.GA13667@nevyn.them.org \
--to=dan@debian.org \
--cc=hirofumi@mail.parknet.co.jp \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=torvalds@transmeta.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.