From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 108024 invoked by alias); 8 Feb 2018 16:28:17 -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 108009 invoked by uid 89); 8 Feb 2018 16:28:17 -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=grossly, communication 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:28:15 +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 w18GS8Ac002147 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 8 Feb 2018 11:28:13 -0500 Received: by simark.ca (Postfix, from userid 112) id 6A14E1E74E; Thu, 8 Feb 2018 11:28:08 -0500 (EST) Received: from simark.ca (localhost [127.0.0.1]) by simark.ca (Postfix) with ESMTP id 9B8B81E093; Thu, 8 Feb 2018 11:28:07 -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:28:00 -0000 From: Simon Marchi To: Dmitry Antipov Cc: GDB Development Subject: Re: Testing with remote gdbserver In-Reply-To: <1eca7308-60e6-5c39-1eae-1f9dc1c034f1@nvidia.com> References: <1eca7308-60e6-5c39-1eae-1f9dc1c034f1@nvidia.com> Message-ID: <1d63145a1dba01bce9608c232d459a0c@polymtl.ca> 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:28:08 +0000 X-IsSubscribed: yes X-SW-Source: 2018-02/txt/msg00080.txt.bz2 On 2018-02-08 09:29, Dmitry Antipov wrote: > Hello, > > are there any known-to-work board configuration files to test > gdbserver remotely? > After reading https://sourceware.org/gdb/wiki/TestingGDB, I supposed > that this > has to be relatively simple, at least between two GNU/Linux x86 > machines with public > key-based ssh access between them. But, since I just have a) noise > about missing 'runtest' > (which is /usr/bin/runtest in my $PATH), b) a lot of FAILED messages > (probably due to > communication timeouts) and c) time-to-time zombie ssh processes, I > assume that my setup > is grossly misconfigured at some non-obvious but very important point. > I've started > from example remote board file taken from "Testing gdbserver in a > remote cross-target > configuration" of the above and tried some tweaks, but still have no > PASSes (except > for local libiberty tests). Is it possible to run the tests in a "much > more verbose" > mode to check what's going on? > > Thanks in advance, > Dmitry 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