Filename with "./" in breakpoint command

Filename with "./" in breakpoint command

[Vladimir Prus]

Hi,
I just got the following gdb session:

        $ ~/build/gdb-cvs/gdb/gdb tracepoints
        GNU gdb 6.4.50.20051121-cvs
        (gdb) b ./tracepoints.cpp:12
        No source file named ./tracepoints.cpp.
        Breakpoint 1 (./tracepoints.cpp:12) pending.
        (gdb) b tracepoints.cpp:12
        Breakpoint 2 at 0x80483c4: file tracepoints.cpp, line 12.
        (gdb) quit
        $ ls tracepoints.cpp
        tracepoints.cpp

It looks like leading "./" in file name confuses gdb. This "./" thing is
send by KDevelop in some cases. I'm about to fix on KDevelop side just to
make sure it works with gdb 6.4, but actually, this seems like a bug in
gdb. Say, I have two files called util.cpp -- one in current dir, and
another in some library. It's reasonable to use "./util.cpp" to refer to a
file in the current dir, no? So, is this a bug, and should I file it in the
tracker?

- Volodya

Re: Filename with "./" in breakpoint command

[Eli Zaretskii]

> From: Vladimir Prus <ghost@cs.msu.su>
> Date: Sat, 03 Dec 2005 15:55:10 +0300
> 
>         $ ~/build/gdb-cvs/gdb/gdb tracepoints
>         GNU gdb 6.4.50.20051121-cvs
>         (gdb) b ./tracepoints.cpp:12
>         No source file named ./tracepoints.cpp.
>         Breakpoint 1 (./tracepoints.cpp:12) pending.
>         (gdb) b tracepoints.cpp:12
>         Breakpoint 2 at 0x80483c4: file tracepoints.cpp, line 12.
>         (gdb) quit
>         $ ls tracepoints.cpp
>         tracepoints.cpp
> 
> It looks like leading "./" in file name confuses gdb. This "./" thing is
> send by KDevelop in some cases.

What are the actual source file names recorded in the debug info?
Please show us that, and we will be able to reason whether this is a
feature, a bug, or a missing feature.

Re: Filename with "./" in breakpoint command

[Bob Rossi]

On Sat, Dec 03, 2005 at 03:55:10PM +0300, Vladimir Prus wrote:
> 
> Hi,
> I just got the following gdb session:
> 
>         $ ~/build/gdb-cvs/gdb/gdb tracepoints
>         GNU gdb 6.4.50.20051121-cvs
>         (gdb) b ./tracepoints.cpp:12
>         No source file named ./tracepoints.cpp.
>         Breakpoint 1 (./tracepoints.cpp:12) pending.
>         (gdb) b tracepoints.cpp:12
>         Breakpoint 2 at 0x80483c4: file tracepoints.cpp, line 12.
>         (gdb) quit
>         $ ls tracepoints.cpp
>         tracepoints.cpp
> 
> It looks like leading "./" in file name confuses gdb. This "./" thing is
> send by KDevelop in some cases. I'm about to fix on KDevelop side just to
> make sure it works with gdb 6.4, but actually, this seems like a bug in
> gdb. Say, I have two files called util.cpp -- one in current dir, and
> another in some library. It's reasonable to use "./util.cpp" to refer to a
> file in the current dir, no? So, is this a bug, and should I file it in the
> tracker?

For some reason, GDB doesn't seem to be forgiving with relative paths. I
even tried ../dirname/tracepoints.cpp:12 and it doesn't work. There
could be a good reason for this, but I dont know what it is. Why not
give the absolute path when setting a breakpoint? That's what I do. This
is pretty much guarenteed to work.

Bob Rossi

Re: Filename with "./" in breakpoint command

[Bob Rossi]

