From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12281 invoked by alias); 5 Mar 2011 11:38:48 -0000 Received: (qmail 12264 invoked by uid 22791); 5 Mar 2011 11:38:47 -0000 X-SWARE-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,BAYES_00,FSL_RU_URL X-Spam-Check-By: sourceware.org Received: from mail.apical.co.uk (HELO srv1.office.apical.co.uk) (213.106.251.44) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 05 Mar 2011 11:38:41 +0000 Received: from [10.250.149.213] (23.nat.acronis.net [91.195.22.23]) (authenticated bits=0) by srv1.office.apical.co.uk (8.14.4/8.14.4) with ESMTP id p25BbSYg023649 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 5 Mar 2011 11:37:29 GMT Message-ID: <4D721C43.1070804@sw.ru> Date: Sat, 05 Mar 2011 11:38:00 -0000 From: Vladimir Simonov User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100430 Fedora/3.0.4-2.fc11 Thunderbird/3.0.4 MIME-Version: 1.0 To: Kai Tietz CC: Mark Kettenis , eliz@gnu.org, brobecker@adacore.com, gdb-patches@sourceware.org Subject: Re: [patch gdb]: Fix some DOS-path related issues in gdb References: <20110303145832.GY30306@adacore.com> <83tyfkw00f.fsf@gnu.org> <201103041037.p24AbPBb001379@glazunov.sibelius.xs4all.nl> In-Reply-To: Content-Type: multipart/mixed; boundary="------------090309050008000708030106" X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2011-03/txt/msg00365.txt.bz2 This is a multi-part message in MIME format. --------------090309050008000708030106 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-length: 2876 On 03/05/2011 12:13 PM, Kai Tietz wrote: > 2011/3/4 Mark Kettenis: >>> Date: Fri, 4 Mar 2011 10:48:35 +0100 >>> From: Kai Tietz >>> >>> 2011/3/3 Eli Zaretskii: >>>>> Date: Thu, 3 Mar 2011 18:58:32 +0400 >>>>> From: Joel Brobecker >>>>> Cc: Kai Tietz, 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 --------------090309050008000708030106 Content-Type: text/plain; name="gcc-dosbase.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="gcc-dosbase.patch" Content-length: 860 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; --------------090309050008000708030106 Content-Type: text/plain; name="gcc-4.4.2-filename-normalize.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="gcc-4.4.2-filename-normalize.patch" Content-length: 3971 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; --------------090309050008000708030106--