From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 116452 invoked by alias); 8 Feb 2018 16:31:01 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 116271 invoked by uid 89); 8 Feb 2018 16:30:54 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-25.0 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy= X-HELO: smtp.polymtl.ca Received: from smtp.polymtl.ca (HELO smtp.polymtl.ca) (132.207.4.11) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 08 Feb 2018 16:30:53 +0000 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id w18GUkGA003651 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 8 Feb 2018 11:30:51 -0500 Received: by simark.ca (Postfix, from userid 112) id E75301E757; Thu, 8 Feb 2018 11:30:46 -0500 (EST) Received: from simark.ca (localhost [127.0.0.1]) by simark.ca (Postfix) with ESMTP id 046EA1E093; Thu, 8 Feb 2018 11:30:45 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 08 Feb 2018 16:31:00 -0000 From: Simon Marchi To: Dmitry Antipov Cc: GDB Development Subject: Re: Testing with remote gdbserver In-Reply-To: <1d63145a1dba01bce9608c232d459a0c@polymtl.ca> References: <1eca7308-60e6-5c39-1eae-1f9dc1c034f1@nvidia.com> <1d63145a1dba01bce9608c232d459a0c@polymtl.ca> Message-ID: X-Sender: simon.marchi@polymtl.ca User-Agent: Roundcube Webmail/1.3.4 X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Thu, 8 Feb 2018 16:30:47 +0000 X-IsSubscribed: yes X-SW-Source: 2018-02/txt/msg00081.txt.bz2 On 2018-02-08 11:28, Simon Marchi wrote: > The remote-stdio-gdbserver.exp board should work, but be aware of this > issue that was reported recently: > > https://sourceware.org/ml/gdb/2018-01/msg00023.html > > I just tried it and stumbled on another bug, if you are using > gdb/gdbserver 8.1. You might get something like this in gdb.log: > > (gdb) target remote | /usr/bin/ssh simark@s.thetu.bz > /usr/bin/gdbserver --once stdio jump > Remote debugging using | /usr/bin/ssh simark@s.thetu.bz > /usr/bin/gdbserver --once stdio jump > stdin/stdout redirected > zsh:1: command not found: jump > During startup program exited with code 127. > > This is likely caused by the fact that gdbserver now starts (by > default) the inferior process through a shell. If you run "gdbserver > ... jump", it will try to run the "jump" command through the shell, > which is not found because it's not in the path. I worked around it > by doing this simple change: > > diff --git a/gdb/testsuite/boards/remote-stdio-gdbserver.exp > b/gdb/testsuite/boards/remote-stdio-gdbserver.exp > index aff7902..3e01d1b 100644 > --- a/gdb/testsuite/boards/remote-stdio-gdbserver.exp > +++ b/gdb/testsuite/boards/remote-stdio-gdbserver.exp > @@ -70,7 +70,7 @@ proc get_remote_login { } { > proc get_target_remote_pipe_cmd { } { > set target_exec [gdbserver_download_current_prog] > set rsh_cmd "[board_info [target_info name] rsh_prog] > [get_remote_login]" > - return "$rsh_cmd /usr/bin/gdbserver --once stdio $target_exec" > + return "$rsh_cmd /usr/bin/gdbserver --once stdio ./$target_exec" > } > > proc ${board}_file { dest op args } { > > > With this I'm able to test using a remote gdbserver between two x86 > machines (though note that it uses the gdbserver on the target > machine, the testsuite doesn't upload it itself). > > Simon For reference, here's the command line I used (replace example.com with the appropriate hostname/ip, of course): make check TESTS="gdb.base/jump.exp" RUNTESTFLAGS="--target_board=remote-stdio-gdbserver REMOTE_USERNAME=simark REMOTE_HOSTNAME=example.com" Simon