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

[Bob Rossi <bob@brasko.net>]

On Wed, May 04, 2005 at 10:55:35AM -0400, Christopher Faylor wrote:
> On Wed, May 04, 2005 at 07:48:21AM -0400, Bob Rossi wrote:
> >> 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!
> >
> >From this email, I understand completly why it would be impossible for
> >GDB to translate \abc into an absolute path. If the compiler was nieve
> >enought to put \abc, it's possible that the current drive is different
> >when GDB looks for the file then when the user compiled it. (Sorry, I
> >know you already said this, but I believe if I type it all out, it just
> >might sink in)
> >
> >I asked a question in this Email,
> >http://sources.redhat.com/ml/gdb-patches/2005-05/msg00100.html
> 
> Has anyone actually confirmed that gcc will put \abc or x:abc in source
> files?

Well, utils.c:xfullpath in GDB has a comment I posted earlier,

#ifdef HAVE_DOS_BASED_FILE_SYSTEM
  /* We need to be careful when filename is of the form 'd:foo', which
     is equivalent of d:./foo, which is totally different from d:/foo.  */
  if (strlen (dir_name) == 2 && isalpha (dir_name[0]) && dir_name[1] == ':')
    {
      dir_name[2] = '.';
      dir_name[3] = '\000';
    }
#endif

That leads me to believe that at some point, GDB was getting d:foo from
the compiler as a path. This may have been a compiler bug that was fixed
however.

Thanks,
Bob Rossi