This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Wed, May 04, 2005 at 07:24:47AM +0300, Eli Zaretskii wrote:
>> Date: Tue, 3 May 2005 17:39:11 -0400
>> From: Christopher Faylor <me@cgf.cx>
>> 
>> Cygwin has realpath and Windows has an equivalent function.  AFAIK, it
>> will correctly translate \abc to x:\abc.
>
>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.
>
>> I don't know what it will do with d:foo.  NT+ shells treat that as
>> "the current directory on drive d:" but that's just something that
>> is special to a shell.
>
>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.  Otherwise the current directory is
stored in hidden environment variables by the shell.  XP/NT and 9x
differ in this regard.

>There's a special OS data structure where it holds the current
>directory for each drive.  Also, unlike on Unix, the current directory
>on each drive is globally in effect for all the processes that run in
>the current VM.

This is true only on 9x/Me (and MS-DOS).

>> Probably it should be resolved as "d:\foo".
>
>Please! I'm gonna cry! you are suggesting to revert the code that took
>hard work to get right!  openp used to do d:foo -> d:/foo, but that
>was blatantly wrong and caused bugs.  Let's not go that way just
>because some test case doesn't seem 100% right!
>
>I am frustrated by my evident inability to communicate to you all the
>simple truth: openp IS OKAY, IT DOESN'T NEED ANY FIXING!

I just built a simple test case (tm) using a mingw version of lrealpath
from libiberty.  It fully canonicalizes the path and it even works on XP,
so, apparently, GetFullPathName understand the hidden environment variables.

So, if I type:

  myrealpath d:foo

and the cwd on d: is set to \tmp:

   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.

>> Hopefully the Windows
>> routine for producing absolute paths will do something sensical.
>
>They won't; see above.
>
>> Anyway, it seems like the mingw port should be using GetFullPathName()
>> in gdb_realpath().
>
>I don't see this in my sandbox.

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.

cgf


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]