From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19277 invoked by alias); 23 Jun 2006 20:10:37 -0000 Received: (qmail 19265 invoked by uid 22791); 23 Jun 2006 20:10:36 -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; Fri, 23 Jun 2006 20:10:34 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-nile.gnat.com (Postfix) with ESMTP id DF59348CC26 for ; Fri, 23 Jun 2006 16:10:20 -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 24628-01-2 for ; Fri, 23 Jun 2006 16:10:20 -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 8E8EB48CC09 for ; Fri, 23 Jun 2006 16:10:20 -0400 (EDT) Received: by takamaka.act-europe.fr (Postfix, from userid 507) id AE81747E7F; Fri, 23 Jun 2006 13:10:19 -0700 (PDT) Date: Fri, 23 Jun 2006 20:18:00 -0000 From: Joel Brobecker To: gdb@sources.redhat.com Subject: Should "dir" override the full path encoded in debug info? Message-ID: <20060623201019.GX22750@adacore.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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/msg00193.txt.bz2 Hello all, One of my coworkers just attracted my attention to the semantics of the "dir" command. Our compiler fixes are tested through a mechanism where we submit a patch to our testing engine. It then applies the patch to the sources of the night before, rebuilds the compiler, reruns our testsuite, and then send the differences. In order to facilitate the investigation of regressions, we also make a copy of the resulting compiler in a separate location. Once all this is completed, the nightly compiler is restored in order to get ready for the next testing job. My coworker tried to run the debugger using that copy of the executable and used "dir" commands to point to his copy of the sources. Unfortunately, that didn't work as the debugger insisted on using the original location for getting the source files. The issue comes from the fact that the compiler sources seem to be compiled using full path names, or in a way that causes the AT_name attribute of the compilation unit to be a full path. And then, when I look at find_and_open_source(), and how it gets called through open_source_file() (called by print_source_lines_base()), it almost seems like it was a deliberate decision to objey the fullpath if available rather than let the "dir" path override the debugging info. /* Open a source file given a symtab S. Returns a file descriptor or negative number for error. This function is a convience function to find_and_open_source. */ int open_source_file (struct symtab *s) { if (!s) return -1; return find_and_open_source (s->objfile, s->filename, s->dirname, &s->fullname); } Is that really so, or is this a bug? Note that in most cases, we compile files using relative file names. And under these circumstances, the "dir" path overrides the path provided by the debugging info. This is inconsistent. Thanks, -- Joel