From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13444 invoked by alias); 18 Feb 2003 02:39:15 -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 13412 invoked from network); 18 Feb 2003 02:39:14 -0000 Received: from unknown (HELO localhost.redhat.com) (172.16.49.200) by 172.16.49.205 with SMTP; 18 Feb 2003 02:39:14 -0000 Received: by localhost.redhat.com (Postfix, from userid 1008) id 14C7E3CF3; Mon, 17 Feb 2003 21:24:01 -0500 (EST) Subject: Re: [RFC] PTRACE_ATTACH problem on new Linux kernels In-Reply-To: <15953.34032.985446.344226@localhost.redhat.com> "from Elena Zannoni at Feb 17, 2003 07:57:20 pm" To: Elena Zannoni Date: Tue, 18 Feb 2003 02:39:00 -0000 Cc: gdb-patches@sources.redhat.com MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Message-Id: <20030218022401.14C7E3CF3@localhost.redhat.com> From: ac131313@redhat.com (Andrew Cagney) X-SW-Source: 2003-02/txt/msg00363.txt.bz2 Solution 0 is to discard the STOP in infrun.c as part of the stop analyzis. > 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. Andrew