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

[Daniel Jacobowitz <drow@false.org>]

On Wed, May 04, 2005 at 11:17:23PM +0300, Eli Zaretskii wrote:
> > Date: Wed, 4 May 2005 09:45:38 -0400
> > From: Daniel Jacobowitz <drow@false.org>
> > Cc: gdb-patches@sources.redhat.com
> > 
> > > No, it will _incorrectly_ translate them: the current drive and
> > > directory that are in effect when we call these functions are _not_
> > > what they were when the compiler compiled the source and recorded its
> > > file name in the debug info.
> > 
> > Eli, this is inconsistent with the rest of the world.  In the rest of
> > the world, realpath() and canonicalize_file_name() call getcwd() (or
> > the operating system's equivalent function).  Can you explain to us why
> > it is correct for other OSes to do this resolution in xfullpath (or
> > wherever else), and for DJGPP not to?
> 
> We are again talking past each other.  What you describe is correct
> for all platforms, including DJGPP and Windows, but not in the
> specific circumstances which led us to this endless thread, which is
> to find a fully qualified file name using the information recorded in
> the debug info.

This is where you have completely lost me.  I need for you to explain
why it is OK for the "fully qualified file name" not to be an absolute
path on DJGPP.

If we successfully find a file, openp will already call xfullpath,
after optionally prepending the current notion of current directory (in
the correct circumstances, i.e. !IS_ABSOLUTE_PATH, though I have begun
to think that that macro is seriously misnamed).

xfullpath calls gdb_realpath.  At the moment that doesn't include the
MinGW32 bits to call resolve Windows paths to include the correct
drive/directory.  That's simply an oversight; when this discussion is
over, I intend to fix it by using the implementation from libiberty,
which GCC already uses.

So, with that fix and on any system but DJGPP, the path returned in
*FILENAME_OPENED will always be canonicalized via realpath, with the
exception of the basename, as described in the comments around the
call.

So why shouldn't we do this same thing for DJGPP?  If you'll tell me
the appropriate DJGPP interfaces and test the result I'll even write
the code myself; I can't do it from scratch since I have no hardware
set up to deal with DJGPP.

With that change, the special case code in xfullpath to turn "d:foo"
into "d:.\foo" (which I do understand and see the justification for)
could almost be replaced by an assertion that the path never looks like
"d:foo".  In fact it can't; that's because some callers of xfullpath
may pass filenames that don't exist, so we may not get an absolute path
back from realpath.

-- 
Daniel Jacobowitz
CodeSourcery, LLC