From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14569 invoked by alias); 5 Mar 2011 12:45:19 -0000 Received: (qmail 14557 invoked by uid 22791); 5 Mar 2011 12:45:18 -0000 X-SWARE-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,FSL_RU_URL,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST X-Spam-Check-By: sourceware.org Received: from mail-qy0-f169.google.com (HELO mail-qy0-f169.google.com) (209.85.216.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 05 Mar 2011 12:45:14 +0000 Received: by qyk2 with SMTP id 2so936221qyk.0 for ; Sat, 05 Mar 2011 04:45:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.136.9 with SMTP id p9mr1518569qat.187.1299329112029; Sat, 05 Mar 2011 04:45:12 -0800 (PST) Received: by 10.229.89.197 with HTTP; Sat, 5 Mar 2011 04:45:11 -0800 (PST) In-Reply-To: <4D721C43.1070804@sw.ru> References: <20110303145832.GY30306@adacore.com> <83tyfkw00f.fsf@gnu.org> <201103041037.p24AbPBb001379@glazunov.sibelius.xs4all.nl> <4D721C43.1070804@sw.ru> Date: Sat, 05 Mar 2011 12:45:00 -0000 Message-ID: Subject: Re: [patch gdb]: Fix some DOS-path related issues in gdb From: Kai Tietz To: Vladimir Simonov Cc: Mark Kettenis , eliz@gnu.org, brobecker@adacore.com, gdb-patches@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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/msg00367.txt.bz2 2011/3/5 Vladimir Simonov : > 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? =A0With what toolchains? >>>>>>> >>>>>>> As for mdebugread.c, I always thought it was MIPS specific. =A0What >>>>>>> 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? =A0Who would develop on Windows if t= hey >>>>> 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. =A0Backslashes don't have a special meaning; they're just like >>> normal letters. =A0That's exactly why a native debugger on a Unix-like >>> system should not try to be DOS compatible at all. =A0And 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 =A0'C:/source/xyz.c" are absolute= ly > 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 > Yes, this patch at least avoids issues about written out file-information. But of course it doesn't touch the comparision problematic itself. There are in gcc still a lot of issues about file-comparisions and directory separators. Btw your patch looks suitable for normalization from windows -> unix like file-system, but not for vice-verse, as you are using here libiberties path-separator macros, which are itself host dependent. I prepared for gcc already a patch-set for addressing native-filename comparision, but well, stage-4 doesn't look suitable for this. Regards, Kai