From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17015 invoked by alias); 5 Mar 2011 09:13:26 -0000 Received: (qmail 17003 invoked by uid 22791); 5 Mar 2011 09:13:25 -0000 X-SWARE-Spam-Status: No, hits=-1.1 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST X-Spam-Check-By: sourceware.org Received: from mail-qw0-f41.google.com (HELO mail-qw0-f41.google.com) (209.85.216.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 05 Mar 2011 09:13:21 +0000 Received: by qwd7 with SMTP id 7so2815460qwd.0 for ; Sat, 05 Mar 2011 01:13:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.101.40 with SMTP id a40mr1322609qco.82.1299316399164; Sat, 05 Mar 2011 01:13:19 -0800 (PST) Received: by 10.229.89.197 with HTTP; Sat, 5 Mar 2011 01:13:19 -0800 (PST) In-Reply-To: <201103041037.p24AbPBb001379@glazunov.sibelius.xs4all.nl> References: <20110303145832.GY30306@adacore.com> <83tyfkw00f.fsf@gnu.org> <201103041037.p24AbPBb001379@glazunov.sibelius.xs4all.nl> Date: Sat, 05 Mar 2011 09:13:00 -0000 Message-ID: Subject: Re: [patch gdb]: Fix some DOS-path related issues in gdb From: Kai Tietz To: Mark Kettenis Cc: 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/msg00363.txt.bz2 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 th= ey >> > 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. Even worse it gets by the second example provided by Andr=E9 in his post. As here on a linux based OS the file "..\\calendar\\main.cpp" directory "C:\\SDK1\\Examples\\4.7\\richtext\\calendar-build-desktop/". So if gdb should be able to debug a native application, which might be cross-compiled on a different host with a different file-system, the is for sure a lot of work. Nevertheless my patch didn't addressed that.It just fixes the obvious bug in file-comparision on Windows-like filesystems. It won't change behavior on Unix-like OS AFAICS. Kai