Re: [RFA] maintenance_print_msymbols: Try harder to match files

[Daniel Jacobowitz <drow@false.org>]

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