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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Tue, 22 Jan 2013 08:12:05 +0100
> From: Jan Kratochvil <jan.kratochvil@redhat.com>
> Cc: tromey@redhat.com, gdb-patches@sourceware.org
> 
> > 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.

What is the semantics of such a 'break' command?  Does "." here mean
the current directory?  Or does it mean something else?

If the former, then we have the current directory in GDB, don't we?

> 	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.

Because MS didn't bother to code that.

> I expect it is just a MS-Windows stat implementation bug probably
> workarounded in Cygwin but apparently not in MinGW?

Cygwin doesn't use the Windows runtime, it uses its own library.

MinGW does use the Windows runtime, and doesn't have a replacement for
'stat' in its "mingwex" library.  One complication with such a
replacement is that the FileIndex thing is a 64-bit quantity, while
'struct stat' in MS implementation uses a 'short' data type for it.
This creates binary incompatibility.  That's why I suggested a
separate method for retrieving the inode.