From owner-freebsd-hackers  Sat Apr 27 11:37:45 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id LAA28990
          for hackers-outgoing; Sat, 27 Apr 1996 11:37:45 -0700 (PDT)
Received: from zygorthian-space-raiders.MIT.EDU (ZYGORTHIAN-SPACE-RAIDERS.MIT.EDU [18.70.0.61])
          by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id LAA28970
          Sat, 27 Apr 1996 11:37:39 -0700 (PDT)
Received: (from mycroft@localhost) by zygorthian-space-raiders.MIT.EDU (8.7.4/8.6.11) id OAA10935; Sat, 27 Apr 1996 14:37:27 -0400 (EDT)
To: "Jordan K. Hubbard" <jkh@time.cdrom.com>
Cc: sef@freebsd.org, hackers@freebsd.org
Subject: Re: Something fishy with our PT_ATTACH code!
References: <29493.830512651@time.cdrom.com>
From: mycroft@mit.edu (Charles M. Hannum)
Date: 27 Apr 1996 14:37:24 -0400
In-Reply-To: "Jordan K. Hubbard"'s message of Fri, 26 Apr 1996 02:57:31 -0700
Message-ID: <el2bukd344b.fsf@zygorthian-space-raiders.MIT.EDU>
Lines: 25
X-Mailer: September Gnus v0.78/Emacs 19.30
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk


"Jordan K. Hubbard" <jkh@time.cdrom.com> writes:

> 
> Start cat, attach cat from another tty with gdb, watch cat go to
> sleep, detach cat in gdb and watch it return to its previous
> un-stopped state.

Yes; that's correct.

One of the problems here is that PT_ATTACH sends a SIGSTOP to the
process, expecting it to be trapped by the debugger, but it
accidentally gets passed through when the process is resumed.  In
general, the signal handling in Sean's ptrace(2) implementation is
fairly broken.

Also, the only difference between PT_CONTINUE and PT_DETACH should be
that the latter gives the process back to its original parent first
(and turns off P_TRACED and P_WAITED, of course).  In particular,
PT_DETACH is allowed to specify an address and signal to continue
with.

You may want to look at the implementation in NetBSD, in which I've
fixed these problems (and others).