Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin AT sources DOT redhat DOT com Date: Sat, 20 Oct 2001 22:39:34 -0400 From: Christopher Faylor To: bgat AT billgatliff DOT com Cc: cygwin AT cygwin DOT com Subject: Re: [1.3.3] breaks serial i/o? Message-ID: <20011020223934.A28028@redhat.com> Mail-Followup-To: bgat AT billgatliff DOT com, cygwin AT cygwin DOT com References: <20011018161003 DOT A3059 AT saturn DOT billgatliff DOT com> <20011018222406 DOT C11830 AT redhat DOT com> <20011019085618 DOT A5013 AT saturn DOT billgatliff DOT com> <20011019114712 DOT A23101 AT visi DOT com> <028e01c1594f$47cf7030$0200a8c0 AT lifelesswks> <20011020150809 DOT A3610 AT saturn DOT billgatliff DOT com> <20011020190254 DOT A27597 AT redhat DOT com> <20011020203703 DOT A4217 AT saturn DOT billgatliff DOT com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011020203703.A4217@saturn.billgatliff.com> User-Agent: Mutt/1.3.21i [I've Cc'ed cygwin AT cygwin DOT com] 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/