On Sat, Dec 03, 2005 at 04:17:45PM +0200, Eli Zaretskii wrote:
> > From: Vladimir Prus <ghost@cs.msu.su>
> > Date: Sat, 03 Dec 2005 15:55:10 +0300
> > 
> >         $ ~/build/gdb-cvs/gdb/gdb tracepoints
> >         GNU gdb 6.4.50.20051121-cvs
> >         (gdb) b ./tracepoints.cpp:12
> >         No source file named ./tracepoints.cpp.
> >         Breakpoint 1 (./tracepoints.cpp:12) pending.
> >         (gdb) b tracepoints.cpp:12
> >         Breakpoint 2 at 0x80483c4: file tracepoints.cpp, line 12.
> >         (gdb) quit
> >         $ ls tracepoints.cpp
> >         tracepoints.cpp
> > 
> > It looks like leading "./" in file name confuses gdb. This "./" thing is
> > send by KDevelop in some cases.
> 
> What are the actual source file names recorded in the debug info?
> Please show us that, and we will be able to reason whether this is a
> feature, a bug, or a missing feature.

Eli, I can reproduce this like this,
  tmp/
    one/
      uut.c uut.h
    two/
      uut.c uut.h main.c

If I compile each file in there own directory with -g and then link in
directory two/ and then start GDB from there, the command
  b uut.c:5 works for me and b ./uut.c:5 doesn't. If I compile 
gcc -S uut.c in either directory, the assembly file says the name is
"uut.c". Is there a better way to tell you what the debug info says?

Bob Rossi

Re: Filename with "./" in breakpoint command

[Eli Zaretskii]

> Date: Sat, 3 Dec 2005 09:21:49 -0500
> From: Bob Rossi <bob@brasko.net>
> Cc: Vladimir Prus <ghost@cs.msu.su>, gdb@sources.redhat.com
> 
> > What are the actual source file names recorded in the debug info?
> > Please show us that, and we will be able to reason whether this is a
> > feature, a bug, or a missing feature.
> 
> Eli, I can reproduce this like this,
>   tmp/
>     one/
>       uut.c uut.h
>     two/
>       uut.c uut.h main.c
> 
> If I compile each file in there own directory with -g and then link in
> directory two/ and then start GDB from there, the command
>   b uut.c:5 works for me and b ./uut.c:5 doesn't. If I compile 
> gcc -S uut.c in either directory, the assembly file says the name is
> "uut.c". Is there a better way to tell you what the debug info says?

Yes, there is a better way: type "info sources" inside GDB.

Re: Filename with "./" in breakpoint command

[Bob Rossi]

On Sat, Dec 03, 2005 at 04:54:54PM +0200, Eli Zaretskii wrote:
> > Date: Sat, 3 Dec 2005 09:21:49 -0500
> > From: Bob Rossi <bob@brasko.net>
> > Cc: Vladimir Prus <ghost@cs.msu.su>, gdb@sources.redhat.com
> > 
> > > What are the actual source file names recorded in the debug info?
> > > Please show us that, and we will be able to reason whether this is a
> > > feature, a bug, or a missing feature.
> > 
> > Eli, I can reproduce this like this,
> >   tmp/
> >     one/
> >       uut.c uut.h
> >     two/
> >       uut.c uut.h main.c
> > 
> > If I compile each file in there own directory with -g and then link in
> > directory two/ and then start GDB from there, the command
> >   b uut.c:5 works for me and b ./uut.c:5 doesn't. If I compile 
> > gcc -S uut.c in either directory, the assembly file says the name is
> > "uut.c". Is there a better way to tell you what the debug info says?
> 
> Yes, there is a better way: type "info sources" inside GDB.

O, of course:

(gdb) info sources
/home/bob/tmp/tmp/tmp/tmp/one/uut.c,
/home/bob/tmp/tmp/tmp/tmp/two/uut.c, 
/home/bob/tmp/tmp/tmp/tmp/two/main.c


