Re: schedlock.exp questions

[Orjan Friberg <orjan.friberg@axis.com>]

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