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