From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29781 invoked by alias); 29 Sep 2003 13:21:55 -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 29774 invoked from network); 29 Sep 2003 13:21:54 -0000 Received: from unknown (HELO localhost.redhat.com) (207.219.125.105) by sources.redhat.com with SMTP; 29 Sep 2003 13:21:54 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 041022B8D; Mon, 29 Sep 2003 09:21:56 -0400 (EDT) Message-ID: <3F7831F3.6010203@redhat.com> Date: Mon, 29 Sep 2003 13:23:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030820 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Jacobowitz Cc: Michael Elizabeth Chastain , aurelien.chanudet@enst.fr, gdb@sources.redhat.com Subject: Re: process attaching gdb to itself References: <200309282225.h8SMP9Rf026649@duracef.shout.net> <3F77622C.8090403@redhat.com> <20030928232401.GA20802@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-09/txt/msg00368.txt.bz2 >> 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. > 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. > 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? Andrew