From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15844 invoked by alias); 24 Jun 2006 06:59:45 -0000 Received: (qmail 15660 invoked by uid 22791); 24 Jun 2006 06:59:44 -0000 X-Spam-Check-By: sourceware.org Received: from nile.gnat.com (HELO nile.gnat.com) (205.232.38.5) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 24 Jun 2006 06:59:31 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-nile.gnat.com (Postfix) with ESMTP id E0A3248CBDF; Sat, 24 Jun 2006 02:59:25 -0400 (EDT) Received: from nile.gnat.com ([127.0.0.1]) by localhost (nile.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 08463-01-10; Sat, 24 Jun 2006 02:59:25 -0400 (EDT) Received: from takamaka.act-europe.fr (s142-179-108-108.bc.hsia.telus.net [142.179.108.108]) by nile.gnat.com (Postfix) with ESMTP id 409F548CBD6; Sat, 24 Jun 2006 02:59:25 -0400 (EDT) Received: by takamaka.act-europe.fr (Postfix, from userid 507) id 87D9D47E7F; Fri, 23 Jun 2006 23:59:20 -0700 (PDT) Date: Sat, 24 Jun 2006 07:04:00 -0000 From: Joel Brobecker To: Eli Zaretskii Cc: gdb@sources.redhat.com Subject: Re: Should "dir" override the full path encoded in debug info? Message-ID: <20060624065920.GB22750@adacore.com> References: <20060623201019.GX22750@adacore.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-06/txt/msg00203.txt.bz2 > As Daniel points out, this is a complicated issue; the relevant code > was changed several times during the last year to cater to several > popular practices wrt source location. I think, to judge whether this > is a bug or a feature, we need to see more information, like the > original location of the sources during compilation, what file names > are recorded in the debug info, the "dir" command that was issued at > debug time, and the unwanted behavior and/or the error message(s), if > any, from GDB. OK, here goes an example using C. Consider the following source file called foo.c, located in /src. #include int main (void) { printf ("Hello world.\n"); } Cd to /src, and then compile it as follow: % gcc -c -g `pwd`/foo.c % gcc -o foo foo.o Then cd one level up to and do the following: % cp -R src dup Now, let's simulate the action of our test engine that undoes the changes that we just tested. For that, I simply edited the original file in src/, and change the string. Next step, we debug the binary we copied. Because we know the relevant sources are in dup, and not in the original location where they were located when we did the built, the user used the "dir" command to point GDB to the new location: (gdb) dir dup Source directories searched: //dup:$cdir:$cwd But then, trying to print the contents of foo.c reveals that we display the file from the original location. So the "dir" command was not taken into account: (gdb) list foo.c:1 warning: Source file is more recent than executable. 1 #include 2 3 int 4 main (void) 5 { 6 printf ("Hello modified.\n"); 7 } It seems from Daniel's answer that this is by design. The document is not that clear about that, which explained why I asked before going in and "fixing" it. The debugging information generated by foo.c is as follow: <0>: Abbrev Number: 1 (DW_TAG_compile_unit) DW_AT_stmt_list : 0 DW_AT_high_pc : 0x21 33 DW_AT_low_pc : 0 0 DW_AT_producer : GNU C 3.4.6 for GNAT Pro 5.05w (20060507) DW_AT_language : 1 (ANSI C) DW_AT_name : /t.a/brobecke/moved/ex/src/foo.c As you can see, the DW_AT_name attribute contains a full path name, and the DW_AT_comp_dir attribute is ommitted. Normally, what we see is a relative path name in AT_name, and a comp_dir attribute that provides the path for that file. For instance: <0>: Abbrev Number: 1 (DW_TAG_compile_unit) DW_AT_stmt_list : 0 DW_AT_high_pc : 0x21 33 DW_AT_low_pc : 0 0 DW_AT_producer : GNU C 3.4.6 for GNAT Pro 5.05w (20060507) DW_AT_language : 1 (ANSI C) DW_AT_name : foo.c DW_AT_comp_dir : /t.a/brobecke/moved/ex/src The above debugging data is obtained if I compile the file with the same command, but ommitting the `pwd` part. It's interesting to notice that in this case, the scenario above leads to a different behavior which actually matches what my coworker expected. -- Joel