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

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

On Tue, 22 Jan 2013 09:24:59 +0100, Eli Zaretskii wrote:
> > 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?

It is compilation directory (DW_AT_comp_dir) relative name (therefore CU's
DW_AT_name).

Moreover recent GDBs allow to use also any trailing part, therefore not just
"break ./gdb.base/return.c:main" and "break return.c:main"
but also "break gdb.base/return.c".


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

Current directory of GDB can be somewhere completely else, it is not related.


I just try not to regress any existing case while fully fixing the absolute
filenames.  I do not remember symlinks used in source trees so I consider
those only as a backward compatibility relict.  And in this regard it can be
all further extended.  Attachment to a C++ applications shows 26000 source
files from all its tens/hundreds libraries so using relative source filenames
is rather a pain.  I already got hit by false breakpoint hits due to an
accidental source filename match.


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

BTW Free wine32 also has st_ino == 0; I understand it needs to be compatible.
Free wine64 (with 64-bit PE32+ executable) also behaves the same.


> That's why I suggested a separate method for retrieving the inode.

Thanks for the suggestion, it may match better (+it would be faster also on
MS-Windows) than the filename strings fallback.


Jan