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

[Simon Marchi <simon dot marchi at ericsson dot com>]

On 16-09-21 12:40 PM, Pedro Alves wrote:
>> Oops, while trying to rerun the full testsuite, I noticed that it leaves
>> "-ex \"set non-stop 1\"" in the GDBFLAGS... that's not good.  You can
>> see it easily if you swap the order of the "all-stop" and "non-stop"
>> variations.  Can you spot why the save_vars isn't working as intended? 
>> When I use a temporary variable instead, it works as intended...
> 
> Did you ever figure this out?

As you found and mentioned on IRC, it was a stray invisible character:

save_vars { <stray>GDBFLAGS } {
  ...
}

The result was that <stray>GDBFLAGS was saved, instead of GDBFLAGS...  I
would have searched for so long, so thanks a lot!

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

>>> gdb_test_multiple ?
>>
>> Like this?
>>
>>     set test "interrupt thread $inf.2"
>>
>>     send_gdb "interrupt\n"
>>     gdb_test_multiple "" $test {
>>         -re "Thread.*2.*stopped" {
>>             pass $test
>>         }
>>     }
> 
> No need for the separate send_gdb call:
> 
>      set test "interrupt thread $inf.2"
>      gdb_test_multiple "interrupt" $test {
>          -re "Thread.*2.*stopped" {
>              pass $test
>          }
>      }

Yep, it works fine with that.

>> I think that will go in the same basket as the fact that any MI command
>> with --thread currently changes the selected thread silently (without
>> any =thread-selected event).  Currently, --thread changes the thread tot
>> he desired one, then when the mi_cmd_thread_select tries to change the
>> thread, it thinks that it was already the current thread, so that an
>> event isn't necessary.  This should get fixed in the next iteration,
>> when we split the concepts of user-selected-ptid and
>> internally-selected-ptid.  Specifying --thread won't mess with the
>> user-selected-ptid, but if you do "-thread-select --thread 2 2", then
>> mi_cmd_thread_select will change the user-selected-ptid, generating an
>> event.
>>
>> It's not pretty to leave it like this in the test though.  Should I
>> create a bug right now and kfail it?  Leave it commented out but put a
>> better description?
> 
> There's no right or wrong answer, but since you've already written the 
> bits, I'd be inclined to file bug and kfail.

Ok I'll do that.

Thanks,

Simon