From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5221 invoked by alias); 16 Sep 2013 19:01:59 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 5211 invoked by uid 89); 16 Sep 2013 19:01:59 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 16 Sep 2013 19:01:59 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.0 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r8GJ1tfc001315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 16 Sep 2013 15:01:55 -0400 Received: from host2.jankratochvil.net (ovpn-116-51.ams2.redhat.com [10.36.116.51]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r8GJ1pR8003170 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 16 Sep 2013 15:01:54 -0400 Date: Mon, 16 Sep 2013 19:01:00 -0000 From: Jan Kratochvil To: Doug Evans Cc: gdb-patches Subject: Re: [patchv2] Support .dwp with the name of symlinked binary file Message-ID: <20130916190151.GA24936@host2.jankratochvil.net> References: <20130905131839.GA8618@host2.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes X-SW-Source: 2013-09/txt/msg00467.txt.bz2 On Fri, 06 Sep 2013 20:29:09 +0200, Doug Evans wrote: > On Thu, Sep 5, 2013 at 6:18 AM, Jan Kratochvil wrote: > > Also currently GDB code seems to use bfd->filename and its objfile->name > > interchangeably so I did not want to change either. > > One needn't address things all at once, but not wanting to change > something isn't, in and of itself(!), a good reason. The posted patches [patchv3 3/5] Code cleanup: Add objfile_name accessor [patchv3 4/5] Keep objfile original filename therefore: * unify the two separate strings into one (the bfd one, canonical one). * keep backward compatibility all the current code uses the bfd string. * preserve the non-canonical string for special cases (accessing explicitly objfile->original_name) > Is there a real issue here? I'm not sure, but it seems so. > >From the point of view of the user, realpath bugs me. > [I'm not including stripping "./" in this, stripping that is reasonable enough. > And foo/bar/../baz isn't worth the trouble, though I would be ok with > an option where the user can turn canonicalization on.] I found the foo/bar/../baz paths unexpectedly annoying, after Pedro's examples. > ISTM realpath is mostly just an implementation detail in gdb. > Or to turn it around, when *does* the user want realpath? > If it is indeed rare that the user wants (or cares) about realpath, > can we move towards not showing it to them? ISTM people want the directories normalized against any "../". I was giving a countercase where realpath gives worse result /home/user/file -> /.sdb5/home/user/file but that happens rarely and the "../" normalization is a better benefit so that one prefers to use gdb_realpath(). > It may be that there are places where we don't have anything else > besides bfd->filename, > but we already wrap bfd in gdb_bfd (I'm all for abstracting away bfd > as much as possible). > We *could* save the file passed to gdb_bfd_open, > and have gdb_bfd_filename() or some such. IIUC you were proposing thin 'struct gdb_bfd *' wrapper around 'bfd *'. In the patchset above I have found we do not IMO need non-canonical filename from 'bfd *', it is enough to have non-canonical filename from 'objfile *'. > Also, it may be that not all objfiles have a bfd (I don't remember off > hand, but whether it's true or not is irrelevant to my point), and if > not all objfiles have a bfd we can't just remove objfile->name > (assuming objfiles-without-bfds have a name). > OTOH, if objfiles-without-bfds have a name, we could store it in a > different place (objfile->foo_name), and thus still effectively have > an implementation that only maintains one name, not two (setting aside > bfd->filename which is more an implementation detail of the cache). > [I don't want to add more file names, having two copies of something > is already causing trouble. But I think this is a solvable problem.] See the top paragraph. > And if we record the original file name we can always > get the realpath name, Calling gdb_realpath() dynamically is very expensive. Fortunately bfd's canonical filename can be used for it / as a cache. Jan