Re: schedlock.exp questions

[Orjan Friberg <orjan dot friberg at axis dot com>]

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