This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFA] maintenance_print_msymbols: Try harder to match files
- From: Daniel Jacobowitz <drow at false dot org>
- To: gdb-patches at sources dot redhat dot com
- Cc: Joel Brobecker <brobecker at adacore dot com>
- Date: Sun, 1 May 2005 19:37:00 -0400
- Subject: Re: [RFA] maintenance_print_msymbols: Try harder to match files
- References: <20050124210931.GE17455@cygbert.vinschen.de>
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