From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31723 invoked by alias); 29 Sep 2003 13:26:43 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 31715 invoked from network); 29 Sep 2003 13:26:42 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 29 Sep 2003 13:26:42 -0000 Received: from drow by nevyn.them.org with local (Exim 4.22 #1 (Debian)) id 1A3y2q-0004fs-0r; Mon, 29 Sep 2003 09:26:32 -0400 Date: Mon, 29 Sep 2003 13:30:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: Michael Elizabeth Chastain , aurelien.chanudet@enst.fr, gdb@sources.redhat.com Subject: Re: process attaching gdb to itself Message-ID: <20030929132631.GA17873@nevyn.them.org> Mail-Followup-To: Andrew Cagney , Michael Elizabeth Chastain , aurelien.chanudet@enst.fr, gdb@sources.redhat.com References: <200309282225.h8SMP9Rf026649@duracef.shout.net> <3F77622C.8090403@redhat.com> <20030928232401.GA20802@nevyn.them.org> <3F7831F3.6010203@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F7831F3.6010203@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-09/txt/msg00370.txt.bz2 On Mon, Sep 29, 2003 at 09:21:55AM -0400, Andrew Cagney wrote: > > >>works on BSD but fails on GNU/Linux. When doing an attach, BSD always > >>generates something for wait4 to consume. GNU/Linux does not, leaving > >>GDB stuck in wait4 :-( > > > > > >Yes, I've known about this problem for a long time. We've [I, Roland, > > This explains something. I beg your pardon? > >a couple of other people I can't recall] talked about changing it and > >decided that, really, the current behavior makes more sense. > > Not to me. > > GDB sends a message to the kernel asking for the process to stop. The > kernel sends a message back indicating that the request has completed. The kernel generates a message at each change of the program's state. It isn't changing state; it was already stopped. This behavior allows the debugger to determine if the program was stopped before attach; I can easily picture a multi-threaded daemon design that leaves parts of itself SIGSTOP'd and would get confused if unexpectedly wakened. > >It's not at all hard to make GDB work in the current system anyway. > >Just have to do it. It goes something like: > > - attach > > - wait4 WNOHANG, break if succeeds (optimistic, not necessary) > > - check in /proc to make sure the process is in a stopped state > > - If it was: > > - wait4 WNOHANG > > - If we get a status, then the process was running when we attached > > - If no status is available then the process was stopped when > > we attached > > - If it wasn't: > > - The process was running when we attached and hasn't stopped yet > > - wait4 without WNOHANG > > I feel ill. What happens, for instance, if /proc isn't there? At this point in its life, Linux can just assume the /proc filesystem is available. Linus has repeatedly refused to duplicate information available via /proc through another interface. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer