Subject: Re: [1.3.3] breaks serial i/o?
From: Christopher Faylor <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Sat, 20 Oct 2001 22:39:34 -0400

[I've Cc'ed [email-masked]]
On Sat, Oct 20, 2001 at 08:37:03PM -0500, William A. Gatliff wrote:
>Christopher:

(Chris, please.  I use Christopher in the email header just to avoid the
inevitable he/she references.)

>> Did you verify that 1.3.2 actually does work better?
>
>I don't know yet--- I botched the downgrade.
>
>What I did was take the cygwin-1.3.2-1.tar.bz2 file and untar it.
>Looks like it's a /usr directory, so, I moved my 1.3.3 /usr out of the
>way, and put the 1.3.2 one there.

Ouch.  /usr has *a lot* of stuff in it besides what is in the
cygwin-1.3.2-1.tar.bz2 tar ball.

>Now the gdb-5.0 build is complaining about a missing windows.h.  So
>apparently, some stuff goes into /usr/include that I didn't do.

Yes.  Some of the header files are in a separate package, specifically
w32api in this case.

>Taking the gdb-5.0 built under 1.3.3 and running it with the DLL you
>sent me didn't seem to affect the problem.  And I'm wary of running
>the gdb-5.0 built under 1.3.3 on the 1.3.2 DLL, since I'm not sure
>that doesn't present an apples-vs-oranges situation.

If there are downgrade problems they should be really obvious, like
a popup from Windows telling you that a symbol is missing.  It should
not hurt at all to run a 1.3.3-built gdb with a 1.3.2 dll if you
do not see this kind of problem.

>What's the *right* way to downgrade from a 1.3.3 to 1.3.2 setup?

You can do it via setup.exe.  Go through the dialog until you get to
the "Select Package To Install" screen.  Click on the Full/Part button.
This will display all of the packages.  At this point, you should be
able to click on the "Keep" button on the Cygwin line until it says
1.3.2-1.

This will revert your installation to 1.3.2.  You should do this
*without* moving /usr out of the way, though.

Alternately, you can just extract usr/bin/cygwin1.dll from
cygwin-1.3.2-1.tar.bz2 into a temporary directory and then use Windows
commands to copy the DLL from the directory into your /bin:

copy usr\bin\cygwin1.dll c:\cygwin\bin

(You need to use windows commands rather than cygwin commands because
you can't overwrite a DLL that is in-use)

>>I've been corresponding with Fernando Nasser, one of the gdb engineers
>>who works for me.  He reminded me that we worked on fixing a problem in
>>both gdb and cygwin a year ago.  The fix should be in cygwin 1.3.3 but
>>it is definitely not in gdb 5.0.
>>
>>Maybe you've already mentioned this, but I was wondering if you'd tried
>>the current gdb 5.1 WIP.  That may actually work better.  The other
>>alternative is that there may be ARM patches for gdb 5.0.
>
>I avoid the gdb snapshot, because I was hoping to stick with released
>stuff as much as possible.  I suppose that's what I should do next,
>though.  Maybe the problem isn't with Cygwin at all...

(dreamy smile) Wouldn't that be great...

>> You also mentioned that you could test on W2K.  It would be
>> interesting to see if your problems went away upon moving to W2K.
>
>The problem with moving off of Win98SE is that unless I run under
>VMWare, I have to do a clean OS install.  I can do that late next
>week, after I get back from a business trip.

Agh.  Ok.  I guess we should skip that step.  I don't know for sure
that this has ever been tested on Windows 98 but if you had it running
at one point then either it's a non-issue or you got lucky.  :-)

>Did the information in unixcomm.c provide any clues?  I couldn't step
>into the read() for some reason...

You'd need a debugging version of cygwin for that.  I can send one to
you and it might be interesting to see where the hang is occuring but I
assume that it is probably hanging in a Windows ReadFile function.

One thing that you could do is run gdb under strace:

strace -oc:\tmp\strace.out gdb qwer

Cygwin's strace is not much like linux's though.  This will be a *huge*
file with lots of strange debugging output.

If you can duplicate a hang by running strace, I'll take a look at the
output.  I wouldn't wish strace analysis on anybody who isn't familiar
with it.  Just bzip2 the output and send it to me.

(Note that this is not a general request for everyone in the cygwin
mailing list to send me strace output.  I'm just talking to Bill here.)

However, before we reach this drastic step, I'd *really* suggest at
least trying the 5.1 branch of gdb.  Your errors sound very similar
to others that were reported with ARM.  It is very possible that
they were fixed subsequent to 5.0.

I'm sorry that it has taken me so long to dredge up the memories about
this arm/gdb problem.  I'm glad that a gdb developer mentioned the
problems to me or I possibly never would have remembered about this.

You could also try the cygwin gdb snapshot sources.  Those were taken
in April and they are at least semi-stable:  gdb-20010428-3-src.tar.bz2.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/