From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28208 invoked by alias); 17 Jul 2013 16:51:00 -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 28183 invoked by uid 89); 17 Jul 2013 16:51:00 -0000 X-Spam-SWARE-Status: No, score=-5.0 required=5.0 tests=AWL,BAYES_05,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RDNS_NONE,SPF_HELO_PASS,SPF_PASS,TW_BG,TW_GT,TW_LR,TW_RW,TW_WX,TW_XR autolearn=no version=3.3.1 Received: from Unknown (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Wed, 17 Jul 2013 16:50:59 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r6HGonL8014702 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 17 Jul 2013 12:50:50 -0400 Received: from host2.jankratochvil.net (ovpn-116-19.ams2.redhat.com [10.36.116.19]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r6HGojmH014542 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 17 Jul 2013 12:50:48 -0400 Date: Wed, 17 Jul 2013 16:51:00 -0000 From: Jan Kratochvil To: Doug Evans Cc: "Agovic, Sanimir" , "gdb-patches@sourceware.org" , Cary Coutant , Sterling Augustine Subject: Re: [patchv2 1/11] Remove xfullpath (use gdb_realpath instead) Message-ID: <20130717165045.GA7275@host2.jankratochvil.net> References: <20130127223135.GB15252@host2.jankratochvil.net> <0377C58828D86C4588AEEC42FC3B85A71762FE8D@IRSMSX105.ger.corp.intel.com> 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-07/txt/msg00400.txt.bz2 On Wed, 17 Jul 2013 18:12:53 +0200, Doug Evans wrote: > Ah, forgot a reason. [How not unexpected, sigh.] > > If a binary has an auxiliary file (e.g., a separate debug info file or > a -gdb.py file) then gdb won't be able to find them - the auxiliary > files could be named and/or located based on the realpath name. In general GDB does many comparison for file identity by: strcmp (xfullpath (a), xfullpath (b)) == 0 It would be much more efficient to do: stat (a).st_{dev,ino} == stat (b).st_{dev,ino} Going to check what to do with the argv[0] problem, there seems to be xfullpath excessive. I do not know what happens with ${binary}.dwp. But .debug files were always symlinked similar way to their original binary files: lrwxrwxrwx 1 root root 27 Jun 19 00:23 /lib64/libgtk-x11-2.0.so -> libgtk-x11-2.0.so.0.2400.19* lrwxrwxrwx 1 root root 27 Jun 19 00:23 /lib64/libgtk-x11-2.0.so.0 -> libgtk-x11-2.0.so.0.2400.19* -rwxr-xr-x 1 root root 4779088 Jun 16 22:05 /lib64/libgtk-x11-2.0.so.0.2400.19* lrwxrwxrwx 1 root root 33 Jun 19 00:23 /usr/lib/debug/lib64/libgtk-x11-2.0.so.debug -> libgtk-x11-2.0.so.0.2400.19.debug lrwxrwxrwx 1 root root 33 Jun 19 00:23 /usr/lib/debug/lib64/libgtk-x11-2.0.so.0.debug -> libgtk-x11-2.0.so.0.2400.19.debug -r--r--r-- 1 root root 13663732 Jun 16 22:05 /usr/lib/debug/lib64/libgtk-x11-2.0.so.0.2400.19.debug So I would say this is a bug in the script generating *.dwp, isn't it? Jan