Re: Filename with "./" in breakpoint command

[Eli Zaretskii <eliz@gnu.org>]

> Date: Mon, 5 Dec 2005 23:55:18 -0500
> From: Daniel Jacobowitz <drow@false.org>
> Cc: Vladimir Prus <ghost@cs.msu.su>, gdb@sources.redhat.com
> 
> On Tue, Dec 06, 2005 at 06:27:37AM +0200, Eli Zaretskii wrote:
> > > Date: Mon, 5 Dec 2005 13:55:56 -0500
> > > From: Daniel Jacobowitz <drow@false.org>
> > > Cc: Vladimir Prus <ghost@cs.msu.su>, gdb@sources.redhat.com
> > > 
> > > Or, when the existing lookups have failed for a relative pathname,
> > > canonicalize it and treat it like a full path?
> > 
> > I don't like that, since it requires to chdir to some directory first.
> 
> Could you explain why not?  GDB already has a notion of $cdir, and it
> seems logical to me that if the user types "./foo.c" they mean for that
> to be relative to $cdir, but I certainly could be missing something.

I didn't say that "./foo.c" shouldn't resolve to the file in the
current working directory, I'm saying that it is not, IMHO, a good
solution of the original problem.

The original problem was _not_ that "./foo.c" didn't do what the user
expected; "./foo.c" was an attempt of _solving_ a problem.  And the
problem the OP tried to solve was that there were several source files
linked into the executable, each one in its own directory.

I don't like telling the user to go to some directory to solve that
original problem.  For starters, it requires the user to type the full
name of the directory, which is almost like asking them to type the
full file name of the source file.

I'd prefer to have a better solution to the original problem.