[RFC] fullname attribute for GDB/MI stack frames

[Eli Zaretskii]

> Date: Wed, 4 May 2005 16:29:59 -0400
> From: Daniel Jacobowitz <drow@false.org>
> Cc: gdb-patches@sources.redhat.com
> 
> This is where you have completely lost me.  I need for you to explain
> why it is OK for the "fully qualified file name" not to be an absolute
> path on DJGPP.

Because of 2 reasons: (1) there's nothing wrong with d:foo, so
resolving the cwd on drive d: would mean gratuitous DOS-specific code
in a general-purpose source file, which I try to avoid; and (2) because 
years I spent porting dozens of GNU packages to DJGPP led me to this
engineering decision which I found to work well in _all_ of the many
packages I ported.  I'm not going to go back and recollect all of the
complicated situations and reiterate hundreds of hours of testing and
debugging, just so that openp and xfullpath will look logically
perfect to an outsider.

> If we successfully find a file, openp will already call xfullpath,

Please let's not forget that xfullpath and gdb_realpath are also
functions on their own.  Not every file they deal with is going to be
opened with openp.  Thus, some transformations of the file names is
not going to be positively validated by opening the resulting name.

> after optionally prepending the current notion of current directory (in
> the correct circumstances, i.e. !IS_ABSOLUTE_PATH, though I have begun
> to think that that macro is seriously misnamed).

See, that's exactly what I was afraid of: first, you want to make the
regex right, then you question functions that worked for years since I
fixed them, then you question IS_ABSOLUTE_PATH which works for I don't
remember how much time in I don't remember how many ports I made...

IS_ABSOLUTE_PATH says that d:foo is an absolute file name for a very
good reason: that non-absolute file names are treated in a way that is
blatantly incorrect on Windows (e.g., by prepending the cwd to them).
If you want a better name, think of it as ISNT_NOT_ABSOLUTE_PATH,
okay?

> xfullpath calls gdb_realpath.  At the moment that doesn't include the
> MinGW32 bits to call resolve Windows paths to include the correct
> drive/directory.  That's simply an oversight; when this discussion is
> over, I intend to fix it by using the implementation from libiberty,
> which GCC already uses.

Beware: you might break things by this change, since currently
lrealpath returns file names with backslashes, which is not a good
idea in a program that came from the Posix world.

And even after that, there will be problems with UNCs and other
subtleties.

> With that change, the special case code in xfullpath to turn "d:foo"
> into "d:.\foo" (which I do understand and see the justification for)

d:./foo has the same issues you didn't like in d:foo: it still doesn't
resolve the current directory.  So I don't understand why it is better
for you.

The reason that d:foo is converted to d:./foo is that the rest of the
code needs at least one slash in the file name.  So we supply one.
Adding a syscall to find the cwd on drive d: would be an unjustified
complication: another syscall, the need to deal with errors, etc.