[PATCH] source.s: Fix problem handling windows like path with MinGW

[PATCH] source.s: Fix problem handling windows like path with MinGW

[Michael Fischer]

Hello,

the patch below will fix the problem if an application sends path
information like "d:\foo1\foo2" instead of "/d/foo1/foo2"

I has some problem to get Eclipse running with a MinGW based arm toolchain.
The debugger could not find the source information.

I have change the openp function which try to find a file given by string
and searching in path.

Here are some examples how the path could look like:

1. "D:\Projekte\Eclipse\Test:$cwd"
2.
"D:\Projekte\Eclipse\Test:D:\Projekte\Eclipse\Test\src:D:\Projekte\Eclipse\T
est\inc:$cwd"

The problem is, that the DIRNAME_SEPARATOR is used to separate
path part-one from path part-two and so on. In case #1
"D:\Projekte\Eclipse\STR7Test"
from "$cwd". At the same time DIRNAME_SEPARATOR  is used to separate
the drive from the path itself <drive>:<path>.

If the application send only path information like:

3. "/D/Projekte/Eclipse/Test:$cwd"
4.
"/D/Projekte/Eclipse/Test:/D/Projekte/Eclipse/Test/src:/D/Projekte/Eclipse/T
est/inc:$cwd"

the old implementation is working, here we can use the DIRNAME_SEPARATOR
to separate each path from another. But for #1 we got
"\Projekte\Eclipse\Test", the drive
information is missing here. The additional code should handle the problem.

I have done the diff against gdb-6.5.50.20060615.tar.bz2, sorry I do not
know how
can I make a diff against the cvs tree.

Please check it, specially if it is allowed to use alloca more than one
time.

Can someone take it to the CVS if this patch is axactable?

Best regards,

Michael
PS: This is my first patch here, therefore I could use the wrong style for
it.
Please correct me.



diff -Naur gdb-6.5.50.20060615/gdb/source.c
gdb-6.5.50.20060615-arm/gdb/source.c
--- gdb-6.5.50.20060615/gdb/source.c	Mon May 15 15:50:13 2006
+++ gdb-6.5.50.20060615-arm/gdb/source.c	Sat Jun 17 15:56:11 2006
@@ -721,6 +721,109 @@
   /* ./foo => foo */
   while (string[0] == '.' && IS_DIR_SEPARATOR (string[1]))
     string += 2;
+
+#ifdef __MINGW32__
+  alloclen = strlen (path) + strlen (string) + 2;
+  filename = alloca (alloclen);
+  fd = -1;
+
+  /*
+   * Special handling for a windows path.
+   * Here are some examples how the path could look like:
+   *
+   * 1. "D:\Projekte\Eclipse\Test:$cwd"
+   * 2.
"D:\Projekte\Eclipse\Test:D:\Projekte\Eclipse\Test\src:D:\Projekte\Eclipse\T
est\inc:$cwd"
+   *
+   * The problem is, that the DIRNAME_SEPARATOR is used to separate
+   * path one from path two and so on. In case #1
"D:\Projekte\Eclipse\STR7Test"
+   * from "$cwd". At the same time DIRNAME_SEPARATOR  is used to separate
+   * the drive from the path itself <drive>:<path>.
+   *
+   * If the application send only path information like:
+   *
+   * 3. "/D/Projekte/Eclipse/Test:$cwd"
+   * 4.
"/D/Projekte/Eclipse/Test:/D/Projekte/Eclipse/Test/src:/D/Projekte/Eclipse/T
est/inc:$cwd"
+   *
+   * the old implementation is working, here we can use the
DIRNAME_SEPARATOR
+   * to separate each path from another. But for #1 we got
"\Projekte\Eclipse\Test", the drive
+   * information is missing here. The additional code should handle the
problem.
+   */
+  p = path;
+  while (*p != 0)
+  {
+    if (IS_ABSOLUTE_PATH(p))
+    {
+      /* Start to extract the path */
+
+      /* Copy the  <drive> and DIRNAME_SEPARATOR */
+      strncpy(filename, path, 2);
+      p   = p + 2;
+      len = 2;
+
+      /* Copy the rest up to the next DIRNAME_SEPARATOR */
+      while ((*p != DIRNAME_SEPARATOR) && (len < alloclen))
+      {
+        filename[len++] = *p++;
+      }
+      filename[len] = 0;
+
+      /* At this point we have the path
+         information and can add the string */
+      strcat (filename, SLASH_STRING);
+      strcat (filename, string);
+
+      /* Jump over the ":",
+         for the next round */
+      p++;
+    }
+    else
+    {
+      /* No absolute path found, this could be the current dir
+         or a mix of windows style and the other one */
+	    len = strlen (p);
+      if (len == 4 && p[0] == '$' && p[1] == 'c' && p[2] == 'w' && p[3] ==
'd')
+	    {
+	      /* Name is $cwd -- insert current directory name instead.  */
+	      int newlen;
+
+	      /* First, realloc the filename buffer if too short. */
+	      len = strlen (current_directory);
+	      newlen = len + strlen (string) + 2;
+	      if (newlen > alloclen)
+	      {
+	        alloclen = newlen;
+	        filename = alloca (alloclen);
+	      }
+	      strcpy (filename, current_directory);
+        strcat (filename, SLASH_STRING);
+        strcat (filename, string);
+
+        /* Jump over the $cwd, p should no point to the
+           end (*p==0), and we will leave the loop after
+           the last filename check */
+        p += 4;
+      }
+      else
+      {
+        /* It was not the $cwd, we does not handle this
+           situation, leave the loop */
+        break;
+      }
+    } /* end if (IS_ABSOLUTE_PATH(p))*/
+
+    /* We have a filename and can check it */
+    if (is_regular_file (filename))
+	  {
+	    fd = open (filename, mode);
+	    if (fd >= 0)
+      {
+        /* We have found the file */
+	      goto done;
+      }
+	  }
+
+  } /* while (*p != 0) */
+#endif /* __MINGW32__ */

   alloclen = strlen (path) + strlen (string) + 2;
   filename = alloca (alloclen);

Re: [PATCH] source.s: Fix problem handling windows like path with MinGW

[Eli Zaretskii]

> From: "Michael Fischer" <fischermi@t-online.de>
> Date: Sat, 17 Jun 2006 18:23:23 +0200
> 
> the patch below will fix the problem if an application sends path
> information like "d:\foo1\foo2" instead of "/d/foo1/foo2"

Thank you for your contribution.

However, I'm not sure I understand the details and/or the motivation.
The patch is MinGW-specific, so I'd expect the source path to use `;',
not `:', to separate directories.  That is what I see in my
MinGW-compiled GDB (built for native Windows debugging).

In other words, DIRNAME_SEPARATOR is supposed to be `;' in this
build.  Can you explain how it became `:'?

> Here are some examples how the path could look like:
> 
> 1. "D:\Projekte\Eclipse\Test:$cwd"
> 2. "D:\Projekte\Eclipse\Test:D:\Projekte\Eclipse\Test\src:D:\Projekte\Eclipse\Test\inc:$cwd"

If you want GDB to distinguish between the two different uses of `:',
then I think we shouldn't even try.  While it's probable that in
"d:\foo:c:\bar" the 1st and the 3rd colon are not separators but parts
of the drive letter, nothing prevents a user from legitimately using
it in a non-probable way, i.e. the user could really mean to search
the directories `d', `\foo', `c', and `\bar'.  GDB has no business
second-guessing the user's intent, IMHO.

The solution to this, IMO, is to make sure your GDB uses `;' to
separate directories in paths.