Re: [patch gdb]: Fix some DOS-path related issues in gdb

[Vladimir Simonov <sv@sw.ru>]

[-- Attachment #1: Type: text/plain, Size: 2876 bytes --]

On 03/05/2011 12:13 PM, Kai Tietz wrote:
> 2011/3/4 Mark Kettenis<mark.kettenis@xs4all.nl>:
>>> Date: Fri, 4 Mar 2011 10:48:35 +0100
>>> From: Kai Tietz<ktietz70@googlemail.com>
>>>
>>> 2011/3/3 Eli Zaretskii<eliz@gnu.org>:
>>>>> Date: Thu, 3 Mar 2011 18:58:32 +0400
>>>>> From: Joel Brobecker<brobecker@adacore.com>
>>>>> Cc: Kai Tietz<ktietz70@googlemail.com>, gdb-patches@sourceware.org
>>>>>
>>>>>> I didn't know that the Windows 64bit target can use ELF debug info.
>>>>>> Can it?  With what toolchains?
>>>>>>
>>>>>> As for mdebugread.c, I always thought it was MIPS specific.  What
>>>>>> other platforms use it?
>>>>>
>>>>> These would still be pertinent in the case of cross debugging, no?
>>>>> If the files were cross-compiled on Windows, the debug info would
>>>>> contain file paths that follow the Windows convention...
>>>>
>>>> Is that use-case even practical?  Who would develop on Windows if they
>>>> have Linux or Irix?
>>>>
>>>> Anyway, if others don't mind to have DOS-ism in mdebugread.c and
>>>> elfread.c, I don't object.
>>>>
>>>
>>> I didn't saw here direct objections. So ok for apply?
>>>
>>> On a second thought about Pedros's switch for turning on
>>> case-(in)sensitive-ness by switch, it could be helpful. But the
>>> slash/backslash issue is something pretty incompatible. Windows host
>>> don't have issues in general (not for all API) to use slash and
>>> backslash, but on unix filesystem a backslash causes troubles. So we
>>> need here some path/filename normalization.
>>
>> There is no problem with backslashes in path names on Unix-like
>> systems.  Backslashes don't have a special meaning; they're just like
>> normal letters.  That's exactly why a native debugger on a Unix-like
>> system should not try to be DOS compatible at all.  And if you ask me,
>> the same is true for a cross-debugger for a Unix-like target running
>> on a Unix-like host.
>
> I didn't said that backslashes are forbidden characters in
> file/directory names, I just mentioned that they are causing problems.
> And well, you provided here the best example. A referenced filename -
> eg. 'C:\source\xyz.c" - would be treated on Unix-like filesystem as
> one file name and it wouldn't be an absolute path at all. How a user
> should be able to match such a thing? Symbolic links (as suggested
> before) won't work.
Sorry for confusing about C: link.

Yes, I've met the same problem several
years ago. The solution was - fix original names on Windows side.
For Windows names 'C:\source\xyz.c" and  'C:/source/xyz.c" are absolutely
equivalent. If we replace "\\" with "/" in gcc command line,
debug info will have records like C:/source/xyz.c

Probably gcc-dosbase it is not needed - gcc command may
converted by some external filter...

With this patches all should be ok. I mean C: link or directory
in current WD should work

Best regards
Vladimir Simonov

[-- Attachment #2: gcc-dosbase.patch --]
[-- Type: text/plain, Size: 860 bytes --]

Vladimir Simonov(sv@sw.ru) - mingw support.
Useful if you crossbuild Linux app on Windows.
- Debug info now contains C:/mydir/myfile.c (vs. C:\mydir\myfile.c).
  This permits debug such app on Linux box (just create C: dir or simlink
  and simulate appropriate path.
Index: gcc/gcc/gcc.c
===================================================================
--- gcc.orig/gcc/gcc.c
+++ gcc/gcc/gcc.c
@@ -6207,6 +6207,16 @@ main (int argc, char **argv)
   struct user_specs *uptr;
   char **old_argv = argv;
 
+#if HAVE_DOS_BASED_FILE_SYSTEM
+   if (argc > 0)
+     {
+	   char *pp;
+	   argv[0]=xstrdup (argv[0]);
+	   while ((pp = strchr (argv[0], '\\')) != NULL)
+		 *pp = '/';
+     }
+#endif
+
   /* Initialize here, not in definition.  The IRIX 6 O32 cc sometimes chokes
      on ?: in file-scope variable initializations.  */
   asm_debug = ASM_DEBUG_SPEC;

[-- Attachment #3: gcc-4.4.2-filename-normalize.patch --]
[-- Type: text/plain, Size: 3971 bytes --]

Vladimir Simonov(sv@sw.ru) - normailize filenames.
Useful if you crossbuild Linux app on Windows.
- Make filenames a bit shorter (constractions like ../dir/../ are collapced
  into ../dir). It sometimes helps to avoid Windows ascii-filenames length
  restriction (near to 160 bytes as I remenber).

--- gcc-4.4.2/include/filenames.h.orig	2010-01-28 14:58:49.000000000 +0300
+++ gcc-4.4.2/include/filenames.h	2010-01-28 16:26:23.000000000 +0300
@@ -52,6 +52,8 @@
 
 extern int filename_cmp (const char *s1, const char *s2);
 #define FILENAME_CMP(s1, s2)	filename_cmp(s1, s2)
+extern void filename_normalize (char *f);
+#define FILENAME_NORMALIZE(f)	filename_normalize(f)
 
 #ifdef __cplusplus
 }
--- gcc-4.4.2/libiberty/filename_cmp.c.orig	2010-01-28 14:59:04.000000000 +0300
+++ gcc-4.4.2/libiberty/filename_cmp.c	2010-01-28 16:23:36.000000000 +0300
@@ -76,3 +76,116 @@
 #endif
 }
 
+#ifdef HAVE_MEMMOVE
+#define memmove_left memmove
+#else
+static void *
+memmove_left (void *dest, const void *src, int n)
+{
+   char *d;
+   const char *s;
+   int i;
+   for (d = (char *)dest, s = (const char *)src, i = 0; i < n; i++)
+     *d++ = *s++;
+}
+#endif
+
+/*
+
+@deftypefn Extension void filename_normalize (char *@var{fn})
+
+This function tries to normalize file names inplace.
+
+@end deftypefn
+
+*/
+
+#ifndef HAVE_DOS_BASED_FILE_SYSTEM
+void
+filename_normalize (char *fn)
+#else
+static void
+filename_normalize_unix (char *fn)
+#endif
+{
+  char *p;
+  int rest;
+
+  rest = strlen (fn) + 1;
+  for (p = fn; *p != '\0' ; p++, rest--)
+    {
+      char *next;
+      const char *next2;
+      const char *next3;
+
+      next = p + 1;
+      if (*next == '\0')
+        break;
+      if (!IS_DIR_SEPARATOR( *p))
+          continue;
+      next2 = p + 2;
+      next3 = p + 3;
+      *p = '/';
+      /* don't handle some special cases, i.e. "//C/" on Microsoft Windows */
+      if (IS_DIR_SEPARATOR (*next))
+        {
+          memmove_left (next, next2, rest - 2);
+          p--;
+          continue;
+        }
+      if (*next != '.' || *next2 == '\0' || *next3 == '\0')
+          continue;
+      /* simplify "./" case */
+      if (IS_DIR_SEPARATOR (*next2))
+        {
+          memmove_left (next, next3, rest - 3);
+          rest--;
+          p--;
+          continue;
+        }
+      if (*next2 != '.' || ! IS_DIR_SEPARATOR (*next3))
+        continue;
+      while (--p >= fn)
+        {
+          if (*p == '/')
+            break;
+        }
+      if (p < fn)
+        {
+          if (*fn == '/')
+              memmove_left (p + 2, next3 + 1, rest - 4);
+          else if (*fn != '.')
+              memmove_left (p + 1, next3 + 1, rest - 4);
+          else
+            {
+              p = next - 1;
+              continue;
+            }
+        }
+      else if (*(p + 1) != '.')
+        {
+          memmove_left (p + 1, next3 + 1, rest - 4);
+          p--;
+        }
+      else
+        {
+          p = next - 1;
+          continue;
+        }
+      rest -= 2;
+    }
+}
+
+
+#ifdef HAVE_DOS_BASED_FILE_SYSTEM
+void
+filename_normalize (char *fn)
+{
+  if (IS_DIR_SEPARATOR (fn[0]) || ! IS_ABSOLUTE_PATH (fn))
+    /* Absolute path in Unix style or relative path */
+    filename_normalize_unix (fn);
+  else if (fn[1] != '\0')
+    filename_normalize_unix (fn + 2);
+}
+#endif
+
--- gcc-4.4.2/libcpp/directives.c.orig	2010-01-28 15:09:00.000000000 +0300
+++ gcc-4.4.2/libcpp/directives.c	2010-01-28 16:28:04.000000000 +0300
@@ -716,6 +716,7 @@
       return NULL;
     }
 
+  FILENAME_NORMALIZE (fname);
   if (pfile->directive == &dtable[T_PRAGMA])
     {
       /* This pragma allows extra tokens after the file name.  */
--- gcc-4.4.2/libcpp/files.c.orig	2010-02-12 11:47:27.886977300 +0300
+++ gcc-4.4.2/libcpp/files.c	2010-02-14 15:38:39.757260300 +0300
@@ -355,6 +355,7 @@
 
   if (path)
     {
+      FILENAME_NORMALIZE (path);
       hashval_t hv = htab_hash_string (path);
       char *copy;
       void **pp;