Sender: rich AT phekda DOT freeserve DOT co DOT uk Message-ID: <394FE14A.776B1AA2@phekda.freeserve.co.uk> Date: Tue, 20 Jun 2000 22:25:30 +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 Subject: Re: preprpcessor for overiding gcc optimation switch References: <83zop3o170 DOT fsf AT mercury DOT bitbucket> <25c58271 DOT fc969396 AT usw-ex0104-033 DOT remarq DOT com> <8ino7d$i9b$1 AT nets3 DOT rz DOT RWTH-Aachen DOT DE> <394F7467 DOT 6340126B AT phekda DOT freeserve DOT co DOT uk> <200006202008 DOT XAA23539 AT mailgw1 DOT netvision DOT net DOT il> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: djgpp AT delorie DOT com Hello. Eli Zaretskii wrote: > I fail to see how calling a VxD can disable a breakpoint. A > breakpoint is a special instruction written to the program's code; > unless Windows is smart enough to remove that special instruction and > replace it with the original one, it can do nothing to interfere. I didn't say that I understood why this was happening. I only observed that gdb would not break when I used normal breakpoints; I could make it break using hardware breakpoints. I have no idea if Windows is removing the instructions. I have not tried to investigate this problem further, since I was debugging libsocket at the time. As a side issue, gdb crashes VMware (running Windows '95 or NT). If you set a breakpoint, then gdb breaks and then you single-step (using s or n), then VMware will crash. I reported this to the VMware folks and sent them some code so they could reproduce this problem. They have not got back to me. They said at the time that VMware was not really debugger-friendly (i.e. debugging doesn't generally work under it), so I don't think this is limited to gdb. Bye, -- Richard Dawe [ mailto:richdawe AT bigfoot DOT com | http://www.bigfoot.com/~richdawe/ ]