gdb and older cygwins

gdb and older cygwins

[Fabian Cenedese]

Hi

We need to stay with a 2.95.3 cross compiled gcc. This versions has some
errors regarding line endings, especially macro continuers (#define \) are
not recognized if the source file has Windows CRLF endings. I tried to
compile it anew with a recent cygwin version (1.5.10) but I can't get over
with this error. For some reason it seems to work when compiled with
a much older cygwin version. As I also need a cross compiled gdb they
both need to rely on the same cygwin.dll. When trying to run a gdb
compiled with a new cygwin together with an old cygwin.dll I got
missing entry point errors. So I need to compile it with the older
cygwin environment.

Now to the real question: What are the requirements to the cygwin
environment to build an actual gdb? Is there a minimum version
required or will configure take care of it?

Thanks

bye  Fabi

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

Re: gdb and older cygwins

[Michael Chastain]

Fabian Cenedese <Cenedese@indel.ch> 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

Re: gdb and older cygwins

[Fabian Cenedese]

At 08:53 26.08.2004 -0400, Michael Chastain wrote:
>Fabian Cenedese <Cenedese@indel.ch> 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.

Apart from this CRLF bug it seemed to have worked. My source files
could be compiled and after converting the line endings this error
disappeared as well.

>So you are on your own.  But I do have some hints about it.
>
>I can think of six strategies to try:
>
>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.

Wow, that's a lot to try out :) Thanks for the many possibilities.

I also have tried to compile some gdb versions with my old cygwin
environment:
gdb 5.0:        commented out strsignal in defs.h, then worked
gdb 5.2.1:      missing netinet/tcp.h but accepted an empty file
gdb 5.3:        missing netinet/tcp.h but accepted an empty file
gdb 6.0:        make stopped in readline with undeclared stuff
gdb 6.2:        make stopped already in libiberty with undeclared
                stuff (MAX_PATH, DWORD... sounds Windowsy)

So even if everything new would be best I'm not all out. gdb 5 should
provide everything we need for the remote connection. I will still try
some of your suggestions. Maybe I can at least use a newer
cygwin.

Thanks a lot.

bye  Fabi

RE: gdb and older cygwins

[Dave Korn]

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

RE: gdb and older cygwins

[Fabian Cenedese]

>> > 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?]

It depends. I use cygwin only to compile gcc/gdb+co. The intended platform
to use them is Windows with cygwin.dll, not the whole Cygwin system. So
the source files which gcc will need to cope with ARE Windows text files.

The source files for gcc and gdb of course I didn't unpack with Winzip,
and if it's only because it doesn't understand tar/gz/bzip2 :)

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

I might not even need to do that as other solutions are even simpler. But
I'll still keep it in mind.

>  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

Looks also good. But the mentioned option 3B (redefine open) already seems
to do the trick. But I need to test some more. Ld seems to do something
wrong... Better recompile everything :)

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

As I will use gcc and gdb from Windows (and not in Cygwin) I guess
this is no option for me.

Thanks

bye  Fabi

RE: gdb and older cygwins

[Dave Korn]

> -----Original Message-----
> From: gdb-owner On Behalf Of Fabian Cenedese
> Sent: 26 August 2004 15:58

> >> > 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?]
> 
> It depends. I use cygwin only to compile gcc/gdb+co. The 
> intended platform
> to use them is Windows with cygwin.dll, not the whole Cygwin 
> system. So
> the source files which gcc will need to cope with ARE Windows 
> text files.

  You have two misunderstandings here:

#1.  The cygwin dll is all you need to be using Cygwin; it's the dll that
provides the posix environment, it's the dll that handles
textmode-vs-binmode and line endian-ness issues.  Windows-plus-cygwin-dll
equals cygwin equals Unix style line-ends.

#2.  It doesn't matter what platform you want to compile on.  The gcc
sources come with Unix-style LF line ends.  They are NOT Windows text files
unless *you* have altered them.  If they now have CRs in them, it was *you*
who put them there, when you didn't need to do so, and if you hadn't done
so, it would have compiled fine under 2.95.3

> The source files for gcc and gdb of course I didn't unpack 
> with Winzip,
> and if it's only because it doesn't understand tar/gz/bzip2 :)

  It didn't understand bzip2 last time I checked, but it had no trouble
whatsoever with either tar, gz, or .tar.gz.  In fact some versions (v8
upward IIRC) even have an option to decide whether to mangle line-ends or
not specifically when unpacking a tar file.


> As I will use gcc and gdb from Windows (and not in Cygwin) I guess
> this is no option for me.

  As I point out above, if the cygwin dll is involved, you *are* in Cygwin;
what you are running is *not* a native windows app and will follow Cygwin's
preferences for line-end style.

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

RE: gdb and older cygwins

[Fabian Cenedese]

>> > [Did I guess correctly how you managed to get your gcc 
>> sources mangled?]
>> 
>> It depends. I use cygwin only to compile gcc/gdb+co. The 
>> intended platform
>> to use them is Windows with cygwin.dll, not the whole Cygwin 
>> system. So
>> the source files which gcc will need to cope with ARE Windows 
>> text files.
>
>  You have two misunderstandings here:
>
>#1.  The cygwin dll is all you need to be using Cygwin; it's the dll that
>provides the posix environment, it's the dll that handles
>textmode-vs-binmode and line endian-ness issues.  Windows-plus-cygwin-dll
>equals cygwin equals Unix style line-ends.

In this case I meant with cygwin system the bash, the shell. I will not use
them on the cygwin shell but on windows even if that doesn't make a
difference.
"cygwin equals Unix style line-ends", so why can you set the style upon
installing cygwin?

>#2.  It doesn't matter what platform you want to compile on.  The gcc
>sources come with Unix-style LF line ends.  They are NOT Windows text files
>unless *you* have altered them.  If they now have CRs in them, it was *you*
>who put them there, when you didn't need to do so, and if you hadn't done
>so, it would have compiled fine under 2.95.3

I think that's something you missunderstood since the first mail. I have no
problems with the gcc/gdb sources, they are unpacked as they should be,
they still have LF endings, I can compile all (except other problems). It's
the resulting gcc which needs to eat CRLF endings (and gives me problems).
But that should be solvable with one of the six possibilities Michael gave me.

>  It didn't understand bzip2 last time I checked, but it had no trouble
>whatsoever with either tar, gz, or .tar.gz.  In fact some versions (v8
>upward IIRC) even have an option to decide whether to mangle line-ends or
>not specifically when unpacking a tar file.

Too unreliable. I ran into problems too many times like that, be it cygwin
and windows or linux and windows. If I need the sources on a certain
system I also unpack it there with the accompanying tools.

>> As I will use gcc and gdb from Windows (and not in Cygwin) I guess
>> this is no option for me.
>
>  As I point out above, if the cygwin dll is involved, you *are* in Cygwin;
>what you are running is *not* a native windows app and will follow Cygwin's
>preferences for line-end style.

I meant the mounting. Windows already has its drives, there will be no
mounting. It just has to work as delivered. Even worse at the customers'.
We don't know what drives they will have and use, so we can't mount
anything for cygwin.

But I think we're getting OT here :)

Thanks

bye  Fabi