From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20921 invoked by alias); 24 Jun 2006 13:30:58 -0000 Received: (qmail 20873 invoked by uid 22791); 24 Jun 2006 13:30:57 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Sat, 24 Jun 2006 13:30:54 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1Fu8Dr-0006vy-Ep; Sat, 24 Jun 2006 09:30:51 -0400 Date: Sat, 24 Jun 2006 13:38:00 -0000 From: Daniel Jacobowitz To: Joel Brobecker Cc: Eli Zaretskii , gdb@sources.redhat.com Subject: Re: Should "dir" override the full path encoded in debug info? Message-ID: <20060624133051.GB26555@nevyn.them.org> Mail-Followup-To: Joel Brobecker , Eli Zaretskii , gdb@sources.redhat.com References: <20060623201019.GX22750@adacore.com> <20060624065920.GB22750@adacore.com> <20060624071058.GD22750@adacore.com> <20060624075143.GF22750@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060624075143.GF22750@adacore.com> User-Agent: Mutt/1.5.11+cvs20060403 X-IsSubscribed: yes 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/msg00213.txt.bz2 On Sat, Jun 24, 2006 at 12:51:43AM -0700, Joel Brobecker wrote: > > Then I think this is by design: GDB gives preference to existing files > > in the default places. > > That's fine. But then how do you explain that when you compile > differently GDB now finds the files in the new location, despite > the fact that the files in the original location are still present > (and the debugging info contains the path to the original files)? > Isn't that inconsistent? I think that's a bug, but the fix for the bug won't make you any happier - if told to fix it, I'd probably make the compilation directory be searched first. But don't quote me on that; I haven't looked at this code in a while (I have another bug to fix in it but it takes me so long to re-internalize how it works that I haven't done it yet). -- Daniel Jacobowitz CodeSourcery