-file-list-exec-source-files
^done,files=[{file="uut.c",fullname="/home/bob/tmp/tmp/tmp/tmp/one/uut.c"},
             {file="uut.c",fullname="/home/bob/tmp/tmp/tmp/tmp/two/uut.c"},
             {file="main.c",fullname="/home/bob/tmp/tmp/tmp/tmp/two/main.c"}]

Bob Rossi

Re: Filename with "./" in breakpoint command

[Vladimir Prus]

On Saturday 03 December 2005 17:17, Eli Zaretskii wrote:
> > From: Vladimir Prus <ghost@cs.msu.su>
> > Date: Sat, 03 Dec 2005 15:55:10 +0300
> >
> >         $ ~/build/gdb-cvs/gdb/gdb tracepoints
> >         GNU gdb 6.4.50.20051121-cvs
> >         (gdb) b ./tracepoints.cpp:12
> >         No source file named ./tracepoints.cpp.
> >         Breakpoint 1 (./tracepoints.cpp:12) pending.
> >         (gdb) b tracepoints.cpp:12
> >         Breakpoint 2 at 0x80483c4: file tracepoints.cpp, line 12.
> >         (gdb) quit
> >         $ ls tracepoints.cpp
> >         tracepoints.cpp
> >
> > It looks like leading "./" in file name confuses gdb. This "./" thing is
> > send by KDevelop in some cases.
>
> What are the actual source file names recorded in the debug info?
> Please show us that, and we will be able to reason whether this is a
> feature, a bug, or a missing feature.

Here's the DWARF2 entry for the file in question:

<0><213>: Abbrev Number: 1 (DW_TAG_compile_unit)
     DW_AT_stmt_list   : 316
     DW_AT_high_pc     : 0x80483dd
     DW_AT_low_pc      : 0x8048394
     DW_AT_name        : tracepoints.cpp
     
DW_AT_comp_dir    : /home/ghost/Work/Module/kdevelop3.4/languages/cpp/debugger/tests/tracepoints
     DW_AT_producer    : GNU C++ 3.3.5 (Debian 1:3.3.5-13)
     DW_AT_language    : 4      (C++)


- Volodya

Re: Filename with "./" in breakpoint command

[Eli Zaretskii]

> From: Vladimir Prus <ghost@cs.msu.su>
> Date: Mon, 5 Dec 2005 09:53:00 +0300
> Cc: gdb@sources.redhat.com
> 
> On Saturday 03 December 2005 17:17, Eli Zaretskii wrote:
> > > From: Vladimir Prus <ghost@cs.msu.su>
> > > Date: Sat, 03 Dec 2005 15:55:10 +0300
> > >
> > >         $ ~/build/gdb-cvs/gdb/gdb tracepoints
> > >         GNU gdb 6.4.50.20051121-cvs
> > >         (gdb) b ./tracepoints.cpp:12
> > >         No source file named ./tracepoints.cpp.
> > >         Breakpoint 1 (./tracepoints.cpp:12) pending.
> > >         (gdb) b tracepoints.cpp:12
> > >         Breakpoint 2 at 0x80483c4: file tracepoints.cpp, line 12.
> > >         (gdb) quit
> > >         $ ls tracepoints.cpp
> > >         tracepoints.cpp
> > >
> > > It looks like leading "./" in file name confuses gdb. This "./" thing is
> > > send by KDevelop in some cases.
> >
> > What are the actual source file names recorded in the debug info?
> > Please show us that, and we will be able to reason whether this is a
> > feature, a bug, or a missing feature.
> 
> Here's the DWARF2 entry for the file in question:
> 
> <0><213>: Abbrev Number: 1 (DW_TAG_compile_unit)
>      DW_AT_stmt_list   : 316
>      DW_AT_high_pc     : 0x80483dd
>      DW_AT_low_pc      : 0x8048394
>      DW_AT_name        : tracepoints.cpp
>      
> DW_AT_comp_dir    : /home/ghost/Work/Module/kdevelop3.4/languages/cpp/debugger/tests/tracepoints
>      DW_AT_producer    : GNU C++ 3.3.5 (Debian 1:3.3.5-13)
>      DW_AT_language    : 4      (C++)

