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

[Daniel Jacobowitz <drow@false.org>]

On Wed, May 04, 2005 at 11:51:08PM +0300, Eli Zaretskii wrote:
> > Date: Wed, 4 May 2005 14:31:28 -0400
> > From: Daniel Jacobowitz <drow@false.org>
> > Cc: gdb-patches@sources.redhat.com
> > 
> > If we're returning a fullname at all, we've decided where to open the
> > file; we can share that decision with the user/client.
> 
> That is perhaps true for openp, but not for xfullpath or gdb_realpath:
> those functions don't open the file, they just manipulate the string
> that is handed to them.

I'm still just not following you.  The value of those functions if they
can not find the file is _nil_.  You can't resolve symlinks in a
directory path, for instance, if you can't find the directory. 
realpath() returns ENOENT if you hand it a path that does not exist.

There are five calls to xfullpath in GDB.  One is for debugging use
(maint print msymbols).  Two are interested in canonicalizing
paths which already meet IS_ABSOLUTE_PATH, for the purposes of
comparison.  And the last two are in openp, after successfully opening
the file.

There are six calls to gdb_realpath.  One is QNX-specific and I'm not
precisely sure what it's for.  Four are used on symtabs for string
comparison.  And the last one is in the implementation of xfullpath.

> > The question is what a front end can expect from GDB.  The
> > documentation says it can expect an absolute path, not a
> > semi-absolute path.
> 
> If the front end is going to open the file, it doesn't matter.  If it
> is going to compare files for equality, it should not use string
> comparison, for the reasons I explained in another message.

If it's going to open files, it _does_ matter.  You said that the
current directory (and presumably the current drive) are global on this
platform.  But the current directory is not stable across time.  If the
front end changes the current directory after talking to GDB, suddenly
it won't be able to open files.

> Because it took me quite an effort to make GDB DTRT with MS-style file
> names.  So I don't want to see it go down the drain because of some
> test case.  The main reason for these functions is to handle files
> which GDB needs to work with, not to display standardized names.  That
> is, the ultimate test is whether opening the file will work or not,
> not if they look canonical.  Canonicalization is a means, not an end
> in itself, except in the test that started this.  So I'm willing to
> give up on this test, but not on what the code does, because I don't
> want us to break much more important situations where the current code
> works.

Can you give me an example of when canonicalization would be harmful? 
The only one I can think of is "the current directory was wrong when we
tried to open the file, so we change the current directory and things
start working".  This relies on a DJGPP specific property; if you want
this behavior, the right way to do it is to make GDB re-resolve
filenames when its current directory changes.

-- 
Daniel Jacobowitz
CodeSourcery, LLC