From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30034 invoked by alias); 18 Feb 2003 03:28:32 -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 30027 invoked from network); 18 Feb 2003 03:28:31 -0000 Received: from unknown (HELO mx1.redhat.com) (172.16.49.200) by 172.16.49.205 with SMTP; 18 Feb 2003 03:28:31 -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 h1I3SVK30088 for ; Mon, 17 Feb 2003 22:28:31 -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 h1I3SVa14635; Mon, 17 Feb 2003 22:28:31 -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 h1I3SUs19001; Mon, 17 Feb 2003 22:28:30 -0500 Received: by localhost.redhat.com (Postfix, from userid 469) id ED376FF79; Mon, 17 Feb 2003 22:32:35 -0500 (EST) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15953.43345.841483.153044@localhost.redhat.com> Date: Tue, 18 Feb 2003 03:28:00 -0000 To: ac131313@redhat.com (Andrew Cagney) Cc: Elena Zannoni , gdb-patches@sources.redhat.com Subject: Re: [RFC] PTRACE_ATTACH problem on new Linux kernels In-Reply-To: <20030218022401.14C7E3CF3@localhost.redhat.com> References: <15953.34032.985446.344226@localhost.redhat.com> <20030218022401.14C7E3CF3@localhost.redhat.com> X-SW-Source: 2003-02/txt/msg00365.txt.bz2 Andrew Cagney writes: > Solution 0 is to discard the STOP in infrun.c as part of the stop > analyzis. > Yes, but I am not sure it won't break the other cases that share that stop analysis. The stop_soon_quietly variable is relied upon in other places, like the start_remote function, the startup_inferior function, the sharedlib machinery. That's why I thought the handling it in the attach command would be safer. > > 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. > Hmm true, sigh. > > 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()? > yes, proceed() already does something like that, but that would mean that we modify the signal before doing the continue, and not after we receive it. There is a lot that can happen between issuing an 'attach' command, and a later 'continue'. Maybe we would be discarding a valid SIGSTOP to pass to the inferior. I think the only option left is to change the handle_inferior_event stop analysis, which is scary... > 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. > > Andrew