Re: FYI: fix 2 tests when glibc debuginfo is installed

[Pedro Alves <pedro@codesourcery.com>]

On Saturday 15 October 2011 15:47:58, Oleg Nesterov wrote:
> On 10/14, Pedro Alves wrote:
> >
> > On Friday 14 October 2011 22:25:10, Jan Kratochvil wrote:
> > > On Fri, 14 Oct 2011 23:19:09 +0200, Pedro Alves wrote:
> > > > On Friday 14 October 2011 20:37:05, Jan Kratochvil wrote:
> > > > > thanks; although these testcases are broken anyway, they should be updated for
> > > > > Linux kernels 3.1.x which always keep inferior stopped if it was stopped
> > > > > during PTRACE_ATTACH; probably to XFAIL older kernels.
> > > >
> > > > Urgh.  Even if you SIGCONT the process before PTRACE_DETACH?
> > >
> > > Yes.  But I do not think it is problem, one can SIGCONT it safely after
> > > PTRACE_DETACH.  Just it may be (T)-stopped for a moment but why not.
> 
> Confused... SIGCONT should work even the task is traced. It won't
> resume the tracee, but it should change its (internal) state to
> mark it as not-stopped.

Thanks.  Okay, so I take it what really happens is that PTRACE_ATTACH no
longer messes with job control, and that gdb will have to
`kill -SIGCONT' the inferior itself if it wants e.g., inferior
function calls to work after attaching to a stopped process (or
if something else SIGSTOPs the program).  Hmm, feels like we got rid
of some races to introduce others.

> > no debugger:
> >
> > $ kill -SIGSTOP PID
> > *stop*
> > $ kill -SIGCONT PID
> > *continue*
> >
> > with debugger:
> >
> > $ kill -SIGSTOP PID
> > *stop*
> >                            $ strace/gdb -p PID
> >                            ...
> > $ kill -SIGCONT PID
> >                            ^C/detach
> > *stop*
> >
> > Oleg, do you have a pointer to a discussion or description of the
> > change? Why doesn't at least the SIGCONT cancel the stop on detach?
> 
> It does or I missed something.

-- 
Pedro Alves