Re: Filename with "./" in breakpoint command

[Eli Zaretskii <eliz@gnu.org>]

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