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

[Bob Rossi <bob@brasko.net>]

> > What should the front end receiving this information do with it?
> 
> It should do the best it can: try to access the file under the
> assumption that the missing drive in "\abc" is the current one and the
> missing directory in d:foo is the current directory on drive d:
> (which could be different from the current drive).  If that works, we
> win; if not, tough.  The failure case is the same situation as when
> the front end receives a file name which does not exist on the machine
> (e.g., a module from a library that was compiled on a different
> computer): GDB tries its best to find the file, but if the directory
> cannot be found by any algorithm known to us, we give up.  What else
> can we do?

In the second case here, "when the front end receives a file name which
does not exist on the machine ..."

The comment for source.c:openp states that the FILENAME_OPENED output
variable will always start with a "/". So, I'm assuming from what we've
talked about, that this comment is wrong.

I just realized that filename_opened is only populated if the
variable "filename" was opened successfully by GDB. Then filename_opened
is generated by doing xfullpath magic on the variable filename. The bad
thing about that, is that GDB never attempts to open filename_opened to
make sure that the file is there and is valid.

Should openp attempt to open filename_opened to make sure that it is
there? That would be one more step in the direction of making sure that
the fullname is at least valid on the disk. That way, absolute or not,
the front end will be able to rely on the fullname file being on the
disk. 

Thanks,
Bob Rossi