This is the mail archive of the
gdb@sourceware.cygnus.com
mailing list for the GDB project.
Re: breakpoint insert API (was: A patch for ia32 hardware watchpoint.)
- To: Andrew Cagney <ac131313 at cygnus dot com>
- Subject: Re: breakpoint insert API (was: A patch for ia32 hardware watchpoint.)
- From: Richard Earnshaw <rearnsha at arm dot com>
- Date: Tue, 21 Mar 2000 14:09:42 +0000
- Cc: jtc at redback dot com, Todd Whitesel <toddpw at windriver dot com>, GDB <gdb at sourceware dot cygnus dot com>
- Cc: rearnsha at arm dot com
- Organization: ARM Ltd.
- Reply-To: rearnsha at arm dot com
> "J.T. Conklin" wrote:
>
> > Todd> So I would have to argue that the singlestep logic must either
> > Todd> happen at a really low level (this guarantees it will patch last
> > Todd> and un-patch first) or must go through the real breakpoint logic
> > Todd> which can do duplicate detection.
> >
> > The SOFTWARE_SINGLE_STEP() macro is called at a low enough level that
> > it inserts and remove trap instructions without effecting GDB's high-
> > level breakpoints. So I think we're OK. As a result, I wouldn't be
> > suprised if steping into a breakpoint didn't behave the same as on a
> > machine with hardware single-step.
>
> Its got long-term problems.
>
> The code assumes that it is going to retain control, blocked on the
> target, while the actual step is performed.
> This doesn't work well within a pure event model where control is ment
> to return to the event-loop when ever the target is resumed.
It doesn't work properly with INSTRUCTION_NULLIFIED either -- at least it
didn't last time I tried it...
R.