Re: gdbinit.in

[Jim Blandy <jimb@redhat.com>]

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.