Sender: rich AT phekda DOT freeserve DOT co DOT uk Message-ID: <39509781.1822F117@phekda.freeserve.co.uk> Date: Wed, 21 Jun 2000 11:22:58 +0100 From: Richard Dawe X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.14 i586) X-Accept-Language: de,fr MIME-Version: 1.0 To: Eli Zaretskii CC: djgpp AT delorie DOT com, rich AT phekda DOT freeserve DOT co DOT uk Subject: Re: preprpcessor for overiding gcc optimation switch References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: djgpp AT delorie DOT com Hello. Eli Zaretskii wrote: > > On Tue, 20 Jun 2000, Richard Dawe wrote: > > > Eli Zaretskii wrote: > > > I fail to see how calling a VxD can disable a breakpoint. [snip] > > > > I didn't say that I understood why this was happening. > > I guess this makes two of us ;-) Indeed. =) > I find it hard to believe that Windows removes the breakpoint > instructions. What is probably happening is that somehow the > breakpoint exception (exception 3) is blocked or disabled, by whatever > reason that is triggered during libsock operation. Hardware > breakpoints use a different exception (exception 1), so they still > work. It sounds much more likely that exception 3 is disabled. I'm not sure if I could credit Windows with silently removing the debugging instructions. ;) At the moment there are too many degrees of freedom in the problem, that I can think of: Windows '95a vs. Windows '95 OSR2.1 gdb 4.18 vs. gdb 4.16 (IIRC) gcc 2.8.1 vs. gcc 2.95.2 binutils 2.8.1 vs. binutils 2.9.5.1 beta Plus, of course, the libsocket code. All these things may have some effect on the debugging. Perhaps gcc, binutils can be eliminated from this list, but I'm not sure. Next time I'm debugging libsocket, I'll try to narrow this vague problem down. Thanks, bye, Rich =] -- Richard Dawe [ mailto:richdawe AT bigfoot DOT com | http://www.bigfoot.com/~richdawe/ ]