From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13986 invoked by alias); 18 Feb 2003 00:53: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 13865 invoked from network); 18 Feb 2003 00:53:15 -0000 Received: from unknown (HELO mx1.redhat.com) (172.16.49.200) by 172.16.49.205 with SMTP; 18 Feb 2003 00:53:15 -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 h1I0rFK01352 for ; Mon, 17 Feb 2003 19:53:15 -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 h1I0rFa15786 for ; Mon, 17 Feb 2003 19:53:15 -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 h1I0rEs11728 for ; Mon, 17 Feb 2003 19:53:14 -0500 Received: by localhost.redhat.com (Postfix, from userid 469) id 76AC6FF79; Mon, 17 Feb 2003 19:57:21 -0500 (EST) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15953.34032.985446.344226@localhost.redhat.com> Date: Tue, 18 Feb 2003 00:53:00 -0000 To: gdb-patches@sources.redhat.com Subject: [RFC] PTRACE_ATTACH problem on new Linux kernels X-SW-Source: 2003-02/txt/msg00362.txt.bz2 The recent linux kernels (2.5.61), have some changes to the behavior of ptrace wrt signals. see the thread at: http://www.uwsg.indiana.edu/hypermail/linux/kernel/0302.2/0107.html One of this changes is the behavior of SIGSTOP for a process that is being ptraced. The kernel would ignore these SIGSTOPs. Now the kernel doesn't ignore SIGSTOPs anymore, and therefore gdb needs to deal with them. If, after an 'attach', the debugger issues a 'continue', it would restart the inferior with a ptrace(PTRACE_CONT, pid, stop_signal) call. The stop_signal, after an attach, would be SIGSTOP, because that's how the kernel stopped the debuggee when the PTRACE_ATTACH request was received (this is still the case). However, now it is gdb that needs to throw away the notification of a SIGSTOP (while before it was muffled by the kernel). If you don't do this, you will see a new FAIL (maybe more) in the attach.exp test. The test does a continue after an attach, and the SIGSTOP is reported to the user, creating some cascade failures. Also the test doesn't clean up after itself very well, and if you FAIL in that particular spot you will see the test process (attach1.) still running after the test is over. There are a few possible ways to deal with this new behavior in gdb. 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. 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. I have verified that the second and third approach work. For the second approach, I have verified that it works fine under Solaris 2.5.1 as well. (Solaris also throws away the SIGSTOP). The interesting thing is that the handle_inferior_event function already partially silenced the SIGSTOP from the attach itself. The stop_soon_quietly variable is used for this purpose, and it is set in the attach_command. So we have already a special case for attach. Here are the diffs for the 2 approaches. Daniel already said (in private e-mail) that he doesn't like the i386-linux-nat.c fix. So I am posting both :-P I do agree that the attach_command fix is cleaner. Thoughts? (yes, I will add comments, etc etc) elena Solution 2: Index: infcmd.c =================================================================== RCS file: /cvs/src/src/gdb/infcmd.c,v retrieving revision 1.72 diff -u -p -r1.72 infcmd.c --- infcmd.c 1 Feb 2003 17:28:40 -0000 1.72 +++ infcmd.c 18 Feb 2003 00:44:20 -0000 @@ -1915,6 +1915,7 @@ attach_command (char *args, int from_tty #ifndef ATTACH_NO_WAIT stop_soon_quietly = 1; wait_for_inferior (); + stop_signal = TARGET_SIGNAL_0; #endif /* Solution 3: Index: i386-linux-nat.c =================================================================== RCS file: /cvs/uberbaum/gdb/i386-linux-nat.c,v retrieving revision 1.43 diff -u -p -r1.43 i386-linux-nat.c --- i386-linux-nat.c 9 Nov 2002 21:31:11 -0000 1.43 +++ i386-linux-nat.c 18 Feb 2003 00:45:21 -0000 @@ -862,7 +862,10 @@ child_resume (ptid_t ptid, int step, enu } } } + + if (signal == TARGET_SIGNAL_STOP) + signal = TARGET_SIGNAL_0; + if (ptrace (request, pid, 0, target_signal_to_host (signal)) == -1) perror_with_name ("ptrace"); }