Re: [PATCH v2 21/29] Don't resume new threads if scheduler-locking is in effect

[Pedro Alves <pedro@palves.net>]

On 2022-07-21 7:49 p.m., Simon Marchi wrote:

>> diff --git a/gdb/testsuite/gdb.threads/schedlock-new-thread.exp b/gdb/testsuite/gdb.threads/schedlock-new-thread.exp
>> new file mode 100644
>> index 00000000000..8952cb7531c
>> --- /dev/null
>> +++ b/gdb/testsuite/gdb.threads/schedlock-new-thread.exp
>> @@ -0,0 +1,63 @@
>> +# Copyright 2021-2022 Free Software Foundation, Inc.
>> +
>> +# This program is free software; you can redistribute it and/or modify
>> +# it under the terms of the GNU General Public License as published by
>> +# the Free Software Foundation; either version 3 of the License, or
>> +# (at your option) any later version.
>> +#
>> +# This program is distributed in the hope that it will be useful,
>> +# but WITHOUT ANY WARRANTY; without even the implied warranty of
>> +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> +# GNU General Public License for more details.
>> +#
>> +# You should have received a copy of the GNU General Public License
>> +# along with this program.  If not, see <http://www.gnu.org/licenses/>.
>> +
>> +# Test continuing over a thread spawn with scheduler-locking on.
>> +
>> +standard_testfile .c
>> +
>> +set syscalls_src $srcdir/lib/my-syscalls.S
> 
> Is this needed?
> 

Eh.  Copy/pasto.  I've removed it.

>> +
>> +if { [build_executable "failed to prepare" $testfile \
>> +	  [list $srcfile $syscalls_src] {debug pthreads}] == -1 } {
>> +    return
>> +}
>> +


>> +proc test {non-stop schedlock} {
>> +    save_vars ::GDBFLAGS {
>> +	append ::GDBFLAGS " -ex \"set non-stop ${non-stop}\""
>> +	clean_restart $::binfile
>> +    }
>> +
>> +    set linenum1 [gdb_get_line_number "set break 1 here"]
>> +
>> +    if { ![runto $::srcfile:$linenum1] } {
>> +	return
>> +    }
>> +
>> +    delete_breakpoints
>> +
>> +    set linenum2 [gdb_get_line_number "set break 2 here"]
>> +    gdb_breakpoint $linenum2
>> +
>> +    gdb_breakpoint "thread_func"
>> +
>> +    gdb_test_no_output "set scheduler-locking $schedlock"
>> +
>> +    if {$schedlock} {
>> +	gdb_test "continue" \
>> +	    "return 0.*set break 2 here .*" \
>> +	    "continue does not stop in new thread"
>> +    } else {
>> +	gdb_test "continue" \
>> +	    "thread_func .*" \
>> +	    "continue stops in new thread"
>> +    }
> 
> In the non-schedlock case, if you imagine a scheduler that messes with
> you on purpose, wouldn't it be possible for main to hit its breakpoint
> before the thread hits thread_func?  If so, any idea how to change the
> test to avoid that?  Maybe main can join the thread in that case,
> instead of doing a sleep.  The thread would have to not be an infinite
> loop, but I don't see why it needs to be.

Yeah, I assume it would have to be a really nasty scheduler, to not schedule the
other thread for 3 seconds.  I mean, since we already had a sleep for the
schedlock case, I had just gone from simplicity and relied on it for the
non-schedlock case too.

But I can tweak it with a join, for sure.  I just means that we have to compile
two different programs (or use #ifdef).  It's not that bad, actually.  Done.

Pedro Alves