From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20274 invoked by alias); 2 May 2005 20:18:59 -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 20226 invoked from network); 2 May 2005 20:18:52 -0000 Received: from unknown (HELO priv-edtnes56.telusplanet.net) (199.185.220.220) by sourceware.org with SMTP; 2 May 2005 20:18:52 -0000 Received: from takamaka.act-europe.fr ([154.20.104.226]) by priv-edtnes56.telusplanet.net (InterMail vM.6.01.04.04 201-2131-118-104-20050224) with ESMTP id <20050502201851.HUKA25789.priv-edtnes56.telusplanet.net@takamaka.act-europe.fr> for ; Mon, 2 May 2005 14:18:51 -0600 Received: by takamaka.act-europe.fr (Postfix, from userid 507) id 8051C47DC4; Mon, 2 May 2005 13:18:51 -0700 (PDT) Date: Mon, 02 May 2005 20:18:00 -0000 From: Joel Brobecker To: gdb-patches@sources.redhat.com Subject: Re: [RFA] maintenance_print_msymbols: Try harder to match files Message-ID: <20050502201851.GB1204@adacore.com> References: <20050124210931.GE17455@cygbert.vinschen.de> <20050501233700.GD4311@nevyn.them.org> <20050502200515.GA1204@adacore.com> <20050502200720.GA9490@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050502200720.GA9490@nevyn.them.org> User-Agent: Mutt/1.4i X-SW-Source: 2005-05/txt/msg00068.txt.bz2 > > I don't remember all the details, I could dig up the relevant messages > > if necessary. But the comment at the begining of the function seems to > > confirm that this code is correct to be here: > > > > /* Return a copy of FILENAME, with its directory prefix canonicalized > > by gdb_realpath. */ > > > > Perhaps the function is incorrectly named, though (misleading)... > > Should we consider finding a more meaningful name? > > I would rather see an example of why the current behavior is correct, > first. I think I remember the whole story now. The description of the problem xfullpath fixes is at: http://sources.redhat.com/ml/gdb-patches/2002-03/msg00345.html All the followup messages were refreshing... Basically, we're trying in xfullpath to avoid canonicalizing the basename part of the path. So, if the name doesn't have any directory part in it, then we're done. -- Joel