FYI: fix 2 tests when glibc debuginfo is installed

[Oleg Nesterov]

On 10/25, Pedro Alves wrote:
>
> 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,

Well, PTRACE_ATTACH was not really changed in this sense. And it
still sends SIGSTOP. You can use PTRACE_SEIZE.

But I guess this is off-topic,

> 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. 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.

Or I misunderstood?

Oleg.