Re: [RFC] fullname attribute for GDB/MI stack frames

["Eli Zaretskii" <eliz@gnu.org>]

> Date: Wed, 4 May 2005 17:07:17 -0400
> From: Daniel Jacobowitz <drow@false.org>
> Cc: gdb-patches@sources.redhat.com
> 
> The value of those functions if they can not find the file is _nil_.

No, it's not.  Given enough information, e.g., the leading directories
and the basename, one can reconstruct the absolute file name even if
it no longer exists.

> realpath() returns ENOENT if you hand it a path that does not exist.

Does GetFullPathName on Windows fails in similar ways for non-existent
files?

In any case, the fact that realpath fails for non-existent files does
not seem to be documented, and I, for one, would not necessarily
expect that, as some similar functions and system calls I've met over
the years on other platforms didn't fail like that.

> There are five calls to xfullpath in GDB.  One is for debugging use
> (maint print msymbols).  Two are interested in canonicalizing
> paths which already meet IS_ABSOLUTE_PATH, for the purposes of
> comparison.  And the last two are in openp, after successfully opening
> the file.
> 
> There are six calls to gdb_realpath.  One is QNX-specific and I'm not
> precisely sure what it's for.  Four are used on symtabs for string
> comparison.  And the last one is in the implementation of xfullpath.

I don't follow the rationale for enumerating the current uses.  These
are sufficiently general-purpose functions; even if today they are
used in certain contexts, tomorrow someone could use them in a
different context.  We need to think about potential uses even if they
aren't currently in the sources.

> > If the front end is going to open the file, it doesn't matter.  If it
> > is going to compare files for equality, it should not use string
> > comparison, for the reasons I explained in another message.
> 
> If it's going to open files, it _does_ matter.  You said that the
> current directory (and presumably the current drive) are global on this
> platform.  But the current directory is not stable across time.  If the
> front end changes the current directory after talking to GDB, suddenly
> it won't be able to open files.

In some (hopefully rare) cases, yes.  \abc will remain correct as long
as you don't change the drive; d:foo and d:./foo will remain correct
as long as you don't change the cwd on drive d:.  Both changes are
rare in practice.

However, similar changes that invalidate file names can happen on Unix
as well: mounted file systems can be unmounted, symlinks can be
broken, etc.  When that happens, GDB will no longer be able to open the
file, even if its name is 100% absolute.

> Can you give me an example of when canonicalization would be harmful? 

It's gratuitous, even if the result is correct.  And we don't know how
to detect when it is correct.

> The only one I can think of is "the current directory was wrong when we
> tried to open the file, so we change the current directory and things
> start working".  This relies on a DJGPP specific property

??? What DJGPP specific property?  What I had in mind was the GDB "cd"
command typed by the user (who presumably knows where to go), not
something specific to DJGPP.