gdbinit.in

gdbinit.in

[david carlton]

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.
This is because, in the .gdbinit that is created in the gdb directory,
the 'dir ./../bfd' command comes later than the 'dir .' command.  This
seems to me to be undesirable behavior; the accompanying patch to
gdbinit.in changes that.

I've moved both 'dir @srcdir@' and 'dir .' to the end of the dir
list.  Certainly I want 'dir @srccdir@' to be towards the end.  I
don't really have a strong opinion about where 'dir .' should be
- honestly, it's not entirely clear to me why it's there at all.
(@srcdir@ is . when I'm configuring this, so I don't see the
difference.)

I didn't worry about running this change through the testsuite, since
it doesn't affect GDB itself and, I assume, it doesn't affect the way 
the testsuite runs.

David Carlton
carlton@math.stanford.edu

2002-07-25  david carlton  <carlton@math.stanford.edu>

	* gdbinit.in: Move dir @srcdir@ and dir . to the end.

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	25 Jul 2002 23:14:58 -0000
*************** commands
*** 10,18 ****
  	return
  end
  
- dir @srcdir@
- dir .
  dir @srcdir@/../mmalloc
  dir @srcdir@/../libiberty
  dir @srcdir@/../bfd
  set prompt (top-gdb) 
--- 10,18 ----
  	return
  end
  
  dir @srcdir@/../mmalloc
  dir @srcdir@/../libiberty
  dir @srcdir@/../bfd
+ dir @srcdir@
+ dir .
  set prompt (top-gdb) 

Re: gdbinit.in

[Jim Blandy]

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.
> This is because, in the .gdbinit that is created in the gdb directory,
> the 'dir ./../bfd' command comes later than the 'dir .' command.  This
> seems to me to be undesirable behavior; the accompanying patch to
> gdbinit.in changes that.
> 
> I've moved both 'dir @srcdir@' and 'dir .' to the end of the dir
> list.  Certainly I want 'dir @srccdir@' to be towards the end.  I
> don't really have a strong opinion about where 'dir .' should be
> - honestly, it's not entirely clear to me why it's there at all.
> (@srcdir@ is . when I'm configuring this, so I don't see the
> difference.)

The directory list maintained by the `dir' command only helps GDB find
source files for code listings.  It doesn't affect the order in which
GDB searches the symtabs for a source file of a given name.  In the
example below, note that, no matter how I have my dir list set up, I
always get the breakpoint in BFD.

$ cat .gdbinit
echo Setting up the environment for debugging gdb.\n

set complaints 1

b internal_error

b info_command
commands
        silent
        return
end

dir /home/jimb/cygnus/src/sourceware/gdb/main/src/gdb
dir .
dir /home/jimb/cygnus/src/sourceware/gdb/main/src/gdb/../mmalloc
dir /home/jimb/cygnus/src/sourceware/gdb/main/src/gdb/../libiberty
dir /home/jimb/cygnus/src/sourceware/gdb/main/src/gdb/../bfd
set prompt (top-gdb) 
$ gdb -nw gdb
GNU gdb 2002-07-16-cvs
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...
Setting up the environment for debugging gdb.
Breakpoint 1 at 0x80f5e74: file /home/jimb/cygnus/src/sourceware/gdb/main/src/gdb/utils.c, line 747.
Breakpoint 2 at 0x8176e08: file /home/jimb/cygnus/src/sourceware/gdb/main/src/gdb/cli/cli-cmds.c, line 184.
(top-gdb) break corefile.c:68
Breakpoint 3 at 0x81809a0: file /home/jimb/cygnus/src/sourceware/gdb/main/src/bfd/corefile.c, line 68.
(top-gdb) $ 
$ cat .gdbinit
echo Setting up the environment for debugging gdb.\n

set complaints 1

b internal_error

b info_command
commands
        silent
        return
end

dir /home/jimb/cygnus/src/sourceware/gdb/main/src/gdb/../mmalloc
dir /home/jimb/cygnus/src/sourceware/gdb/main/src/gdb/../libiberty
dir /home/jimb/cygnus/src/sourceware/gdb/main/src/gdb/../bfd
dir /home/jimb/cygnus/src/sourceware/gdb/main/src/gdb
dir .
set prompt (top-gdb) 
$ gdb -nw gdb
GNU gdb 2002-07-16-cvs
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...
Setting up the environment for debugging gdb.
Breakpoint 1 at 0x80f5e74: file /home/jimb/cygnus/src/sourceware/gdb/main/src/gdb/utils.c, line 747.
Breakpoint 2 at 0x8176e08: file /home/jimb/cygnus/src/sourceware/gdb/main/src/gdb/cli/cli-cmds.c, line 184.
(top-gdb) break corefile.c:68
Breakpoint 3 at 0x81809a0: file /home/jimb/cygnus/src/sourceware/gdb/main/src/bfd/corefile.c, line 68.
(top-gdb) 

I'm not sure how to solve the actual problem you're seeing.  Does it
work to use an absolute path?

Re: gdbinit.in

[david carlton]

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.

Re: gdbinit.in

[Jim Blandy]

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.