This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: gdbinit.in
I think I like your original patch best. I'll commit that.
david carlton <carlton@math.Stanford.EDU> writes:
> On 26 Jul 2002 12:17:47 -0500, Jim Blandy <jimb@redhat.com> said:
> > david carlton <carlton@math.stanford.edu> writes:
>
> >> When debugging GDB, if I'm looking at a function in corefile.c, it
> >> finds the one in bfd/corefile.c rather than the one in
> >> gdb/corefile.c.
>
> > The directory list maintained by the `dir' command only helps GDB
> > find source files for code listings.
>
> My apologies for being unclear; that's what I was referring to. (I
> should know better than to submit such a vague bug report.)
>
> If, from within the GDB source directory, I do
>
> $ gdb gdb
> (top-gdb) dir ./../bfd
> (top-gdb) b read_memory
> (top-gdb) run gdb
>
> I get a bunch of output and then
>
> Breakpoint 3, read_memory (memaddr=135224950, myaddr=0x828b92c "", len=1)
> at corefile.c:236
> Line number 236 out of range; corefile.c has 105 lines.
>
> Whereas if I do
>
> $ gdb gdb
> (top-gdb) dir .
> (top-gdb) b read_memory
> (top-gdb) run gdb
>
> I get a bunch of output and then
>
> Breakpoint 3, read_memory (memaddr=135224950, myaddr=0x828b92c "", len=1)
> at corefile.c:236
> 236 status = target_read_memory (memaddr, myaddr, len);
>
>
> Now I've investigated this some more, and I'm even more confused.
>
> * Either a binary contains complete paths for its source files in its
> debugging information, or it doesn't.
>
> * If it does, then using 'dir' is rarely likely to be a good idea.
> The binary contains the correct information; dir might tell GDB to
> mistakenly look in the wrong directory. This occurs in the first
> example above. (I'm not sure whether or not I think it's a good
> idea for GDB to look in location listed in the binary before
> searching the directories specified by 'dir', but that seems to me
> to be worth considering. Given the info node (gdb)Source Path,
> though, I suspect that idea has been considered and rejected.)
>
> * On my computer, it would seem that the debugging information _does_
> contain full pathnames. So the best situation for me personally is
> to remove all of the dir commands from .gdbinit (and from
> gdbinit.in).
>
> * If, on most people's computers, the debugging information does
> contain full pathnames, then I think we should remove all of the dir
> command from gdbinit.in. (Patch below my signature.) Otherwise, if
> configure can auto-detect whether the debugging information is rich
> enough, then the dir commands should only be included conditionally.
>
> * In the unfortunate situation where debugging information doesn't
> contain full pathnames, the dir lines are useful. In this case, the
> question is: if a file name occurs in both the GDB directory and
> another directory, are people debugging GDB more likely to encounter
> code in the file in the GDB directory or the other directory? My
> guess is that the answer is "the GDB directory"; in that case, the
> command 'dir @srcdir@' should be moved further down in gdbinit.in,
> as my previous patch suggested.
>
> * For what it's worth,
>
> for file in *.c *.h
> do ls ../{mmalloc,libiberty,bfd}/$file
> done 2>&1| grep -v 'No such file or directory'
>
> from within the GDB directory turns up
>
> ../bfd/corefile.c
> ../bfd/init.c
> ../bfd/config.h
> ../libiberty/config.h
> ../bfd/version.h
>
> So there aren't a whole lot of clashes.
>
> * And yes, I do realize that, as bugs go, this isn't a particularly
> serious one...
>
> David Carlton
> carlton@math.stanford.edu
>
> Index: gdbinit.in
> ===================================================================
> RCS file: /cvs/src/src/gdb/gdbinit.in,v
> retrieving revision 1.1.1.2
> diff -c -p -r1.1.1.2 gdbinit.in
> *** gdbinit.in 16 Aug 1999 19:52:40 -0000 1.1.1.2
> --- gdbinit.in 26 Jul 2002 17:59:56 -0000
> *************** commands
> *** 10,18 ****
> return
> end
>
> - dir @srcdir@
> - dir .
> - dir @srcdir@/../mmalloc
> - dir @srcdir@/../libiberty
> - dir @srcdir@/../bfd
> set prompt (top-gdb)
> --- 10,13 ----
>
> 2002-07-26 david carlton <carlton@math.stanford.edu>
>
> * gdbinit.in: Removed all dir commands.