From mboxrd@z Thu Jan 1 00:00:00 1970 From: jtc@redback.com (J.T. Conklin) To: Todd Whitesel Cc: gdb@sourceware.cygnus.com (GDB) Subject: Re: breakpoint insert API (was: A patch for ia32 hardware watchpoint.) Date: Tue, 14 Mar 2000 14:56:00 -0000 Message-id: <5mzos15ffa.fsf@jtc.redbacknetworks.com> References: <200003100133.RAA00070@alabama.wrs.com> X-SW-Source: 2000-03/msg00235.html >>>>> "Todd" == Todd Whitesel 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: jtc@redback.com (J.T. Conklin) To: Todd Whitesel Cc: gdb@sourceware.cygnus.com (GDB) Subject: Re: breakpoint insert API (was: A patch for ia32 hardware watchpoint.) Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-ID: <5mzos15ffa.fsf@jtc.redbacknetworks.com> References: <200003100133.RAA00070@alabama.wrs.com> X-SW-Source: 2000-q1/msg00700.html Message-ID: <20000401000000.zzyU4T8DzQL3swHaM5ECuAoAFv05VnFOxgCctkrOc4Q@z> >>>>> "Todd" == Todd Whitesel 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