Re: [patch 4/9] TUI: Use internally fullname

[Jan Kratochvil <jan.kratochvil@redhat.com>]

On Tue, 22 Jan 2013 07:55:10 +0100, Eli Zaretskii wrote:
> > Date: Mon, 21 Jan 2013 22:11:21 +0100
> > From: Jan Kratochvil <jan.kratochvil@redhat.com>
> > Cc: gdb-patches@sourceware.org
> > 
> > -      if (compare_filenames_for_search (s->filename, name))
> > +      if (compare_filenames_for_search (s->filename, name)
> > +         || compare_filenames_for_search (symtab_to_fullname (s), name))
> > 
> > One cannot use just:
> > +      if (compare_filenames_for_search (symtab_to_fullname (s), name))
> > 
> > as in the case of S->FILENAME == NAME == "./gdb.base/return.c" it would be
> > a regression because SYMTAB_TO_FULLNAME == "/gdb/testsuite/gdb.base/return.c".
> > Formerly S->FILENAME matched NAME but SYMTAB_TO_FULLNAME does not match NAME.
> > 
> > One could also do some "normalization" of NAME, one could strip "./" but for
> > more complicated cases one cannot do much.
> 
> Why strip it?  We could resolve "." to an absolute file name using the
> compilation directory, and then they will match, right?

That can be done for S->FILENAME and that is already done by
symtab_to_fullname.

But for NAME - the string which user entered in "break ./gdb.base/return.c:main"
- has no compilation nor "current" directory.

I think the only perfect solution - which works also for symbolic links and ..
references such as in the case:
  cd gdb
  ln -s testsuite symlinked
then:
  break symlinked/gdb.base/return.c
would be to try resolving the name from each directory of each file being
evaluated for a match:
  /./gdb.base/return.c
  /gdb/./gdb.base/return.c
  /gdb/testsuite/./gdb.base/return.c
But that would be too slow and I do not think anyone would ever use it.

So far I hope this double-match of both s->filename and symtab_to_fullname (s)
is good enough for any real world case.


> > The next step would be to turn various pathname comparisons rather to
> > st_dev&&st_ino comparisons when possible which should be both faster and more
> > universal.
> 
> That will break on Windows, unless we replace the library
> implementation of 'stat' and 'fstat', or provide a method for
> retrieving just the inode and device number (which could be
> implemented on Windows using available APIs, such as
> GetFileInformationByHandle).

I am aware of:
separate_debug_file_exists
     Some operating systems, e.g. Windows, do not provide a meaningful
     st_ino; they always set it to zero.  (Windows does provide a
     meaningful st_dev.)  Do not indicate a duplicate library in that
     case.  While there is no guarantee that a system that provides

I expected to fall back to the current realpath strings matching in the
MS-Windows ST_INO == 0 case.  But when you point at GetFileInformationByHandle
I see at
	http://msdn.microsoft.com/en-us/library/windows/desktop/aa363788%28v=vs.85%29.aspx
	dwVolumeSerialNumber
	nFileIndexHigh
	nFileIndexLow
	The identifier (low and high parts) and the volume serial number
	uniquely identify a file on a single computer. To determine whether
	two open handles represent the same file, combine the identifier and
	the volume serial number for each file and compare them.

So I do not understand why MS-Windows stat call does not provide st_ino from
those fields.  I expect it is just a MS-Windows stat implementation bug
probably workarounded in Cygwin but apparently not in MinGW?


Thanks,
Jan