This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch 4/9] TUI: Use internally fullname
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