From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31065 invoked by alias); 18 Feb 2003 03:32:16 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 31058 invoked from network); 18 Feb 2003 03:32:16 -0000 Received: from unknown (HELO mx1.redhat.com) (172.16.49.200) by 172.16.49.205 with SMTP; 18 Feb 2003 03:32:16 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h1I3WGK30571 for ; Mon, 17 Feb 2003 22:32:16 -0500 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h1I3WGa15200; Mon, 17 Feb 2003 22:32:16 -0500 Received: from localhost.redhat.com (romulus-int.sfbay.redhat.com [172.16.27.46]) by pobox.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h1I3WFs19199; Mon, 17 Feb 2003 22:32:15 -0500 Received: by localhost.redhat.com (Postfix, from userid 469) id 3AAFAFF79; Mon, 17 Feb 2003 22:36:22 -0500 (EST) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15953.43573.646843.825027@localhost.redhat.com> Date: Tue, 18 Feb 2003 03:32:00 -0000 To: Daniel Jacobowitz Cc: Andrew Cagney , Elena Zannoni , gdb-patches@sources.redhat.com Subject: Re: [RFC] PTRACE_ATTACH problem on new Linux kernels In-Reply-To: <20030218031431.GA31807@nevyn.them.org> References: <15953.34032.985446.344226@localhost.redhat.com> <20030218022401.14C7E3CF3@localhost.redhat.com> <20030218031431.GA31807@nevyn.them.org> X-SW-Source: 2003-02/txt/msg00366.txt.bz2 Daniel Jacobowitz writes: > On Mon, Feb 17, 2003 at 09:24:01PM -0500, Andrew Cagney wrote: > > Solution 0 is to discard the STOP in infrun.c as part of the stop > > analyzis. > > I like this; but I can't think how to do it without some global state > bit saying just-attached-expecting-SIGSTOP. > We kind of have it already, it is stop_soon_quietly, I am not sure it is specific enough though. > > > > > A first solution could be that upon continuing, gdb never sends a > > > SIGSTOP through the ptrace call. I.e. the stop_signal in > > > ptrace(PTRACE_CONT, pid, stop_signal) could be changed to > > > TARGET_SIGNAL_0 if it is TARGET_SIGNAL_STOP (such a call is in > > > proceed(), and we already do some signal munging there). > > > > > > Another solution is to throw away the TARGET_SIGNAL_STOP that is saved > > > in stop_signal when we do an attach. This would be in > > > attach_command(), in infcmd.c. This way it would not come into play at > > > all at the next continue. > > > > This will make the desperatly needed objective of trying to eliminate > > the global stop_signal variable just that bit more difficult. > > > > If the already nasty hacks in HP/PA and solib code is ignored, the > > only places stop_signal is modified is in infrun.c. > > > > > Yet another solution is that we 'hide' the TARGET_SIGNAL_STOP in > > > child_resume(), in i386-linux-nat.c but this would not be applicable > > > to the other linux arches. > > > > Or discard the signal in resume()? > > > > Regardless, remembering that GDB is just one client of the kernel, the > > kernel group should probably also restore the behavour that is > > conistent with solaris and (most likely) every other ptrace > > implementation. > > I'm not sure what Solaris does - don't we use procfs instead of ptrace > there anyway? Do we still get a SIGSTOP at attach? Unless I was hallucinating gdb was getting a SIGSTOP and passing that down to resume, later. I'll look again. > > But Roland made a very convincing case for this new behavior; for > programs like strace which just pass all signals through, this prevents > SIGSTOPs being silently cancelled, which is a definite plus. > > -- > Daniel Jacobowitz > MontaVista Software Debian GNU/Linux Developer