Re: Filename with "./" in breakpoint command

[Vladimir Prus <ghost@cs.msu.su>]

Daniel Jacobowitz wrote:

> On Tue, Dec 06, 2005 at 11:02:20PM +0200, Eli Zaretskii wrote:
>> > Date: Tue, 6 Dec 2005 15:17:19 -0500
>> > From: Daniel Jacobowitz <drow@false.org>
>> > 
>> > > I'd prefer to have a better solution to the original problem.
>> > 
>> > We do; use full pathnames.
>> 
>> I thought Vladimir didn't like it (and neither do I, frankly).
> 
> What else is there?  Not a rhetorical question, I just don't see any
> alternative.  Well, we could invent unique identifers "gdb-file-1186",
> "gdb-file-1187".

Ehm.. why? What's wrong with properly resolving relative paths?

> Vladimir's original report is for communication from an IDE to GDB.
> "Find the best match" and "ask the user" aren't very helpful; the IDE
> needs to unambiguously specify what file it's already opened and is
> showing to the user, in a way that GDB can understand precisely what
> file is meant.  Absolute pathnames seem awfully convenient for that.

Yes. I've just suggested that not supporting relative paths can be not very
convenient for those directly using console interface. Especially when you
say "break ./tracepoint.cpp:NNN", gdb suggests that this file might be in
shared library that's no loaded yet, which can confuse users even more.

I think either:

   1. Relative paths should be handled fine, or
   2. Relative paths should produce a warning from gdb.

> For a user typing "break foo.c:54" we've already agreed on a more
> useful behavior - though no promises when it will be implemented!

Which one is that? Setting breakpoint on each file matching foo.c, or
prompting?

- Volodya