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

[Oleg Nesterov <oleg@redhat.com>]

On 10/25, Pedro Alves wrote:
>
> On Tuesday 25 October 2011 18:32:49, Oleg Nesterov wrote:
> >
> > > 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
> >
> > Why? PTRACE_CONT/etc should work. The tracee will be resumed, stopped
> > or not.
>
> Eh, well, I read some discussions from earlier this year on
> lkml proposing that, and I guess I got confused.

Yes, we discussed this option too. And yes, the discussion was
loooooooooooooooooong and confusing ;)

> > But, compared to the old kernels, the tracee "remembers" the
> > fact it was stopped, and it will stop again after DETACH. Unless SIGCONT
> > in between.
>
> What about PTRACE_CONT in between (no SIGCONT)?  Does it make the
> kernel "forget" the fact that the child was stopped before?

No,

> If not, what happens if the ptracer dies while its child
> is PTRACE_CONT'ed, and the child was stopped at PTRACE_ATTACH time?

This doesn't differ from the explicit PTRACE_DETACH.

Actually, this is very simple. We have the per-process (_not_
per thread/tracee) flag, SIGNAL_STOP_STOPPED. It means that this
thread group is stopped (OK, it is not that simple, but we can ignore
details). ptrace can never set/clear this flag. In particular it
is still set after PTRACE_CONT or whatever resumes the tracee.
Only SIGCONT clears SIGNAL_STOP_STOPPED.

Now, __ptrace_unlink() (called by PTRACE_DETACH or by the dying
tracee) checks SIGNAL_STOP_STOPPED, if it is set we ask the tracee
to stop again.

Oleg.