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

Vladimir Simonov
2011-03-05T11:38:48Z

[-- 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;