From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32162 invoked by alias); 11 Oct 2006 13:33:05 -0000 Received: (qmail 32148 invoked by uid 22791); 11 Oct 2006 13:33:04 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Wed, 11 Oct 2006 13:32:58 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1GXeCc-0006bb-Ok; Wed, 11 Oct 2006 09:32:54 -0400 Date: Wed, 11 Oct 2006 13:33:00 -0000 From: Daniel Jacobowitz To: Denis PILAT Cc: Eli Zaretskii , gdb-patches@sourceware.org Subject: Re: '\r' only end-of-line Message-ID: <20061011133254.GA25164@nevyn.them.org> Mail-Followup-To: Denis PILAT , Eli Zaretskii , gdb-patches@sourceware.org References: <452A6905.1040308@st.com> <452B9EB9.4040709@st.com> <452BB767.5000407@st.com> <452CC287.4050401@st.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <452CC287.4050401@st.com> User-Agent: Mutt/1.5.13 (2006-08-11) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-10/txt/msg00108.txt.bz2 On Wed, Oct 11, 2006 at 12:08:07PM +0200, Denis PILAT wrote: > >I think part of your patch is not needed: the Windows port of GDB > >should use the LSEEK_NOT_LINEAR branch of the code in > >find_source_lines, so the code you are patching doesn't need to > >consider the \r\n case. > > > Yes but when you use a linux hosted compiler for reading windows source > file > (sorry for that weirdness but we sometime have common source file for > both OS), > then this case may happen. I was just thinking about this the other day... As a general position, are we willing to support things written / compiled on other hosts? This includes both line endings and pathnames. I hope the answer is yes, but I don't know. At CodeSourcery, as we've said before, we ship a native Windows GDB and GCC. But for a lot of things we have no way to test the native Windows GDB - can't use Cygwin's expect to drive it. So I found myself testing a Cygwin GDB using a customer's Windows-only SDK. And the debugger got very, very unhappy because there's a filename comparison in the dwarf reader; one of the arguments came from the compiler as "\foo\bar.h" and the other came in two pieces "\foo" and "bar.h". GDB assembled that as "\foo/bar.h" and FILENAME_CMP returned false. For my local testing I wrote a filename comparison function that allowed windows slashes. I didn't need to worry about case sensitivity here, because Windows tools are generally case-preserving unless you feed them input with strange casing. This was sort of unpleasant, but useful. And in thinking about it, I think I'd rather have this return true than false: FILENAME_CMP ("a\\b", "a/b") Since almost no one puts backslashes in Unix filenames (they're a mental health hazard), and having a\\b and a/b is a truly improbable case. What do y'all think? Would a gdb_filename_cmp with this behavior be OK? -- Daniel Jacobowitz CodeSourcery