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:50:38 -0400 [thread overview]
Message-ID: <20020905225038.GA14295@nevyn.them.org> (raw)
In-Reply-To: <Pine.LNX.4.44.0209060036100.17495-100000@localhost.localdomain>
On Fri, Sep 06, 2002 at 12:39:02AM +0200, Ingo Molnar wrote:
>
> On Thu, 5 Sep 2002, Daniel Jacobowitz wrote:
>
> > 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.
>
> which code relies on having debugged children only in the ->children list
> and not in the ->ptrace_children list?
Every implementation of PTRACE_TRACEME leaves them in the ->children
list. They are never added to ptrace_children. Whether this is
_right_ is another question.
> > > 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.
>
> it just cannot happen. There are only two kinds of events passed via
> wait4: tracing related and exit related. An exiting task is not traced
> anymore. And two tasks cannot trace the same task - so it can never happen
> that wait4 wants to look at ->ptrace_children for events.
Oh. You are, of course, right.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
next prev parent reply other threads:[~2002-09-05 22:46 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
2002-09-05 22:39 ` Ingo Molnar
2002-09-05 22:50 ` Daniel Jacobowitz [this message]
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=20020905225038.GA14295@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.