Date: Wed, 21 Jun 2000 10:01:04 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
cc: djgpp AT delorie DOT com
Subject: Re: preprpcessor for overiding gcc optimation switch
In-Reply-To: <394FE14A.776B1AA2@phekda.freeserve.co.uk>
Message-ID: <Pine.SUN.3.91.1000621100041.11317C@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


On Tue, 20 Jun 2000, Richard Dawe wrote:

> 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 guess this makes two of us ;-)

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