This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH master+7.12 v2 3/3] Add test for user context selection sync
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