RE: gdb and older cygwins

["Dave Korn" <dk@artimi.com>]

> -----Original Message-----
> From: gdb-owner n Behalf Of Michael Chastain
> Sent: 26 August 2004 13:53
> To: gdb; Cenedese
> Subject: Re: gdb and older cygwins
> 
> 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...

  My first hint is this:  never use WinZIP to unpack a tarball in a cygwin
environment, because it does the wrong thing with soft-links and it mangles
all the line endings.  Use "tar xfv" instead.

 [Did I guess correctly how you managed to get your gcc sources mangled?]

> I can think of six strategies to try:

> (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.

  Actually there's no need to do anything so complex at all.  Since the size
of the processed data will always be less than the size of the original
data, because all we ever do is remove '\r' bytes, you can just read it
directly into the caller-supplied buffer and post-process it in situ.  As to
the second part of the problem, well, given that this routine only has to
handle text input to a compiler, and not general binary files, and assuming
that not being able to parse mac-style CR-only line ends won't be a problem,
you really only need to delete every '\r' and not even care whether there's
a '\n' following or not, nor whether there might happen to be a \r\n split
across two reads.

> (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.

  Cygwin provides a cunning way to avoid having to hack on the sources to to
this.  Simply link with the cygwin standard library file /lib/textmode.o and
it will intercept all calls to open and add the O_TEXT flag for you.  See 

http://www.cygwin.com/ml/cygwin/2002-10/msg00172.html

for evidence that this approach is known to work with gcc-2.95.3 under
cygwin; see

http://www.mail-archive.com/cygwin-apps@sources.redhat.com/msg00022.html

for a clear explanation of what these various object files (textmode.o,
binmode.o, automode.o) do.

> (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.

  Instead, just create a textmode mountpoint solely for the gcc source
directory.  That way nothing else should be affected.  Note that you'll have
to give an absolute path to configure when you invoke it, or use the
--srcdir= argument to configure to specify the mountpoint rather than any
other equivalent but non-textmode path to the sources.

    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....