From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12550 invoked by alias); 26 Aug 2004 12:53:09 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 12359 invoked from network); 26 Aug 2004 12:53:06 -0000 Received: from unknown (HELO smtp6.mindspring.com) (207.69.200.110) by sourceware.org with SMTP; 26 Aug 2004 12:53:06 -0000 Received: from user-119a90a.biz.mindspring.com ([66.149.36.10] helo=berman.michael-chastain.com) by smtp6.mindspring.com with esmtp (Exim 3.33 #1) id 1C0JkV-0001HP-00; Thu, 26 Aug 2004 08:53:03 -0400 Received: from mindspring.com (localhost [127.0.0.1]) by berman.michael-chastain.com (Postfix) with SMTP id DAF4F4B102; Thu, 26 Aug 2004 08:53:15 -0400 (EDT) Date: Thu, 26 Aug 2004 12:53:00 -0000 From: Michael Chastain To: gdb@sources.redhat.com, Cenedese@indel.ch Subject: Re: gdb and older cygwins Message-ID: <412DDD3B.nail3NS112HDC@mindspring.com> References: <5.2.0.9.1.20040826130046.01d35970@NT_SERVER> In-Reply-To: <5.2.0.9.1.20040826130046.01d35970@NT_SERVER> User-Agent: nail 10.8 6/28/04 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2004-08/txt/msg00383.txt.bz2 Fabian Cenedese wrote: > PS: The other solution would be to fix the 2.95.3 source about this > CRLF bug. I looked into the gcc list but couldn't find simple patches, > I guess it needs a bigger change. If anyone has some hints about it... Well first, gcc 2.95.3 is no longer supported on Cygwin. So you are on your own. But I do have some hints about it. gcc 2.95.3 has two preprocessors: the old standalone preprocessor in cccp.c, and the new integrated preprocessor library in cpp*.c. The old standalone preprocessor is the default. The old standalone preprocessor is in cccp. It's all about '\\' and '\n' and doesn't understand '\r' very well. I can think of six strategies to try: (1) Go into cccp.c and fix every occurrence of '\\' '\n' tests to accept '\\' '\r' '\n' as well. (2) Hack on safe_read so that it converts "\r\n" => "\n". Essentially you need to allocate a private buffer, do the raw read into the private buffer, and then translate from the private buffer to the caller-supplied buffer. A problem occurs when the '\r' happens at the end of one read and the '\n' happens at the beginning of the next read. (3A) Change every occurence of "open" to include O_TEXT as part of the mode. That is what O_TEXT is for! It ought to work great, except that it only works on systems that actually support O_TEXT, like Cygwin. You would still not be able to compile your "\r\n" files on a non-Cygwin system with gcc 2.95.3. (3B) Like 3A, only copy a trick from the VMS support code: #if defined(__CYGWIN__) #define open(fname,mode,prot) open(fname,(mode|O_TEXT),prot) #endif That might actually be all the code you need! (4) Try building gcc with the new integrated preprocessor instead of the old standalone preprocessor. Configure with --enable-cpplib or with --disable-cpp --enable-cpplib. However, this was all new code in 2.95.3, so it might have had new and exciting bugs. (5) Mount your Cygwin filesystems with the "text" option. All Cygwin programs will see "\n" line endings instead of "\r\n". This is likely to fix the problems with gcc, but cause other random problems with other random programs. I would recommend (3B), followed by (1). (2) is attractive but if you don't handle the edge case then you will have random intermittent losses. (4) and (5) have side effects that you would have to handle. Hope this helps, Michael Chastain