From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24410 invoked by alias); 27 Feb 2018 00:20:43 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 24391 invoked by uid 89); 27 Feb 2018 00:20:43 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-8.5 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_1,RCVD_IN_DNSWL_LOW,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy= X-HELO: mx1.redhat.com Received: from mx3-rdu2.redhat.com (HELO mx1.redhat.com) (66.187.233.73) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 27 Feb 2018 00:20:41 +0000 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 05B3917CEDA; Tue, 27 Feb 2018 00:20:40 +0000 (UTC) Received: from localhost (unused-10-15-17-196.yyz.redhat.com [10.15.17.196]) by smtp.corp.redhat.com (Postfix) with ESMTP id D9E571C729; Tue, 27 Feb 2018 00:20:39 +0000 (UTC) From: Sergio Durigan Junior To: Pedro Alves Cc: GDB Patches , Simon Marchi Subject: Re: [PATCH v2 2/2] Make gdbserver work with filename-only binaries References: <20180210014241.19278-3-sergiodj@redhat.com> <20180212195733.23639-1-sergiodj@redhat.com> <20180212195733.23639-3-sergiodj@redhat.com> <87f198c5-3963-1c54-ff16-e3dcc8c9e632@redhat.com> Date: Tue, 27 Feb 2018 00:20:00 -0000 Message-ID: <87371n1dwo.fsf@redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2018-02/txt/msg00408.txt.bz2 On Wednesday, February 21 2018, Pedro Alves wrote: > Hi Sergio, > > A few quick comments below. Thanks, Pedro, and sorry for the delay in replying. >> @@ -3539,6 +3564,13 @@ captured_main (int argc, char *argv[]) >> const char *selftest_filter = NULL; >> #endif >> >> + current_directory = getcwd (NULL, 0); >> + if (current_directory == NULL) >> + { >> + warning (_("%s: error finding working directory"), >> + safe_strerror (errno)); > > I think it's much more usual to put the strerror string at the > end of the warning rather than at the beginning. > > I.e., something like: > > warning (_("Could not find working directory: %s"), > safe_strerror (errno)); > > See > > $ (cd gdb; git grep -3 "warning (" *.c | grep strerr -C 3) > > for example. > > From the ongoing discussion, it sounded like this hunk may change > in the next iteration, but I thought I'd still comment as it > may help with future patches. The only change is s/warning/error/, but I can also change the message. >> +# We only test things locally, and on native-gdbserver >> +if { [is_remote target] || [is_remote host] || ![use_gdb_stub] } { >> + return 0 >> +} > > > I don't see why to restrict this to "only on native-gdbserver". The test > is calling gdbserver_start etc. manually, so it should work when testing > with any local board, I think? I.e., when testing with native or > extended-remote too. For the latter, tests will usually call "disconnect". As far as I have tested (and remember), extended-remote doesn't actually start gdbserver by using the binary. Instead, it starts gdbserver without a binary and relies on 'set remote exec-file'. .... (fiddles with testcase) .... Right, I managed to remove this restriction and now the tests runs and passes on other target boards as well. >> + >> +if { [prepare_for_testing "failed to prepare" $testfile $srcfile debug] } { >> + return -1 >> +} >> + >> +set target_exec [gdbserver_download_current_prog] >> +set target_execname [file tail $target_exec] >> +# We temporarily copy the file to our current directory >> +file copy -force $target_exec [pwd] >> +set res [gdbserver_start "" $target_execname] > > Please remind me -- is the current directory here usually > the testcase's output dir? I.e., is it guaranteed that > the current directory here is not going to be the same > directory of another testcase running in parallel at > the same time? No, [pwd] is actually the gdb/testsuite/ directory, from where the Makefile runs. Which means that other tests running in parallel at the same time will have the same value for [pwd]. I copied the file to [pwd] because that's how I solved the problem of having the binary at the same directory as the one I'm starting gdbserver from. Another solution that I thought was to cd into the the dirname of the downloaded $target_exec, execute gdbserver from there, and the cd back to the original directory. WDYT? >> + >> +set gdbserver_protocol [lindex $res 0] >> +set gdbserver_gdbport [lindex $res 1] >> +gdb_target_cmd $gdbserver_protocol $gdbserver_gdbport >> + >> +if { [runto_main] } { >> + pass "load filename without absolute path" >> +} else { >> + fail "load filename without absolute path" >> +} > > runto_main here looks a bit odd to me. You're manually connecting > with gdb_target_cmd, bypassing whatever the current board file > may want to do, but then you're using a routine that call back > into the board file to do random things to prepare for running. > > I think you should set a breakpoint at main and continue to > it without using runto_main. Note how no other test in gdb.server/ > uses runto_main. Ah, OK. I'm usually confused about our testsuite when it comes to remote vs. remote-extended, so thanks for the advice. Thanks, -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/