Re: [patch] Fix Linux attach to signalled/stopped processes

[Daniel Jacobowitz <drow@false.org>]

[Roland, job control question for you in here.  I'm not sure who else
to ask...]

On Wed, Apr 02, 2008 at 12:30:12AM +0200, Jan Kratochvil wrote:
> The condition whether the detached process (previously attached as stopped)
> should be left stopped or running is not intuitive there now, it is Red Hat
> patches backward compatible but IMO it should rather ask the user (with
> a default of leaving it stopped).

Yes, I don't like the changed behavior of detach.  I think it would be
more intuitive if detach always resumed, and the disconnect command
worked for native debugging.  Although that leaves gdbserver out in
the cold (disconnect already has meaning there).  So maybe it should
be detach --stopped?  For the FSF version we can address this
separately from the attach bug.

I have another idea to solve the attach problem that does not involve
redelivering signals - use WNOHANG in the initial wait if /proc
already shows the process as stopped.  There shouldn't be a race if
this is done after we PTRACE_ATTACH.

But I got hung up trying to figure out what was going on with
testing...

If I run attach-stopped from your testcase in a shell, then send it a
stop signal using kill from another window, stock GDB fails to attach
to it - just as I'd expect, that's the bug we're discussing.  But if I
run the attach-stopped.exp test script this part works fine.  It turns
out that if we spawn the program in expect (even at the expect1.1>
prompt, by hand) instead of using a shell with job control, GDB can
attach to it just fine.

In both cases the kernel reports the process as stopped.  The
difference in ps is the "s+":

drow     28162  0.0  0.0   6152   376 pts/50   Ts+  11:19   0:00 ./gdb.threads/attach-stopped
drow     28179  0.0  0.0   6152   376 pts/51   T    11:20   0:00 ./gdb.threads/attach-stopped

There's no difference in /proc/pid/status at all, besides the PIDs.
The "s" means session leader, the "+" means foreground process group.
28162 is the one run from expect.

Any idea why this makes a difference?  Kernel version is 2.6.24, if
that matters.  If we could get the foreground process group behavior
all the time, then we don't even need to change GDB.  But I don't know
if that's right since I don't understand how it occurs.

-- 
Daniel Jacobowitz
CodeSourcery