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

[Bob Rossi <bob at brasko dot net>]

On Wed, May 04, 2005 at 12:12:48AM +0300, Eli Zaretskii wrote:
> > 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.

OK, I'm going to add the examples d:foo and \abc to the doco. This could
potentially help FE developers understand these odd case's when they
appear. Also, it's important to say that the fullname is not necessarily
absolute, but simply the most precise file name that GDB has.

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

Agreed.

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

What I was trying to say was, if d:foo and d:./foo will currently return in 
the fullpath field, then fullname does not always return absolute paths.
I should document -file-list-exec-source-file to state this. Also, the
regex should match the existing functionality (which does not force
absolute paths).

It was Daniel's initial suggestion to not check for an absolute path. I
suggested we should, since I was under the impreession that the fullname
should always check for an absolute path. As Daniel pointed out since
then, it's probably OK to have the regex check for an absolute path,
since we are sure that the testsuite is always going to display that
property.

As a separate issue, we can discuess if fullname should always return as
an absolute path. For now, I'd like to document and test GDB's current
behavior.

Thanks for clearing things up.

Thanks,
Bob Rossi