Re: [PATCH] gdb: better handling of 'S' packets

[Simon Marchi via Gdb-patches <gdb-patches@sourceware.org>]

On 2021-01-07 7:51 p.m., Pedro Alves wrote:
>> +
>> +    gdb_breakpoint "unlock_worker"
>> +    gdb_continue_to_breakpoint "run to unlock_worker"
>> +
>> +    # There should be two threads at this point with thread 1 selected.
>> +    gdb_test "info threads" \
>> +	"\\\* 1\[\t \]*Thread\[^\r\n\]*\r\n  2\[\t \]*Thread\[^\r\n\]*" \
>> +	"second thread should now exist"
>> +
>> +    # Switch threads.
>> +    gdb_test "thread 2" ".*" "switch to second thread"
>> +
>> +    # Single step.  This will set all threads running but as there's
>> +    # no reason for the first thread to report a stop we expect to
>> +    # finish the step with thread 2 still selected.
> 
> I think GDB will first switch to thread 1 to step over the breakpoint thread 1
> is stopped at and only after will it step thread 2 while letting thread 1 run free.
> I think that with your patch GDB will do the "right" thing and figure out the
> right thread for the first step stop of thread 1 correctly, since at that point
> no other thread is executing.  It's just that the comment seems a bit off.
> 
v2 uses scheduler-locking, I suppose to address that.


>> +    gdb_test_multiple "stepi" "" {
>> +	-re "Thread 1 received signal SIGTRAP" {
> 
> Shouldn't this consume the prompt?

Is it important?  We could probably just omit it and let gdb_test_multiple
time out if it doesn't see what we expect?

> 
>> +	    fail $gdb_test_name
>> +	}
>> +	-re "$hex.*$decimal.*while \\(worker_blocked\\).*$gdb_prompt" {
>> +	    pass $gdb_test_name
>> +	}
>> +    }
>> +
>> +    # Double check that thread 2 is still selected.
>> +    gdb_test "info threads" \
>> +	"  1\[\t \]*Thread\[^\r\n\]*\r\n\\\* 2\[\t \]*Thread\[^\r\n\]*" \
>> +	"second thread should still be selected after stepi"
>> +
>> +    # Now "continue" thread 2.  Again there's no reason for thread 1
>> +    # to report a stop so we should finish with thread 2 still
>> +    # selected.
> 
> Ditto here.

This also changed in v2, the test now lets both threads and the program
run until the end.

I tried to address all your comments that still apply in the version
I'll send.

Simon