From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 36774 invoked by alias); 21 Feb 2018 08:05:45 -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 36748 invoked by uid 89); 21 Feb 2018 08:05:44 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: rock.gnat.com Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 21 Feb 2018 08:05:43 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id C3E17116141; Wed, 21 Feb 2018 03:05:41 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id qasxSyqAIT5w; Wed, 21 Feb 2018 03:05:41 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 5A9FF11613D; Wed, 21 Feb 2018 03:05:41 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 058F883054; Wed, 21 Feb 2018 12:05:37 +0400 (+04) Date: Wed, 21 Feb 2018 08:05:00 -0000 From: Joel Brobecker To: Sergio Durigan Junior Cc: Simon Marchi , GDB Patches , Simon Marchi Subject: Re: [PATCH 2/2] Make gdbserver work with filename-only binaries Message-ID: <20180221080536.4kg3avdend5en4ko@adacore.com> References: <20180210014241.19278-1-sergiodj@redhat.com> <20180210014241.19278-3-sergiodj@redhat.com> <8737269fxt.fsf@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8737269fxt.fsf@redhat.com> User-Agent: NeoMutt/20170113 (1.7.2) X-SW-Source: 2018-02/txt/msg00285.txt.bz2 > 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... It would, but it would be at the discretion of each target implementation. linux-low was doing it by calling execv first, which doesn't search the PATH, and then calling execvp if the first execv call failed with a "not found" error. > > 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 "./". I agree with Simon that we shouldn't (and don't really need to) touch the file when it contains some directory information in it. As far as I can tell, it already works as is, both with and without shell startup. $ gdbserver --once :4444 simple/simple_main Process simple/simple_main created; pid = 15400 Listening on port 4444 $ gdbserver --no-startup-with-shell --once :4444 simple/simple_main Process simple/simple_main created; pid = 15432 Listening on port 4444 So, I think the only case that we need to worry about is the case where exec_file is a basename. For that, I think the following test should be sufficient: if (lbasename (exec_file) == exec_file) ... If it returns anything else than exec file, it's either a full path, or a relative path with some directory information in it. I agree with you, Sergio, that I think that expanding to the absolute path would be cleaner. I'm not sure whether adding "." + SLASH_STRING is going to work everywhere... I'd rather not ask myself the question, and just expand to a full path, since you've done the work to do it anyways. -- Joel