Re: [PATCH master+7.12 v2 3/3] Add test for user context selection sync

[Simon Marchi <simon.marchi@ericsson.com>]

On 16-09-21 02:29 PM, Simon Marchi wrote:
>> What I've done in the past is something very much like your breakpoints
>> idea.  Though, instead of a thread-specific breakpoint, I used a normal
>> breakpoint + "set scheduler-locking on" to control which thread got to
>> the breakpoint.  See multiple-step-overs.exp, for example.
>> Using a thread-specific breakpoint maybe makes that a little simpler,
>> worth a try.
> 
> I'll try and send an updated patch if it works.

After messing with this for a while, I think I'll give up for now, unless you
think having that sleep in there is out of the question.  I have been trying to
do roughly this (all-stop mode):

 1. Start inferior 1, break when the two child threads are started.
 2. Setup two thread specific breakpoints (for the two child threads) at the target line.
 3. Do continue twice in a row.

For the first inferior, I get two stops, as expected, because of the two threads
hitting their breakpoint.  For the second inferior, the first "continue" stops, but
the second doesn't, it just hangs forever.  Inspecting the state of the threads at
this moment shows that the thread that did not hit his breakpoint is past it, so it
somehow missed it.  It sounds like a bug in GDB.  I'll try to make a reproducer, but
I don't think the present test should be blocked because of that.

Simon