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

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

> Date: Tue, 3 May 2005 15:56:50 -0400
> From: Bob Rossi <bob@brasko.net>
> Cc: gdb-patches@sources.redhat.com
> 
> When I originally added the field fullname, I purposely picked that name
> because I was unsure if the path would always be absolute. However, it
> was to my understand, that it would always be. Thus, in the manual I
> put,
> 
>    Synopsis
>     -file-list-exec-source-file
> 
>    List the line number, the current source file, and the absolute path to
>    the current source file for the current executable.
> 
> I always expected the fullname to be absolute.

As I tried to explain, the Windows file names have a semi-absolute
form.  That form is generally treated like an absolute file name
because the single most important cause for a program to test a file
name for being absolute is to decide whether we need to prepend the
cwd to it; d:foo and \abc certainly don't need that!  The fullname
field uses the machinery that was invented mainly for that purpose, so
it inherits the same behavior.

> Currently, any front end using the fullname output is expecting the
> output to be an absolute path to a file. If this is not the case in all
> circumstances, then the documentation and expections of the FE
> developers need's to change.

As I explained in my previous messages, there's nothing the FE can do
but try accessing the file as if it were handed an absolute file name.
So the FE doesn't need to worry about this and doesn't need to change
its expectations in any way, because no change in expectations will
ever succeed in resurrecting the missing information (the drive letter
in the case of \abc and the current directory on drive d: in the case
of d:foo).

> I think it would be helpful if we could discover a case in
> which GDB would not be able to output an absolute path, but would still
> think that it has an absolute path. If that case is possible, than the
> doco needs to be updated and the fullname would consider absolute paths
> and some other special cases (\abc  d:foo). If that case is not
> possible, then we can consider only absolute paths. Does this sound
> correct?

I cannot say if this is correct because I cannot figure out what are
you saying.  What does it mean for fullname to consider absolute file
names and also special cases like \abc?  How will it ``consider''
them?

> The code to look at is source.c:openp. The filename_opened parameter is
> either 
>    - NULL 
>    - xfullpath (filename) where filename is potentially any file
>    - xfullpath (current_directory/filename)
> 
> Does anyone know what xfullpath would do if d:foo or \abc was passed to
> it?

I already answered that in this thread: it will leave \abc intact, and
d:foo will be converted into d:./foo.  (On Windows, that is, and
assuming that there's no realpath or canonicalize_file_name in MinGW.)
So xfullpath does not change anything with these cases on Windows (and
can't, since the necessary information is missing).