From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2607 invoked by alias); 26 Jul 2002 18:17:39 -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 2600 invoked from network); 26 Jul 2002 18:17:39 -0000 Received: from unknown (HELO jackfruit.Stanford.EDU) (171.64.38.136) by sources.redhat.com with SMTP; 26 Jul 2002 18:17:39 -0000 Received: (from carlton@localhost) by jackfruit.Stanford.EDU (8.11.6/8.11.6) id g6QIHSf31205; Fri, 26 Jul 2002 11:17:28 -0700 From: david carlton MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15681.37431.43397.452535@jackfruit.Stanford.EDU> Date: Fri, 26 Jul 2002 14:30:00 -0000 To: Jim Blandy Cc: david carlton , gdb-patches@sources.redhat.com Subject: Re: gdbinit.in In-Reply-To: References: <15680.37429.703834.710341@jackfruit.Stanford.EDU> Cc: carlton@math.Stanford.EDU X-SW-Source: 2002-07/txt/msg00535.txt.bz2 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.