From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26371 invoked by alias); 12 Feb 2018 19:16:36 -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 26362 invoked by uid 89); 12 Feb 2018 19:16:35 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.6 required=5.0 tests=AWL,BAYES_00,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; Mon, 12 Feb 2018 19:16:32 +0000 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id F24514040850; Mon, 12 Feb 2018 19:16:30 +0000 (UTC) Received: from localhost (unused-10-15-17-193.yyz.redhat.com [10.15.17.193]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D59082166BAE; Mon, 12 Feb 2018 19:16:30 +0000 (UTC) From: Sergio Durigan Junior To: Simon Marchi Cc: GDB Patches , Simon Marchi Subject: Re: [PATCH 2/2] Make gdbserver work with filename-only binaries References: <20180210014241.19278-1-sergiodj@redhat.com> <20180210014241.19278-3-sergiodj@redhat.com> Date: Mon, 12 Feb 2018 19:16:00 -0000 In-Reply-To: (Simon Marchi's message of "Sun, 11 Feb 2018 23:18:27 -0500") Message-ID: <8737269fxt.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/msg00176.txt.bz2 On Sunday, February 11 2018, Simon Marchi wrote: > On 2018-02-09 08:42 PM, Sergio Durigan Junior wrote: >> Simon mentioned on IRC that, after the startup-with-shell feature has >> been implemented on gdbserver, it is not possible to specify a >> filename-only binary, like: >> >> $ gdbserver :1234 a.out >> /bin/bash: line 0: exec: a.out: not found >> During startup program exited with code 127. >> Exiting >> >> This happens on systems where the current directory "." is not listed >> in the PATH environment variable. Although include "." in the PATH >> variable is a possible workaround, this can be considered a regression >> because before startup-with-shell it was possible to use only the >> filename (due to reason that gdbserver used "exec*" directly). >> >> The idea of the patch is to perform a call to "gdb_abspath" and adjust >> the PROGRAM_NAME variable before the call to "create_inferior". This >> adjustment will consist of tilde-expansion or prefixing PROGRAM_NAME >> using the CURRENT_DIRECTORY (a variable that was specific to GDB, but >> has been put into common/common-defs.h and now is set/used by >> gdbserver as well), thus transforming PROGRAM_NAME in an absolute >> path. >> >> This mimicks the behaviour seen on GDB (look at "openp" and >> "attach_inferior", for example). Now, we'll always execute the binary >> using its full path on gdbserver. >> >> I am also submitting a testcase which exercises the scenario described >> above. Because the test requires copying (and deleting) files >> locally, I decided to restrict its execution to non-remote >> targets/hosts. I've also had to do a minor adjustment on >> gdb.server/non-existing-program.exp's regexp in order to match the >> correct error message. > > Hi Sergio, Hey, Simon, > The behavior is still different than for GDB (and previous gdbservers), in > the case where you specify a filename-only binary that is found in PATH. For > example, try "gdb ls" and/or "gdbserver ls". The expected behavior is to > search for a file with this name in the current directory, and if there isn't > one, to search in the PATH. This is what openp does when OPF_TRY_CWD_FIRST > is passed. Ah, I guess I didn't consider this (obvious) scenario for gdbserver. I was thinking that gdbserver (before the startup-with-shell feature) would not work with binaries in PATH... > Bringing openp to gdbserver may not be easy nor desirable, since it supports > some concepts that don't exist in gdbserver (like $-variables). Also, we would > not really want to open the file in this case, only see if it exists. Yeah, it crossed my mind to move openp to common, but it's not a trivial task as you pointed. > I didn't think this through completely, but maybe we could do something simpler, > if the program_name doesn't contain a directory separator and the file exists in > the current working directory, we add "./" in front of it when passing it to the > shell? I think all three use cases would work: > > - gdbserver :1234 foo (foo in current directory) > - gdbserver :1234 foo (foo in PATH) > - gdbserver :1234 ./foo So, what do you think of checking if the file exists in the CWD (and is executable), and prefixing it with current_directory, as I'm doing with this patch? I personally prefer to be more verbose, so using the full path is better IMHO than just adding "./". 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/