schedlock.exp questions

schedlock.exp questions

[Orjan Friberg]

I'm having problems with my upcoming CRISv32 target on schedlock.exp 
that I can't figure out (the existing CRIS target is all PASS).  (For 
reference, the CRIS target has software single-step and is running Linux 
2.4.22; the CRISv32 target has hardware single-step and is running Linux 
2.6.6.)

 From what I've understood from looking at the remote communication, 
"set scheduler-locking off/on" just translates into whether the vCont 
packet specifies a default action for the other threads.

First off, the "step without lock does not change thread" test doesn't 
make any sense to me.  If we're stepping without scheduling lock, then 
isn't the thread *allowed* to change?  Unless I've misunderstood, 
shouldn't both "changed thread" and "didn't change thread" be OK in this 
case?

Second, if the thread *did* change when it shouldn't (when the sheduling 
lock is on), wouldn't it make sense to continue with whatever thread we 
end up with?  Like this:

  if {$curthread == $newthread} {
      pass "continue with lock does not change thread"
  } else {
      fail "continue with lock does not change thread (switched to 
thread $newthread)"
+    # If the thread changed, well, we have to live with that.
+    set curthread $newthread
}

-- 
Orjan Friberg
Axis Communications

Re: schedlock.exp questions

[Daniel Jacobowitz]

On Tue, Aug 24, 2004 at 04:51:13PM +0200, Orjan Friberg wrote:
> I'm having problems with my upcoming CRISv32 target on schedlock.exp 
> that I can't figure out (the existing CRIS target is all PASS).  (For 
> reference, the CRIS target has software single-step and is running Linux 
> 2.4.22; the CRISv32 target has hardware single-step and is running Linux 
> 2.6.6.)
> 
> From what I've understood from looking at the remote communication, 
> "set scheduler-locking off/on" just translates into whether the vCont 
> packet specifies a default action for the other threads.
> 
> First off, the "step without lock does not change thread" test doesn't 
> make any sense to me.  If we're stepping without scheduling lock, then 
> isn't the thread *allowed* to change?  Unless I've misunderstood, 
> shouldn't both "changed thread" and "didn't change thread" be OK in this 
> case?

No.  The request was "single-step this thread, but allow other threads
to run while you do it".  Other threads might report a breakpoint (not
possible in this testcase), but they shouldn't report a single-step
trap - they shouldn't singlestep.

This is a kind of wacky behavior but it's historical.  We could support
single-step-all-threads but we don't now.

> Second, if the thread *did* change when it shouldn't (when the sheduling 
> lock is on), wouldn't it make sense to continue with whatever thread we 
> end up with?  Like this:
> 
>  if {$curthread == $newthread} {
>      pass "continue with lock does not change thread"
>  } else {
>      fail "continue with lock does not change thread (switched to 
> thread $newthread)"
> +    # If the thread changed, well, we have to live with that.
> +    set curthread $newthread
> }

No opinion.

-- 
Daniel Jacobowitz

Re: schedlock.exp questions

[Orjan Friberg]

Daniel Jacobowitz wrote:
> 
> No.  The request was "single-step this thread, but allow other threads
> to run while you do it".  Other threads might report a breakpoint (not
> possible in this testcase), but they shouldn't report a single-step
> trap - they shouldn't singlestep.

Thanks for clarifying.  Would you mind explaining the "not possible in 
this testcase" part?  I do get spurious SIGTRAPs for the other threads 
from the "break 41 if arg != 5" breakpoint, reported as SIGTRAP (instead 
of as breakpoint hits).

Strangely enough, for the CRIS target (the above refers to CRISv32) I
*also* get breakpoint hits from "break 41 if arg != 5" for the other 
threads also (noticed by inspecting the remote communication), but these 
are ignored by GDB (neither displayed as breakpoint hits, nor as SIGTRAPs).

This is all when stepping without a lock, BTW.

Any insight as to what's going on is greatly appreciated.

-- 
Orjan Friberg
Axis Communications

Re: schedlock.exp questions

[Daniel Jacobowitz]

On Wed, Aug 25, 2004 at 05:10:37PM +0200, Orjan Friberg wrote:
> Daniel Jacobowitz wrote:
> >
> >No.  The request was "single-step this thread, but allow other threads
> >to run while you do it".  Other threads might report a breakpoint (not
> >possible in this testcase), but they shouldn't report a single-step
> >trap - they shouldn't singlestep.
> 
> Thanks for clarifying.  Would you mind explaining the "not possible in 
> this testcase" part?  I do get spurious SIGTRAPs for the other threads 
> from the "break 41 if arg != 5" breakpoint, reported as SIGTRAP (instead 
> of as breakpoint hits).

