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: Todd Whitesel <toddpw at windriver dot com>
- Subject: Re: breakpoint insert API (was: A patch for ia32 hardware watchpoint.)
- From: jtc at redback dot com (J.T. Conklin)
- Date: 14 Mar 2000 14:56:41 -0800
- Cc: gdb at sourceware dot cygnus dot com (GDB)
- References: <200003100133.RAA00070@alabama.wrs.com>
- Reply-To: jtc at redback dot com
>>>>> "Todd" == Todd Whitesel <toddpw@windriver.com> writes:
jtc> One issue that I'm not sure how to address is that there are several
jtc> places breakpoints are inserted where a breakpoint has not been
jtc> constructed. Most of these occur in tdep code which implements single
jtc> step with breakpoints on processors without a trace mode.
Todd> Aiee! Such code is evil and must be destroyed.
I don't think it's that bad.
Todd> One important value of the full breakpoint machinery is that it
Todd> can help avoid the same location being patched twice. Any time
Todd> we patch the same instruction twice, we must un-patch it in
Todd> exactly reverse order or else we leave a breakpoint instruction
Todd> sitting in the code -- Not Good.
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.
--jtc
--
J.T. Conklin
RedBack Networks