Thanks.

Looking at symtab.c:lookup_symtab, I see that we simply don't try to
look for anything but the exact match when given a relative file name
such as "./tracepoints.cpp".

I'm not sure this is a bug; the idea of asking the user to chdir into
the right directory and then use "./foo" to distinguish between
several namesake files doesn't sound like a very user-friendly design,
not really a big improvement over asking them to specify a full
absolute file name of the source (in which case it does work for you,
does it?).

Perhaps we should modify the lookup_symtab to not return immediately
after finding the first matching tail (near line 174 in symtab.c), but
instead see if there's more than one match, and if so, ask the user
which one she wants.  What do you think?

Re: Filename with "./" in breakpoint command

[Daniel Jacobowitz]

On Mon, Dec 05, 2005 at 08:39:37PM +0200, Eli Zaretskii wrote:
> Thanks.
> 
> Looking at symtab.c:lookup_symtab, I see that we simply don't try to
> look for anything but the exact match when given a relative file name
> such as "./tracepoints.cpp".
> 
> I'm not sure this is a bug; the idea of asking the user to chdir into
> the right directory and then use "./foo" to distinguish between
> several namesake files doesn't sound like a very user-friendly design,
> not really a big improvement over asking them to specify a full
> absolute file name of the source (in which case it does work for you,
> does it?).
> 
> Perhaps we should modify the lookup_symtab to not return immediately
> after finding the first matching tail (near line 174 in symtab.c), but
> instead see if there's more than one match, and if so, ask the user
> which one she wants.  What do you think?

Or, when the existing lookups have failed for a relative pathname,
canonicalize it and treat it like a full path?

I don't think adding more user interaction at this level is a good idea
- it's too far away from the user commands, in GDB's internals.  It's
been back-burnered for lack of time, but I was working on patches to
handle location lookups returning more than one location; e.g. setting
breakpoints at all locations matching tracepoints.cpp:25.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Filename with "./" in breakpoint command

[Eli Zaretskii]

> 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.

> I don't think adding more user interaction at this level is a good idea
> - it's too far away from the user commands, in GDB's internals.  It's
> been back-burnered for lack of time, but I was working on patches to
> handle location lookups returning more than one location; e.g. setting
> breakpoints at all locations matching tracepoints.cpp:25.

If asking is not a good idea here, I'd prefer that GDB tries to put a
breakpoint on all locations that match the descriptor, yes.

Re: Filename with "./" in breakpoint command

[Daniel Jacobowitz]

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.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Filename with "./" in breakpoint command

[Bob Rossi]

On Mon, Dec 05, 2005 at 11:55:18PM -0500, Daniel Jacobowitz wrote:
> 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 also don't think it makes sense to prompt the user on this issue.
However, unless I'm missing something, I don't think it makes sense to
set multiple breakpoints.

If the user types 'b ./foo.c' then that maps to exactly 1 file. If the
file can be found, we could set the breakpoint. If the file can not be
found, then we should give the error that there is no such file.

Bob Rossi

Re: Filename with "./" in breakpoint command

[Joel Brobecker]

> If the user types 'b ./foo.c' then that maps to exactly 1 file. If the
> file can be found, we could set the breakpoint. If the file can not be
> found, then we should give the error that there is no such file.

To me, it is natural that ./foo.c means foo.c in the current dir, so
should be expande to $cdir/foo.c. So I like Daniel's suggestion.

-- 
Joel

Re: Filename with "./" in breakpoint command

[Andrew STUBBS]

Joel Brobecker wrote:
>>If the user types 'b ./foo.c' then that maps to exactly 1 file. If the
>>file can be found, we could set the breakpoint. If the file can not be
>>found, then we should give the error that there is no such file.
> 
> 
> To me, it is natural that ./foo.c means foo.c in the current dir, so
> should be expande to $cdir/foo.c. So I like Daniel's suggestion.
> 

