Re: [PATCH] gdb: Don't let SIGWINCH interrupt waiting for remote target

[Andrew Burgess <andrew.burgess@embecosm.com>]

* Simon Marchi <simark@simark.ca> [2020-07-09 12:00:09 -0400]:

> Wow thanks, I didn't expect a patch when I filed the bug report, and especially
> not that fast :).
> 
> > gdb/testsuite/ChangeLog:
> > 
> > 	PR remote/26221
> > 	* gdb.server/connect-resize-quit.exp: New file.
> 
> Does the new test really belong in `gdb.server`?  I would imagine that
> this directory contains tests specific to GDBserver.  This is more a
> test for GDB's remote target.
> 
> > +	# Open a connection to a remote target, but use a port number that is
> > +	# unlikely to actually be in use.  We want this connection to block
> > +	# waiting for a remote so we can test GDB's behaviour in this blocked
> > +	# state.
> > +	gdb_test_no_output "set tcp connect-timeout 2"
> > +
> > +	set timeout_count 0
> > +	while { $timeout_count < 5} {
> > +	    # Try connecting.  This should block waiting for a remote to appear.
> > +	    send_gdb "target remote :0\n"
> 
> What happens when trying to connect to port 0? At first I thought it would try
> to connect to a random port, but that wouldn't make sense (it wouldn't be very
> useful).  I confused that with trying to _bind_ to port 0.
> 
> According to this:
> 
> https://unix.stackexchange.com/questions/180492/is-it-possible-to-connect-to-tcp-port-0
> 
> It will actually try to connect to port 0, but since there's no way of binding
> to port 0, it will never connect.  Smart!
> 
> So it should be fine on Linux, I don't know about other platforms.  I could imagine
> other OSes returning EINVAL or something like that.  We'll see.

I had a number of ideas here, in no particular order:

  - Pick a random port number and hope it doesn't connect to
    anything.  Maybe spot if the port does connect and try different
    port numbers.

  - Write an LD_PRELOAD library that replaces connect/select in order
    to force the return values and errno values I want.  This test
    would probably be Linux only though.

  - Use port 0.  Wasn't sure this would work, but knew 0 wasn't a
    valid port for someone to be listening on, tried it, and it seemed
    to work....

I'm happy to go with any of the above, or maybe a different plan
entirely if there are alternative suggestions....

> 
> > +
> > +	    # Now send a signal to GDB and follow up by sending some other command.
> > +	    set gdb_pid [exp_pid -i [board_info host fileid]]
> 
> GDB's spawn id is available as $gdb_spawn_id.  I don't know which is better between
> that and `[board_info host fileid]`, but I usually get it from
> $gdb_spawn_id.

Good point.  I just copied this code from elsewhere in the testsuite.
I've changed this test to use gdb_spawn_id.

> 
> > +	    remote_exec host "kill -${sig} $gdb_pid"
> > +	    send_gdb "echo xxyyzz\\n\n"
> > +
> > +	    # Now try to figure out what GDB did.
> > +	    set got_timeout false
> > +	    gdb_test_multiple "" "$testname" {
> > +		-re "^target remote :0\r\n:0: Connection timed out\\..*$gdb_prompt $" {
> > +		    # It's possible that we didn't send the signal quickly enough.
> > +		    # Maybe the testing machine is heavily loaded?
> > +		    set got_timeout true
> > +		}
> > +		-re "^target remote :0\r\n:0: Interrupted system call\\.\r\n$gdb_prompt.*xxyyzz.*$gdb_prompt $" {
> > +		    fail "$gdb_test_name (interrupted by $sig)"
> > +		    return
> > +		}
> > +		-re "^target remote :0\r\necho xxyyzz\\\\n\r.:0: Connection timed out.\r\n$gdb_prompt.*xxyyzz.*$gdb_prompt $" {
> > +		    if { $sig == "WINCH" } {
> > +			pass $gdb_test_name
> > +		    } else {
> > +			fail "$gdb_test_name (unexpected timeout)"
> > +		    }
> > +		    return
> > +		}
> > +		-re "^target remote :0\r\nQuit\r\n$gdb_prompt.*xxyyzz.*$gdb_prompt $" {
> > +		    if { $sig == "INT" } {
> > +			pass $gdb_test_name
> > +		    } else {
> > +			fail "$gdb_test_name (unexpected QUIT)"
> > +		    }
> > +		    return
> > +		}
> > +	    }
> 
> I don't remember, what happens if none of the -re match, will that generate
> a FAIL?  I just want to be sure that if GDB outputs something else, we'll
> see a failure.

gdb_test_multiple adds a bunch of default patterns, including a
generic, you reached the prompt pattern that results in an error.  I
tested this by deliberately breaking all my patterns and the test
finishes instantly (no timeouts) and registers some failures.

Thanks,
Andrew