Re: [PATCH 2/2] Make gdbserver work with filename-only binaries

[Joel Brobecker <brobecker at adacore dot com>]

> 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