From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x343.google.com (mail-wm1-x343.google.com [IPv6:2a00:1450:4864:20::343]) by sourceware.org (Postfix) with ESMTPS id 5A71B3857013 for ; Fri, 10 Jul 2020 13:22:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 5A71B3857013 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=embecosm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=andrew.burgess@embecosm.com Received: by mail-wm1-x343.google.com with SMTP id w3so5894162wmi.4 for ; Fri, 10 Jul 2020 06:22:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=embecosm.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=qTkx7FRrvPKdqYPZzyHs5mkxfBoR7m9bPbX+QNmyfUg=; b=hdjka9A9Fp7llv6IkIQgcggLVkgoNF+0ZJDIFOc7fyC/SGFM7qrE8fh6papn+SSpc8 AVtdBfC4xLj35wCZyMo3v8gmvFEmDs7I6k++6z5aAEGFjkx7hRipVynGEnWNz9MsDFHT RTzi4a51T4DZJ8GX3xCP6vSbD9ggj6jDzlbpk+DuR8+jFqhwRzJQst/v3CC5wTY8KfEy U/SOjM/1rbfPKlk929JvBixn++y+gUkSsxss6vZLPNt71dqtvkGVplPEmOSrKH2oN972 rDMLevITWsfPHvqf6Vg2QokserAv3FPiCIcFPxlY09MC7b/SYsqgYwRDReBcVuALhXtB 6gVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=qTkx7FRrvPKdqYPZzyHs5mkxfBoR7m9bPbX+QNmyfUg=; b=Ku7wK/Z66TCvf+tHElqL7W0gTTwyvHIN8Cv4C5ajq3oOGx+ccz3bzsi1ohfQRHOvxX etA1Gl0CsQq/cK/73KZ/wqvwsI3YmpxAqHCPmHZ/LY0UzV2ZeuUT/KfXSYIXIp8yjLa4 2TQUNj+4nq9PpMErnwzZZ1+XudxFvJQPosK3SOa6/CkVMjJuZykO3/6BkCoTNvvqd+pa Y1sSa8eZkIaLKpbEt5ev0i4yTEK0ZVTjt0ZIZZ5Zqb+S9eIx+RqRqegTlJcTMPrjnedP MuBSGV9aYda7hI66wO/3dal1S0fO5DE4gW137fUKlepQFEq2MXBBh7i+uoAESRZWyvrp SLXg== X-Gm-Message-State: AOAM532qO2WqFRX8RjhuYZrOIRQu5tp1CynZzFj580Jx0EmSB8N+r00V 2aiAatpglxk2CzUbNURZGtXfj/HD3K4= X-Google-Smtp-Source: ABdhPJw9CHS9rvRJoQFqUoM9LOZfeVX0fAfdVzo6nERUWGFCb6QmMZgp8/AYDTI+Voj+wdZC1tj6iw== X-Received: by 2002:a1c:7216:: with SMTP id n22mr5394079wmc.189.1594387336298; Fri, 10 Jul 2020 06:22:16 -0700 (PDT) Received: from localhost (host109-154-20-168.range109-154.btcentralplus.com. [109.154.20.168]) by smtp.gmail.com with ESMTPSA id 26sm9009001wmj.25.2020.07.10.06.22.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 10 Jul 2020 06:22:15 -0700 (PDT) Date: Fri, 10 Jul 2020 14:22:14 +0100 From: Andrew Burgess To: Simon Marchi Cc: gdb-patches@sourceware.org Subject: Re: [PATCH] gdb: Don't let SIGWINCH interrupt waiting for remote target Message-ID: <20200710132214.GH3463@embecosm.com> References: <20200709150228.79385-1-andrew.burgess@embecosm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Linux/5.6.15-200.fc31.x86_64 (x86_64) X-Uptime: 13:45:59 up 32 days, 2:52, X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] X-Spam-Status: No, score=-5.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2020 13:22:18 -0000 * Simon Marchi [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