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

[Bob Rossi <bob@brasko.net>]

On Tue, May 03, 2005 at 10:34:15PM +0300, Eli Zaretskii wrote:
> > Date: Mon, 2 May 2005 23:46:05 -0400
> > From: Daniel Jacobowitz <drow@false.org>
> > Cc: gdb-patches@sources.redhat.com
> > 
> > > > That's not what we're testing for in the testsuite, though.
> > > 
> > > What _are_ we trying to test?
> > 
> > GDB is outputting an absolute path, which will be used by either the
> > user or by a front end.  In either case, it should locate the file
> > entirely unambiguously.
> 
> If that is what we want to test, then the test is IMHO inappropriate:
> we shouldn't try to identify an absolute file name, we should see if
> the name it produces corresponds to a real file.  I.e., try to stat
> the file, or maybe cmp it against the source whose path we know, or
> something like that.

OK, I think I can solve some confusion here. At least, I feel that I
just understood why you have your position to allow paths that are not
absolute to be acceptable in the fullname output.

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. This is why I made the
original regex /.*

> > > > I think that we should reject both \abc and d:foo here.
> > > 
> > > I don't think so.
> > 
> > Could you explain why?
> 
> Because (as I said in my other mail this morning) such semi-absolute
> file names can be recorded in the debug info, albeit under somewhat
> unusual circumstances.  Since we don't own the compiler's code that
> records file and directory names in the debug info, we can never be
> 100% sure such file names will never end up there.  When they do,
> there's nothing we can do about them in GDB but try to find them, see
> below.  Failing the test because we see such file names will thus do a
> misservice to us: it will mark a perfrctly legitimate result as a
> failure.

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.

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?

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 look more into this...

Thanks,
Bob Rossi