[RFC] PTRACE_ATTACH problem on new Linux kernels

[Elena Zannoni <ezannoni@redhat.com>]

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.<PID>)
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");
 }