From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14381 invoked by alias); 19 Mar 2002 17:34:18 -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 14237 invoked from network); 19 Mar 2002 17:34:10 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 19 Mar 2002 17:34:10 -0000 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 16nNUj-0004Eb-00; Tue, 19 Mar 2002 12:33:57 -0500 Date: Tue, 19 Mar 2002 09:34:00 -0000 From: Daniel Jacobowitz To: Eli Zaretskii Cc: Joel Brobecker , gdb-patches@sources.redhat.com Subject: Re: [RFC] gdb_realpath causes problems with GVD Message-ID: <20020319123357.A16236@nevyn.them.org> Mail-Followup-To: Eli Zaretskii , Joel Brobecker , gdb-patches@sources.redhat.com References: <20020319171236.D6465@act-europe.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.23i X-SW-Source: 2002-03/txt/msg00349.txt.bz2 On Tue, Mar 19, 2002 at 07:16:33PM +0200, Eli Zaretskii wrote: > > On Tue, 19 Mar 2002, Joel Brobecker wrote: > > > As you see, GDB has translated toto.c into toto.C. This translation > > causes GDB to think that the inferior stopped in a file named toto.C > > (which is not known to GDB, since the compiler used only toto.c). > > Are you saying that gdb_realpath shouldn't follow symlinks? Well, that it shouldn't follow file symlinks. > > The translation is performed by gdb_realpath. I searched the gdb-patches > > archives, and found the reason for this translation in a message from > > Tom Tromey. I think I found a way to keep the fix to his problem and > > then at the same time fix our issue: instead of canonicalizing the > > entire filename, I suggest that we only expand the directory prefix > > (ie the part returned by the "dirname" unix command). > > Is this a complete solution? That is, will it work in a situation > slightly different from your, e.g., when one of the directories in the > full file name is also a symlink? I believe it will. We'll have a canonical name for each directory a source file was built out of; if the source file was a link, well, it's still the name we were given for the source file. Does that seem right to you? -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer