[patch] Build arm-elf-gdb on mingw host

[patch] Build arm-elf-gdb on mingw host

[Dave Murphy]

[-- Attachment #1: Type: text/plain, Size: 1131 bytes --]

When building the bfd/doc directory under mingw/msys chew.c converts 
line endings to crlf.  I've patched so the files are read as binary, 
preventing this conversion.


Currently the rdi-share directory can't be built for a windows native 
host http://sourceware.org/ml/gdb/2005-08/msg00058.html. I've copied the 
embed.mt file, renamed to mingw_embed.mt and removed the parts which 
don't build then patched configure.tgt so that the new .mt file is used 
when building for a mingw host.

SIGTRAP isn't defined in the MinGW headers, I patched remote-sim.c to 
define this if it's not defined.

There are some other problems to deal with to get the debugger working 
with thumb code, my arm-elf toolchain is binutils 2.16.1, gcc 4.0.1 and 
newlib 1.13.0. With this combination gdb doesn't recognise thumb symbols 
in the generated elf, at least when setting breakpoints. Debugging ARM 
only code seems to work well.

The attached patch is against current CVS HEAD. To whomever is 
responsible for getting the gdb sources to a point where such minimal 
patching is required on MinGW, great work, it's very much appreciated.

Dave.

[-- Attachment #2: mingw-gdb.patch --]
[-- Type: text/plain, Size: 2380 bytes --]

2005-09-25  Dave Murphy  <davem@devkitpro.org>

	* chew.c: Prevent conversion of line endings on mingw.
	* configure.tgt: Use mingw_embed.mt on mingw.
	* remote-sim.c: Define SIMTRAP on mingw.
	* mingw_embed.mt: Add.
	
Index: bfd/doc/chew.c
===================================================================
RCS file: /cvs/src/src/bfd/doc/chew.c,v
retrieving revision 1.19
diff -u -r1.19 chew.c
--- bfd/doc/chew.c	24 Jul 2005 16:57:42 -0000	1.19
+++ bfd/doc/chew.c	25 Sep 2005 21:47:59 -0000
@@ -92,6 +92,12 @@
 #define DEF_SIZE 5000
 #define STACK 50
 
+#ifdef __MINGW32__
+/* Prevent \r\n\ line endings */
+#include <fcntl.h>
+unsigned int _CRT_fmode = _O_BINARY;
+#endif
+
 int internal_wanted;
 int internal_mode;
 
Index: gdb/configure.tgt
===================================================================
RCS file: /cvs/src/src/gdb/configure.tgt,v
retrieving revision 1.169
diff -u -r1.169 configure.tgt
--- gdb/configure.tgt	15 Aug 2005 21:46:38 -0000	1.169
+++ gdb/configure.tgt	25 Sep 2005 21:48:03 -0000
@@ -61,9 +61,14 @@
 arm-*-nto*)		gdb_target=nto ;;
 arm*-*-openbsd*)	gdb_target=nbsd ;;
 arm*-*-* | thumb*-*-* | strongarm*-*-*)
-			gdb_target=embed
-			build_rdi_share=yes
-                        ;;
+  case "${host}" in
+  *mingw*)	gdb_target=mingw_embed
+            ;;
+  * )  gdb_target=embed
+			 build_rdi_share=yes
+       ;;
+  esac
+  ;;
 xscale-*-*)		gdb_target=embed
 			build_rdi_share=yes
                         ;;
Index: gdb/remote-sim.c
===================================================================
RCS file: /cvs/src/src/gdb/remote-sim.c,v
retrieving revision 1.49
diff -u -r1.49 remote-sim.c
--- gdb/remote-sim.c	19 Jun 2005 20:08:37 -0000	1.49
+++ gdb/remote-sim.c	25 Sep 2005 21:48:07 -0000
@@ -44,6 +44,10 @@
 #include "sim-regno.h"
 #include "arch-utils.h"
 
+#ifndef SIGTRAP
+#define SIGTRAP 5
+#endif
+
 /* Prototypes */
 
 extern void _initialize_remote_sim (void);
Index: gdb/config/arm/mingw_embed.mt
===================================================================
RCS file: gdb/config/arm/mingw_embed.mt
diff -N gdb/config/arm/mingw_embed.mt
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ gdb/config/arm/mingw_embed.mt	25 Sep 2005 21:48:09 -0000
@@ -0,0 +1,7 @@
+# Target: ARM embedded system
+TDEPFILES= arm-tdep.o remote-rdp.o
+TDEPLIBS=
+DEPRECATED_TM_FILE= tm-embed.h
+
+SIM_OBS = remote-sim.o
+SIM = ../sim/arm/libsim.a

Re: [patch] Build arm-elf-gdb on mingw host

[Eli Zaretskii]

> Date: Mon, 26 Sep 2005 00:23:39 +0100
> From: Dave Murphy <wintermute2k4@ntlworld.com>
> 
> When building the bfd/doc directory under mingw/msys chew.c converts 
> line endings to crlf.  I've patched so the files are read as binary, 
> preventing this conversion.

Why?  What's wrong with having the output from chew have CRLF line
endings on Windows?

> SIGTRAP isn't defined in the MinGW headers, I patched remote-sim.c to 
> define this if it's not defined.

I don't think this is a good idea.  It is much better (and widely
practiced) to #ifdef away portions of code that use SIGTRAP, like
this:

    #ifdef SIGTRAP
    ... code that depends on SIGTRAP ...
    #endif

Re: [patch] Build arm-elf-gdb on mingw host

[Daniel Jacobowitz]

On Mon, Sep 26, 2005 at 06:46:10AM +0300, Eli Zaretskii wrote:
> > Date: Mon, 26 Sep 2005 00:23:39 +0100
> > From: Dave Murphy <wintermute2k4@ntlworld.com>
> > 
> > When building the bfd/doc directory under mingw/msys chew.c converts 
> > line endings to crlf.  I've patched so the files are read as binary, 
> > preventing this conversion.
> 
> Why?  What's wrong with having the output from chew have CRLF line
> endings on Windows?

Yeah, I'm wondering about this too.

> > SIGTRAP isn't defined in the MinGW headers, I patched remote-sim.c to 
> > define this if it's not defined.
> 
> I don't think this is a good idea.  It is much better (and widely
> practiced) to #ifdef away portions of code that use SIGTRAP, like
> this:
> 
>     #ifdef SIGTRAP
>     ... code that depends on SIGTRAP ...
>     #endif

In this case, unfortunately, it's a bit more complicated to fix.  You
can find a similar workaround patch from Paul Brook in the archives,
and my discussion (with Mark?) about it.  The gdb<->sim interface uses
"signals", meaning the host signal numbers.  And without SIGTRAP we
can't step or breakpoint.  Thus, a lot of files in sim already define
SIGTRAP.

They ought to be converted to the relatively new "gdb/signals.h" header
in include/, but the simulators are also concerned with actual host
signals in places, so a simple search and replace isn't right either.
It's going to take a little investigation to fix this properly.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: [patch] Build arm-elf-gdb on mingw host

[Dave Murphy]

Daniel Jacobowitz wrote:

>On Mon, Sep 26, 2005 at 06:46:10AM +0300, Eli Zaretskii wrote:
>  
>
>>>When building the bfd/doc directory under mingw/msys chew.c converts 
>>>line endings to crlf.  I've patched so the files are read as binary, 
>>>preventing this conversion.
>>>      
>>>
>>Why?  What's wrong with having the output from chew have CRLF line
>>endings on Windows?
>>    
>>
>
>Yeah, I'm wondering about this too.
>
>  
>
Sorry, I should have said that under mingw/msys files read in text mode 
have line endings converted. There are numerous places in chew.c where 
it checks for a newline character with expressions like "while (at (tos, 
idx) == '\n')", see skip_white_and_stars(src,  idx), 
strip_trailing_newlines(),  remove_noncomments (src, dst), 
outputdots(),  courierize(),  bulletize(), copy_past_newline (ptr, idx, 
dst), kill_bogus_lines(), indent(), skip_past_newline () and  nextword 
(string, word). It seemed easier to just read the input files as binary 
and suppress the conversion rather than make all the code deal with the 
"/r/n" sequence.

Without the supression we get the following error when building in bfd/doc

./chew.exe -f ../../../../gdb/bfd/doc/doc.str 
<../../../../gdb/bfd/doc/../mmo.c >mmo.tmp
/bin/sh ../../../../gdb/bfd/doc/../../move-if-change mmo.tmp mmo.texi
restore=: && backupdir=".am$$" && \
am__cwd=`pwd` && cd ../../../../gdb/bfd/doc && \
rm -rf $backupdir && mkdir $backupdir && \
for f in ../../../../gdb/bfd/doc/bfd.info 
../../../../gdb/bfd/doc/bfd.info-[0-9] 
../../../../gdb/bfd/doc/bfd.info-[0-9][0-9] ../../../../gdb
/bfd/doc/bfd.i[0-9] ../../../../gdb/bfd/doc/bfd.i[0-9][0-9]; do \
  if test -f $f; then mv $f $backupdir; restore=mv; else :; fi; \
done; \
cd "$am__cwd"; \
if makeinfo --split-size=5000000   -I ../../../../gdb/bfd/doc \
 -o ../../../../gdb/bfd/doc/bfd.info ../../../../gdb/bfd/doc/bfd.texinfo; \
then \
  rc=0; \
  cd ../../../../gdb/bfd/doc; \
else \
  rc=$?; \
  cd ../../../../gdb/bfd/doc && \
  $restore $backupdir/* `echo "./../../../../gdb/bfd/doc/bfd.info" | sed 
's|[^/]*$||'`; \
fi; \
rm -rf $backupdir; exit $rc
 section mapping'.ss reference to nonexistent node `mmo
 a New Hash Table Type'.ference to nonexistent node `Deriving
makeinfo: Removing output file `../../../../gdb/bfd/doc/bfd.info' due to 
errors; use --force to preserve.
make[2]: *** [../../../../gdb/bfd/doc/bfd.info] Error 2

This is due to @xref{mmo section mapping}.crossing a line boundary on 
line 67 of mmo.c

>>>SIGTRAP isn't defined in the MinGW headers, I patched remote-sim.c to 
>>>define this if it's not defined.
>>>      
>>>
>>I don't think this is a good idea.  It is much better (and widely
>>practiced) to #ifdef away portions of code that use SIGTRAP, like
>>this:
>>
>>    #ifdef SIGTRAP
>>    ... code that depends on SIGTRAP ...
>>    #endif
>>    
>>
>
>In this case, unfortunately, it's a bit more complicated to fix.  You
>can find a similar workaround patch from Paul Brook in the archives,
>and my discussion (with Mark?) about it.  The gdb<->sim interface uses
>"signals", meaning the host signal numbers.  And without SIGTRAP we
>can't step or breakpoint.  Thus, a lot of files in sim already define
>SIGTRAP.
>
>They ought to be converted to the relatively new "gdb/signals.h" header
>in include/, but the simulators are also concerned with actual host
>signals in places, so a simple search and replace isn't right either.
>It's going to take a little investigation to fix this properly.
>
>  
>
 From a brief look at the sources it appeared to me that it was a signal 
being passed internally between gdb and the simulator. I'll have a look 
for the previous discussions.

Dave

Re: [patch] Build arm-elf-gdb on mingw host

[Daniel Jacobowitz]

On Mon, Sep 26, 2005 at 05:46:17AM +0100, Dave Murphy wrote:
> Sorry, I should have said that under mingw/msys files read in text mode 
> have line endings converted. There are numerous places in chew.c where 
> it checks for a newline character with expressions like "while (at (tos, 
> idx) == '\n')", see skip_white_and_stars(src,  idx), 
> strip_trailing_newlines(),  remove_noncomments (src, dst), 
> outputdots(),  courierize(),  bulletize(), copy_past_newline (ptr, idx, 
> dst), kill_bogus_lines(), indent(), skip_past_newline () and  nextword 
> (string, word). It seemed easier to just read the input files as binary 
> and suppress the conversion rather than make all the code deal with the 
> "/r/n" sequence.

I'm afraid this explanation doesn't leave me any more enlightened.  Are
you saying that opening files in text mode, in mingw, produces \r\n in
the program view if there was originally just a \n?


-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: [patch] Build arm-elf-gdb on mingw host

[Christopher Faylor]

On Mon, Sep 26, 2005 at 09:23:26AM -0400, Daniel Jacobowitz wrote:
>On Mon, Sep 26, 2005 at 05:46:17AM +0100, Dave Murphy wrote:
>> Sorry, I should have said that under mingw/msys files read in text mode 
>> have line endings converted. There are numerous places in chew.c where 
>> it checks for a newline character with expressions like "while (at (tos, 
>> idx) == '\n')", see skip_white_and_stars(src,  idx), 
>> strip_trailing_newlines(),  remove_noncomments (src, dst), 
>> outputdots(),  courierize(),  bulletize(), copy_past_newline (ptr, idx, 
>> dst), kill_bogus_lines(), indent(), skip_past_newline () and  nextword 
>> (string, word). It seemed easier to just read the input files as binary 
>> and suppress the conversion rather than make all the code deal with the 
>> "/r/n" sequence.
>
>I'm afraid this explanation doesn't leave me any more enlightened.  Are
>you saying that opening files in text mode, in mingw, produces \r\n in
>the program view if there was originally just a \n?

I think I get it.  This patch just modifies chew so that it always
outputs '\n'.  Then you see '\n' on input no matter what.

Would it be possible to just link with binmode.o under mingw (and cygwin for
that matter)?

cgf

Re: [patch] Build arm-elf-gdb on mingw host

[Daniel Jacobowitz]

On Mon, Sep 26, 2005 at 10:08:41AM -0400, Christopher Faylor wrote:
> On Mon, Sep 26, 2005 at 09:23:26AM -0400, Daniel Jacobowitz wrote:
> >On Mon, Sep 26, 2005 at 05:46:17AM +0100, Dave Murphy wrote:
> >> Sorry, I should have said that under mingw/msys files read in text mode 
> >> have line endings converted. There are numerous places in chew.c where 
> >> it checks for a newline character with expressions like "while (at (tos, 
> >> idx) == '\n')", see skip_white_and_stars(src,  idx), 
> >> strip_trailing_newlines(),  remove_noncomments (src, dst), 
> >> outputdots(),  courierize(),  bulletize(), copy_past_newline (ptr, idx, 
> >> dst), kill_bogus_lines(), indent(), skip_past_newline () and  nextword 
> >> (string, word). It seemed easier to just read the input files as binary 
> >> and suppress the conversion rather than make all the code deal with the 
> >> "/r/n" sequence.
> >
> >I'm afraid this explanation doesn't leave me any more enlightened.  Are
> >you saying that opening files in text mode, in mingw, produces \r\n in
> >the program view if there was originally just a \n?
> 
> I think I get it.  This patch just modifies chew so that it always
> outputs '\n'.  Then you see '\n' on input no matter what.

Ah, so the problem is that makeinfo fails to handle the '\r\n'? 
Funny... I'd have expected an msys version of texinfo to expect \r\n.

> Would it be possible to just link with binmode.o under mingw (and cygwin for
> that matter)?

Maybe, but I'm not sure it's what we want here.  What about opening all
input files in text mode and all output files in binary mode, on all
platforms, if we need to do this?

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: [patch] Build arm-elf-gdb on mingw host

[Christopher Faylor]

On Mon, Sep 26, 2005 at 10:14:36AM -0400, Daniel Jacobowitz wrote:
>On Mon, Sep 26, 2005 at 10:08:41AM -0400, Christopher Faylor wrote:
>>On Mon, Sep 26, 2005 at 09:23:26AM -0400, Daniel Jacobowitz wrote:
>>>On Mon, Sep 26, 2005 at 05:46:17AM +0100, Dave Murphy wrote:
>>>>Sorry, I should have said that under mingw/msys files read in text mode
>>>>have line endings converted.  There are numerous places in chew.c where
>>>>it checks for a newline character with expressions like "while (at
>>>>(tos, idx) == '\n')", see skip_white_and_stars(src, idx),
>>>>strip_trailing_newlines(), remove_noncomments (src, dst), outputdots(),
>>>>courierize(), bulletize(), copy_past_newline (ptr, idx, dst),
>>>>kill_bogus_lines(), indent(), skip_past_newline () and nextword
>>>>(string, word).  It seemed easier to just read the input files as
>>>>binary and suppress the conversion rather than make all the code deal
>>>>with the "/r/n" sequence.
>>>
>>>I'm afraid this explanation doesn't leave me any more enlightened.  Are
>>>you saying that opening files in text mode, in mingw, produces \r\n in
>>>the program view if there was originally just a \n?
>>
>>I think I get it.  This patch just modifies chew so that it always
>>outputs '\n'.  Then you see '\n' on input no matter what.
>
>Ah, so the problem is that makeinfo fails to handle the '\r\n'?
>Funny...  I'd have expected an msys version of texinfo to expect \r\n.

Ditto.  I just checked and I didn't do this in earlier cygwin versions
but I did rectify at this at some point this year so that texinfo now
should be line-ending agnostic on cygwin.

>>Would it be possible to just link with binmode.o under mingw (and
>>cygwin for that matter)?
>
>Maybe, but I'm not sure it's what we want here.  What about opening all
>input files in text mode and all output files in binary mode, on all
>platforms, if we need to do this?

I think you're right.  This sounds like a problem in msys's texinfo
although just linking with binmode.o shouldn't really hurt anything even
if texinfo was fixed.

cgf

Re: [patch] Build arm-elf-gdb on mingw host

[Daniel Jacobowitz]

On Mon, Sep 26, 2005 at 10:26:11AM -0400, Christopher Faylor wrote:
> I think you're right.  This sounds like a problem in msys's texinfo
> although just linking with binmode.o shouldn't really hurt anything even
> if texinfo was fixed.

Wouldn't it break if the source files (bfd/*, inputs to chew) had DOS
line endings?  I know chew doesn't handle that.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: [patch] Build arm-elf-gdb on mingw host

[Christopher Faylor]

On Mon, Sep 26, 2005 at 10:30:47AM -0400, Daniel Jacobowitz wrote:
>On Mon, Sep 26, 2005 at 10:26:11AM -0400, Christopher Faylor wrote:
>> I think you're right.  This sounds like a problem in msys's texinfo
>> although just linking with binmode.o shouldn't really hurt anything even
>> if texinfo was fixed.
>
>Wouldn't it break if the source files (bfd/*, inputs to chew) had DOS
>line endings?  I know chew doesn't handle that.

"It depends" on the underlying mount table, at least on cygwin, and, I
assume, under msys.  If the directory is mounted in text mode then linking
with 'binmode.o' will help.  If it is mounted in 'binary mode' then linking
with 'binmode.o' will have no effect.

The 100% correct fix is, as you said, to always open the file in text
mode but there is, apparently, no POSIX-sanctioned way to do that,
although MSVCRT does allow "rt" or O_TEXT to force a text file open, I
believe.

cgf

Re: [patch] Build arm-elf-gdb on mingw host

[Eli Zaretskii]

> Date: Mon, 26 Sep 2005 10:30:47 -0400
> From: Daniel Jacobowitz <drow@false.org>
> 
> On Mon, Sep 26, 2005 at 10:26:11AM -0400, Christopher Faylor wrote:
> > I think you're right.  This sounds like a problem in msys's texinfo
> > although just linking with binmode.o shouldn't really hurt anything even
> > if texinfo was fixed.
> 
> Wouldn't it break if the source files (bfd/*, inputs to chew) had DOS
> line endings?

It most certainly would.  So 100% binary I/O is a problem waiting to
bite us, as soon as someone edits bfd/* sources with a Windows editor
that doesn't preserve EOL format.

Re: [patch] Build arm-elf-gdb on mingw host

[Daniel Jacobowitz]

On Mon, Sep 26, 2005 at 10:26:11AM -0400, Christopher Faylor wrote:
> On Mon, Sep 26, 2005 at 10:14:36AM -0400, Daniel Jacobowitz wrote:
> >On Mon, Sep 26, 2005 at 10:08:41AM -0400, Christopher Faylor wrote:
> >>I think I get it.  This patch just modifies chew so that it always
> >>outputs '\n'.  Then you see '\n' on input no matter what.
> >
> >Ah, so the problem is that makeinfo fails to handle the '\r\n'?
> >Funny...  I'd have expected an msys version of texinfo to expect \r\n.
> 
> Ditto.  I just checked and I didn't do this in earlier cygwin versions
> but I did rectify at this at some point this year so that texinfo now
> should be line-ending agnostic on cygwin.

Hi Chris,

Are you sure?  I had this exact GDB build failure today; then I
staggered through a Cygwin upgrade (it tried to eat itself in
the postinstall scripts...) and tried again, same behavior.  I'm using
Cygwin, no MSYS involved.

Sedding away the \r's in chew's output lets the build succeed.

This vaguely suggests that we ought to make chew only output \n's, for
compatibility...

-- 
Daniel Jacobowitz
CodeSourcery

Re: [patch] Build arm-elf-gdb on mingw host

[Christopher Faylor]

On Sat, Apr 08, 2006 at 04:21:35PM -0400, Daniel Jacobowitz wrote:
>On Mon, Sep 26, 2005 at 10:26:11AM -0400, Christopher Faylor wrote:
>> On Mon, Sep 26, 2005 at 10:14:36AM -0400, Daniel Jacobowitz wrote:
>> >On Mon, Sep 26, 2005 at 10:08:41AM -0400, Christopher Faylor wrote:
>> >>I think I get it.  This patch just modifies chew so that it always
>> >>outputs '\n'.  Then you see '\n' on input no matter what.
>> >
>> >Ah, so the problem is that makeinfo fails to handle the '\r\n'?
>> >Funny...  I'd have expected an msys version of texinfo to expect \r\n.
>> 
>> Ditto.  I just checked and I didn't do this in earlier cygwin versions
>> but I did rectify at this at some point this year so that texinfo now
>> should be line-ending agnostic on cygwin.
>
>Hi Chris,
>
>Are you sure?

That was six months ago.  If I had to guess, I'd guess that I wasn't
talking about a cygwin update since the cygwin \r\n handling hasn't
changed in years, AFAIK.  I was probably talking about a texinfo.
Texinfo links with the cygwin automode.o file, which means that it
should, by default, accept \r\n input and spit out \n.

cgf

Re: [patch] Build arm-elf-gdb on mingw host

[Daniel Jacobowitz]

On Mon, Apr 10, 2006 at 12:51:25PM -0400, Christopher Faylor wrote:
> >> Ditto.  I just checked and I didn't do this in earlier cygwin versions
> >> but I did rectify at this at some point this year so that texinfo now
> >> should be line-ending agnostic on cygwin.
> >
> >Hi Chris,
> >
> >Are you sure?
> 
> That was six months ago.  If I had to guess, I'd guess that I wasn't
> talking about a cygwin update since the cygwin \r\n handling hasn't
> changed in years, AFAIK.  I was probably talking about a texinfo.
> Texinfo links with the cygwin automode.o file, which means that it
> should, by default, accept \r\n input and spit out \n.

Right - sorry, I realized you meant a Texinfo package update.  As of
4.8-1, a MinGW chew (which produces \r\n) causes texinfo to choke, but
a Cygwin chew (which produces \n) does not.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [patch] Build arm-elf-gdb on mingw host

[Eli Zaretskii]

> Date: Mon, 26 Sep 2005 10:14:36 -0400
> From: Daniel Jacobowitz <drow@false.org>
> 
> What about opening all input files in text mode and all output files
> in binary mode, on all platforms, if we need to do this?

There's no easy way of doing that, AFAIK, except if we add "rt" and
"wb" to every call to `fopen' (or the respective O_BINARY and O_TEXT
to every call to `open').  Is that what you were suggesting?

Re: [patch] Build arm-elf-gdb on mingw host

[Christopher Faylor]

On Mon, Sep 26, 2005 at 10:16:12PM +0300, Eli Zaretskii wrote:
>> Date: Mon, 26 Sep 2005 10:14:36 -0400
>> From: Daniel Jacobowitz <drow@false.org>
>> 
>> What about opening all input files in text mode and all output files
>> in binary mode, on all platforms, if we need to do this?
>
>There's no easy way of doing that, AFAIK, except if we add "rt" and
>"wb" to every call to `fopen' (or the respective O_BINARY and O_TEXT
>to every call to `open').  Is that what you were suggesting?

It's easy to do in cygwin by just linking with "automode.o" (which causes
that behavior) but I don't think it's easy to do in raw mingw.

cgf

Re: [patch] Build arm-elf-gdb on mingw host

[Eli Zaretskii]

> Date: Mon, 26 Sep 2005 10:08:41 -0400
> From: Christopher Faylor <me@cgf.cx>
> 
> I think I get it.  This patch just modifies chew so that it always
> outputs '\n'.  Then you see '\n' on input no matter what.
> 
> Would it be possible to just link with binmode.o under mingw (and cygwin for
> that matter)?

If the problem is with MSYS's makeinfo, then it's IMHO wrong to solve
it in chew.  Besides, the suggested change, viz
 
    +#ifdef __MINGW32__
    +/* Prevent \r\n\ line endings */
    +#include <fcntl.h>
    +unsigned int _CRT_fmode = _O_BINARY;
    +#endif

is too general: it switches _all_ file I/O for _all_ files to binary
mode, in _all_ MinGW builds.  Thus, if the file chew reads is edited
with some Windows editor that doesn't preserve line-endings (Emacs
does), then chew itself might fail.

Even if currently this change doesn't cause any trouble, it could be a
time bomb: imagine that at a later date someone adds code to chew that
reads some other file--we don't want to remember then to open it
explicitly in text mode to prevent bugs.

So I'm against this fix.  If MSYS makeinfo is the culprit, let them
fix it, or let them use another port, which does TRT.

Re: [patch] Build arm-elf-gdb on mingw host

[Eli Zaretskii]

> Date: Mon, 26 Sep 2005 05:46:17 +0100
> From: Dave Murphy <wintermute2k4@ntlworld.com>
> CC: Eli Zaretskii <eliz@gnu.org>,  gdb-patches@sources.redhat.com
> 
> Sorry, I should have said that under mingw/msys files read in text mode 
> have line endings converted. There are numerous places in chew.c where 
> it checks for a newline character with expressions like "while (at (tos, 
> idx) == '\n')", see skip_white_and_stars(src,  idx), 
> strip_trailing_newlines(),  remove_noncomments (src, dst), 
> outputdots(),  courierize(),  bulletize(), copy_past_newline (ptr, idx, 
> dst), kill_bogus_lines(), indent(), skip_past_newline () and  nextword 
> (string, word). It seemed easier to just read the input files as binary 
> and suppress the conversion rather than make all the code deal with the 
> "/r/n" sequence.

Text-mode read conversion just removes \r from a \r\n  pair, thus
doing exactly what you want.

Others suggested that you actually mean the problem is with makeinfo,
not with chew.  The error messages you show us also seem to indicate
that this is the problem.  Can you please confirm that this indeed is
the case?