It would be useful if GDB would strip ./ from the middle of paths. These 
things tend to creep in when pasting paths together and nobody removes 
them because they usually not wrong.

Re: Filename with "./" in breakpoint command

[Eli Zaretskii]

> 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.

Re: Filename with "./" in breakpoint command

[Eli Zaretskii]

> Date: Tue, 6 Dec 2005 06:55:59 -0500
> From: Bob Rossi <bob@brasko.net>
> 
> However, unless I'm missing something, I don't think it makes sense to
> set multiple breakpoints.
> 
> If the user types 'b ./foo.c' then that maps to exactly 1 file. If the
> file can be found, we could set the breakpoint. If the file can not be
> found, then we should give the error that there is no such file.

We are miscommunicating: multiple breakpoints were suggested for the
situation where the user types "b foo.c" and there are more than 1
file in the symtabs whose basename is foo.c.

Re: Filename with "./" in breakpoint command

[Daniel Jacobowitz]

On Tue, Dec 06, 2005 at 10:11:21PM +0200, Eli Zaretskii wrote:
> 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.

Great - then we all agree, except for a tangent on the meaning of
"original problem" ;-)

I was responding to the question Vladimir asked at the start of the
thread:
  http://sourceware.org/ml/gdb/2005-12/msg00035.html

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

We do; use full pathnames.  Vladimir already said he was fixing
kdevelop to not use ./, so I think that's well in hand.  "info sources"
and the MI fullname field will both show the absolute pathname,
including the compilation directory.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Filename with "./" in breakpoint command

[Eli Zaretskii]

> 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).

Re: Filename with "./" in breakpoint command

[Daniel Jacobowitz]

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".

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.

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!

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Filename with "./" in breakpoint command

[Eli Zaretskii]

> Date: Tue, 6 Dec 2005 16:09:00 -0500
> From: Daniel Jacobowitz <drow@false.org>
> 
> 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.

You suggested one alternative: to put a breakpoint in all matching
file names.

> For a user typing "break foo.c:54" we've already agreed on a more
> useful behavior

That's the alternative I was talking about.

Re: Filename with "./" in breakpoint command

[Vladimir Prus]

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

Re: Filename with "./" in breakpoint command

[Daniel Jacobowitz]

On Wed, Dec 07, 2005 at 10:46:54AM +0300, Vladimir Prus wrote:
> > 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.

I'd rather #1.  But, there's a lot of room for what "fine" is. 
Relative only to $cdir?  Relative to the directory search path?

> > 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?

Multiple breakpoints.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Filename with "./" in breakpoint command

[Vladimir Prus]

Daniel Jacobowitz wrote:

> On Wed, Dec 07, 2005 at 10:46:54AM +0300, Vladimir Prus wrote:
>> > 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.
> 
> I'd rather #1.  But, there's a lot of room for what "fine" is.
> Relative only to $cdir?  Relative to the directory search path?

I'd say relatively to $cdir. I just did not though about the second
approach, and I still think $cdir is more intuitive.

- Volodya

Re: Filename with "./" in breakpoint command

[Paul Gilliam]

On Wednesday 07 December 2005 08:40, Vladimir Prus wrote:
> Daniel Jacobowitz wrote:
> 
> > On Wed, Dec 07, 2005 at 10:46:54AM +0300, Vladimir Prus wrote:
> >> > 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.
> > 
> > I'd rather #1.  But, there's a lot of room for what "fine" is.
> > Relative only to $cdir?  Relative to the directory search path?
> 
> I'd say relatively to $cdir. I just did not though about the second
> approach, and I still think $cdir is more intuitive.
> 
> - Volodya

We could still search the path: make up a special starting path-name component to mean 'search the current path'.

Something like .../find/me or @/find/me.

Just a thought.

-=# Paul #=-