From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20855 invoked by alias); 1 May 2005 23:37:04 -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 20845 invoked from network); 1 May 2005 23:37:01 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 1 May 2005 23:37:01 -0000 Received: from drow by nevyn.them.org with local (Exim 4.50 #1 (Debian)) id 1DSNzg-0001DV-3X; Sun, 01 May 2005 19:37:00 -0400 Date: Sun, 01 May 2005 23:37:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sources.redhat.com Cc: Joel Brobecker Subject: Re: [RFA] maintenance_print_msymbols: Try harder to match files Message-ID: <20050501233700.GD4311@nevyn.them.org> Mail-Followup-To: gdb-patches@sources.redhat.com, Joel Brobecker References: <20050124210931.GE17455@cygbert.vinschen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050124210931.GE17455@cygbert.vinschen.de> User-Agent: Mutt/1.5.8i X-SW-Source: 2005-05/txt/msg00031.txt.bz2 On Mon, Jan 24, 2005 at 10:09:31PM +0100, Corinna Vinschen wrote: > Hi, > > while testing on Cygwin, I found that the maintenance_print_msymbols > doesn't evaluate the optional symbol filename from the command line > very user friendly. Actually it evaluates nothing at all and tests > the objfile names from the loaded object files just against the > command line parameter using strcmp. This has two disadvantages. > > - If the user types a relative pathname, the maintenance_print_msymbols > function prints nothing, because object file names are stored with > absolute pathnames in the objfile structure. > > - On Windows based systems, the user might like to enter the filename > without the .exe suffix. That would fail as well. > > The below patch changes the maintenance_print_msymbols so that the > optional filename is evaluated to an absolute pathname, just to be sure. > If the file doesn't exist, maintenance_print_msymbols will generate an > appropriate error message. > > Then it tests the inode number of this file against the inode number > of the object files stored in GDB. This should be pretty reliable. The xfullpath call doesn't do what you think it does: /* Extract the basename of filename, and return immediately a copy of filename if it does not contain any directory prefix. */ if (base_name == filename) return xstrdup (filename); I've got no idea at all why that is there. Joel added this function; maybe he can explain. You're comparing solely based on inode number; I think that's an unwise choice for two reasons: - The file may have been replaced on disk; we should use the copy that was there when GDB opened it. - There are some file systems in which all st_ino values are zero. If you've got the full path, why not use that? -- Daniel Jacobowitz CodeSourcery, LLC