What should happen is:
  - we stop all threads
  - we see that a thread has hit this breakpoint
  - we check that this breakpoint should stop
    - it shouldn't!  condition is false!
  - we singlestep this thread past the breakpoint
  - we resume

This is a twisty and nasty part of infrun.  It is full of bugs and
things that need to be rearchitected.  So it's quite likely it doesn't
work right.

Is this native or remote (gdbserver based)?  I have some patches which
make it substantially more reliable on slow native targets but I
haven't had enough time to test them properly.  They shouldn't affect
remote though.

-- 
Daniel Jacobowitz

Re: schedlock.exp questions

[Orjan Friberg]

Daniel Jacobowitz wrote:
> 
> This is a twisty and nasty part of infrun.  It is full of bugs and
> things that need to be rearchitected.  So it's quite likely it doesn't
> work right.

Ok, I think I got the hang of it now.  (Apologies if my ramblings below 
are a tad long-winded.)

The actual problem for CRISv32 is that the SIGTRAPs resulting from the 
"break 41 if arg!=5" breakpoint for the other threads aren't ignored, 
and that seems to be due to that it's using hardware single-step.

This what happens: in schedlock.exp, after the first "break 41 if arg != 
5" breakpoint is hit, all breakpoints are removed.  When we step the 
current thread afterwards, the other threads all have a pending SIGTRAP 
(since they also hit that same (now removed) breakpoint).  At this point 
we reach the following code (infrun.c:handle_inferior_event):

/* See if a thread hit a thread-specific breakpoint that was meant for
    another thread.  If so, then step that thread past the breakpoint,
    and continue it.  */

The variable thread_hop_needed determines if we should ignore the 
breakpoint hit and just move on (which I guess is what we want to do 
here).  thread_hop_needed is set if:

* there's a breakpoint at the current location, and it's set for another 
thread (not applicable in this case; the SIGTRAP comes from a now 
removed breakpoint)

or

* we're software single-stepping, and the stopped ptid doesn't match the 
single-step ptid (which is what saves CRIS, having software single-step).

Obviously there is some logic missing to handle this case (using 
hardware single-step).  I tried to add a third condition for setting 
thread_hop_needed, using currently_stepping (ecs) and 
!breakpoints_inserted, but that was too inclusive.  Question is whether 
that is the right approach at all - after all, an i686-pc-linux-gnu host 
doesn't need it.

> Is this native or remote (gdbserver based)?  I have some patches which
> make it substantially more reliable on slow native targets but I
> haven't had enough time to test them properly.  They shouldn't affect
> remote though.

This is a gdbserver based remote target.

-- 
Orjan Friberg
Axis Communications

Re: schedlock.exp questions

[Orjan Friberg]

Orjan Friberg wrote:
> Daniel Jacobowitz wrote:
> 
>>
>> This is a twisty and nasty part of infrun.  It is full of bugs and
>> things that need to be rearchitected.  So it's quite likely it doesn't
>> work right.

I did some more thinking, and maybe what you suggest does apply here. 
The logic of it escapes me at least:

* Breakpoint is set
* Breakpoint is hit (by all threads)
* Some random thread (?) is reported by the gdbserver as stopped
* Breakpoint is deleted (leaving the other threads with a pending(*) 
SIGTRAP)

Now, if a software single-step architecture (CRIS) is stepped, the 
pending SIGTRAPs are reported by the gdbserver, but because we are 
single-stepping thread_hop_needed is set in handle_inferior_event, 
making GDB ignore the signal.  Eventually, when the single-step target 
is reached, we'll stop.

However, if we issue a "continue" instead of a "step", the SIGTRAPs are 
*not* ignored, and GDB will show us as stopped due to a SIGTRAP at the 
now removed breakpoint for each of the threads.  I fail to see why the 
behaviour in these two cases should be different.  Is it because we 
can't stop half-way through an ongoing software single-step?

For a hardware single-step architecture (CRISv32), the behaviour will be 
the same regardless of whether we "step" or "continue" - GDB will stop 
when the SIGTRAPs are received by the gdbserver.

(*) pending in the sense that gdbserver hasn't informed GDB of it yet

-- 
Orjan Friberg
Axis Communications

Re: schedlock.exp questions

[Orjan Friberg]

Daniel Jacobowitz wrote:
> 
> Is this native or remote (gdbserver based)?  I have some patches which
> make it substantially more reliable on slow native targets but I
> haven't had enough time to test them properly.  They shouldn't affect
> remote though.

If you think it could have anything at all to do with it, I'd be happy 
to try out your patches.  (Though I don't know where "slow" fits into 
the equation, it most surely applies to my remote target.)

-- 
Orjan Friberg
Axis Communications