FYI: fix 2 tests when glibc debuginfo is installed

FYI: fix 2 tests when glibc debuginfo is installed

[Tom Tromey]

I'm checking this in.

I found a couple of tests that work by accident when glibc debuginfo is
installed.

First, when running attach-stopped.exp:

    break 30
    Breakpoint 1 at 0x3a160d2d30: file ../sysdeps/unix/syscall-template.S, line 63. (7 locations)

This is not what is intended:

    # This breakpoint is there for old/non-x86 kernels not restarting syscalls.
    gdb_breakpoint [gdb_get_line_number "Second sleep"]

Second, attachstop-mt.exp:

    break 30
    Breakpoint 1 at 0x3a160d2d30: file ../sysdeps/unix/syscall-template.S, line 63. (7 locations)

Again:

    gdb_breakpoint [gdb_get_line_number "cut the sleep time"]

The fix is to add $srcfile to the linespec.

Tom

2011-10-14  Tom Tromey  <tromey@redhat.com>

	* gdb.threads/attachstop-mt.exp: Add $srcfile to the linespecs.
	* gdb.threads/attach-stopped.exp (corefunc): Add $srcfile to the
	linespec.

Index: gdb.threads/attach-stopped.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.threads/attach-stopped.exp,v
retrieving revision 1.6
diff -u -r1.6 attach-stopped.exp
--- gdb.threads/attach-stopped.exp	1 Jan 2011 15:33:50 -0000	1.6
+++ gdb.threads/attach-stopped.exp	14 Oct 2011 16:03:49 -0000
@@ -78,7 +78,7 @@
 	gdb_test "bt" ".*sleep.*main.*" "$threadtype: attach2 to stopped bt"
     }
     # This breakpoint is there for old/non-x86 kernels not restarting syscalls.
-    gdb_breakpoint [gdb_get_line_number "Second sleep"]
+    gdb_breakpoint $srcfile:[gdb_get_line_number "Second sleep"]
     set test "$threadtype: attach2 continue"
     gdb_test_multiple "continue" "continue ($test)" {
 	-re "Continuing" {
Index: gdb.threads/attachstop-mt.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.threads/attachstop-mt.exp,v
retrieving revision 1.7
diff -u -r1.7 attachstop-mt.exp
--- gdb.threads/attachstop-mt.exp	1 Jan 2011 15:33:50 -0000	1.7
+++ gdb.threads/attachstop-mt.exp	14 Oct 2011 16:03:49 -0000
@@ -208,8 +208,8 @@
 gdb_test "bt" ".*sleep.*(func|main).*" "attach4 to stopped bt"
 
 # RHEL3U8 kernel-2.4.21-47.EL will not return SIGINT but only shorten the sleep.
-gdb_breakpoint [gdb_get_line_number "Ridiculous time"]
-gdb_breakpoint [gdb_get_line_number "cut the sleep time"]
+gdb_breakpoint $srcfile:[gdb_get_line_number "Ridiculous time"]
+gdb_breakpoint $srcfile:[gdb_get_line_number "cut the sleep time"]
 set test "attach4 continue"
 gdb_test_multiple "continue" "continue ($test)" {
     -re "Continuing" {

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

[Jan Kratochvil]

On Fri, 14 Oct 2011 18:04:34 +0200, Tom Tromey wrote:
> The fix is to add $srcfile to the linespec.

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.


Regards,
Jan

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

[Pedro Alves]

On Friday 14 October 2011 20:37:05, Jan Kratochvil wrote:
> On Fri, 14 Oct 2011 18:04:34 +0200, Tom Tromey wrote:
> > The fix is to add $srcfile to the linespec.
> 
> 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?  Why was
the behavior changed incompatibly if we're having the all new
PTRACE_SEIZE?  Do you have a lkml reference to the change?

-- 
Pedro Alves

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

[Jan Kratochvil]

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.

The opposite - the upstream 2.6.x kernel state - was IMO worse, it was resumed
and one could not safely keep it stopped.


> Why was the behavior changed incompatibly if we're having the all new
> PTRACE_SEIZE?  Do you have a lkml reference to the change?

I do not have anything specific, AFAIK it just happened as part of all the
changes incl. PTRACE_SEIZE.  I have updated the behavior into two new *-3x.c
tests with Oleg Nesterov ~review/check/approval in:
	http://sourceware.org/systemtap/wiki/utrace/tests


Regards,
Jan

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

[Pedro Alves]

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.

So,

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?

> The opposite - the upstream 2.6.x kernel state - was IMO worse, it was resumed
> and one could not safely keep it stopped.
> 
> 
> > Why was the behavior changed incompatibly if we're having the all new
> > PTRACE_SEIZE?  Do you have a lkml reference to the change?
> 
> I do not have anything specific, AFAIK it just happened as part of all the
> changes incl. PTRACE_SEIZE.  I have updated the behavior into two new *-3x.c
> tests with Oleg Nesterov ~review/check/approval in:
> 	http://sourceware.org/systemtap/wiki/utrace/tests

-- 
Pedro Alves

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

[Oleg Nesterov]

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.

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

Oleg.

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

[Pedro Alves]

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

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

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

[Pedro Alves]

On Tuesday 25 October 2011 18:32:49, Oleg Nesterov wrote:
> On 10/25, Pedro Alves wrote:

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

Ah, okay.

> And it still sends SIGSTOP.  You can use PTRACE_SEIZE.

That I know.  :-)  I was trying to understand what happens
to older gdb's on new kernels, and, if gdb needs to adapt,
and if it needs to detect whether what "flavor" of
PTRACE_ATTACH|DETACH it is talking to.

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

Eh, well, I read some discussions from earlier this year on
lkml proposing that, and I guess I got confused.

> 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?
If not, what happens if the ptracer dies while its child
is PTRACE_CONT'ed, and the child was stopped at PTRACE_ATTACH time?

-- 
Pedro Alves

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

[Oleg Nesterov]

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.

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

[Pedro Alves]

On Tuesday 25 October 2011 19:30:22, Oleg Nesterov wrote:
> On 10/25, Pedro Alves wrote:
> >
> > On Tuesday 25 October 2011 18:32:49, Oleg Nesterov wrote:

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

Ah, cool.

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

Thanks!  All makes sense now.

-- 
Pedro Alves

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

[Jan Kratochvil]

On Fri, 14 Oct 2011 23:25:10 +0200, Jan Kratochvil wrote:
> 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.
> 
> The opposite - the upstream 2.6.x kernel state - was IMO worse, it was resumed
> and one could not safely keep it stopped.

Without going into detail one can reach both states with new kernels, just the
default behavior has changed.

sleep 1h&p=$!;sleep 1;kill -STOP $p;sleep 1;grep ^State /proc/$p/status;./gdb -q -batch -p $p -ex q;sleep 1;grep ^State /proc/$p/status;kill -9 $p
GNU gdb (GDB) 7.3.50.20111016-cvs

kernel-2.6.35.14-96.fc14.x86_64:
State:	T (stopped)
[... - GDB attach+detach]
State:	S (sleeping)

kernel-3.1.0-0.rc6.git0.0.fc17.x86_64
State:	T (stopped)
[... - GDB attach+detach]
State:	T (stopped)


Regards,
Jan