From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12589 invoked by alias); 30 Jul 2002 06:57:54 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 12572 invoked from network); 30 Jul 2002 06:57:53 -0000 Received: from unknown (HELO zwingli.cygnus.com) (208.245.165.35) by sources.redhat.com with SMTP; 30 Jul 2002 06:57:53 -0000 Received: by zwingli.cygnus.com (Postfix, from userid 442) id 2C3125EA11; Tue, 30 Jul 2002 01:57:52 -0500 (EST) To: david carlton Cc: gdb-patches@sources.redhat.com Subject: Re: gdbinit.in References: <15680.37429.703834.710341@jackfruit.Stanford.EDU> <15681.37431.43397.452535@jackfruit.Stanford.EDU> From: Jim Blandy Date: Tue, 30 Jul 2002 05:27:00 -0000 In-Reply-To: <15681.37431.43397.452535@jackfruit.Stanford.EDU> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-07/txt/msg00577.txt.bz2 I think I like your original patch best. I'll commit that. david carlton writes: > On 26 Jul 2002 12:17:47 -0500, Jim Blandy said: > > david carlton 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 > > * gdbinit.in: Removed all dir commands.