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

[Christopher Faylor <me@cgf.cx>]

On Wed, May 04, 2005 at 01:47:47PM -0400, Eli Zaretskii wrote:
>> Date: Wed, 4 May 2005 10:52:00 -0400
>> From: Christopher Faylor <me@cgf.cx>
>> 
>> >Not true: the notion of a current directory on drive d: is maintained
>> >by the OS.
>> 
>> The current directory on another drive is maintained by the "OS" only on
>> Windows 9x variants and on MS-DOS.
>
>Okay, but we still support those versions of Windows, right?

Yes, we do.  I was clarifying your global statement.

>>    c:\>./myrealpath d:foo
>>    d:\tmp\foo
>>    c:\>env - ./myrealpath d:foo
>>    d:\foo
>> 
>> So, AFAICT, libiberty is working fine and it should be safe to expect
>> that canonicalized names on windows will either be in the form of
>> x:\y\z or \\x\y\z if this is used.
>>[snip]
>>I don't see any calls to lrealpath in gdb either.  So, it seems like
>>gdb isn't using this functionality but maybe it should be.
>
>Yes, libiberty is working fine, except that GDB is not using
>lrealpath, AFAIK.

"So, it seems like gdb isn't using this functionality but maybe it
should be."

>And then the question is whether it is correct to resolve d:foo
>etc. assuming thath the current drive and directories are identical to
>what they were when the source was compiled.  Many projects use
>recursive Makefiles that cause the compiler change directories at
>will.

I thought you were advocating that d:foo means "the current directory on
drive d:" no matter what it might have meant at compile time.  I don't
see that we have any choice but to do anything but that and, apparently,
that is what lrealpath will do, as long as the environment is not
perturbed on XP.

So, why not just use lrealpath?

cgf