From mboxrd@z Thu Jan 1 00:00:00 1970 From: jtc@redback.com (J.T. Conklin) To: gdb@sourceware.cygnus.com (GDB) Subject: breakpoint insert API (was: A patch for ia32 hardware watchpoint.) Date: Thu, 09 Mar 2000 11:28:00 -0000 Message-id: <5mitywc5ac.fsf@jtc.redbacknetworks.com> References: <200003080845.AAA18410@alabama.wrs.com> X-SW-Source: 2000-03/msg00192.html >>>>> "Todd" == Todd Whitesel writes: jtc> I was planning to propose that the breakpoint pointer itself be passed jtc> to the target_{insert,remove}_{break,watch}point() functions, so this jtc> is as good of time as any. Todd> I say Just Do It. I am sitting on some local code here that tracks Todd> breakpoints added to the target by a third party, and I ended up needing Todd> the breakpoint shadow field to be available to those functions. I spent some time yesterday investigating what would be necessary to change the target_{insert,remove}_breakpoint() API to pass a pointer to struct breakpoint. What I have so far is change the API from: int foo_insert_breakpoint (CORE_ADDR addr, char *shadow_contents); to: int foo_insert_breakpoint (struct breakpoint *bp, CORE_ADDR addr); I would have prefered to pass only the breakpoint pointer, but the overlay support code in breakpoint.c calls target_insert_breakpoint() twice with different addresses; once for the VMA and once for the LMA. I don't want to address that, at least not yet. For the most part, this change was just tedious grunt work. All those targets to change... However, while I was editing my way through GDBs files, I noticed ARM RDI target also has breakpoints with "handles" and maintains a local database mapping handles to breakpoint. I'm pleased to see this, because this change could be taken advantage by a target already in the tree. One issue that I'm not sure how to address is that there are several places breakpoints are inserted where a breakpoint has not been constructed. Most of these occur in tdep code which implements single step with breakpoints on processors without a trace mode. For example, from arc-tdep.c: /* Always set a breakpoint for the insn after the branch. */ next_pc = pc + ((type == NORMAL8 || type == BRANCH8) ? 8 : 4); target_insert_breakpoint (next_pc, break_mem[0]); My current thinking about how to handle these cases is to create a new breakpoint type bp_singlestep and to use set_momentary_breakpoint() to create "real" breakpoints. I'd appreciate if anyone can share their thoughts on this matter. --jtc -- J.T. Conklin RedBack Networks From mboxrd@z Thu Jan 1 00:00:00 1970 From: jtc@redback.com (J.T. Conklin) To: gdb@sourceware.cygnus.com (GDB) Subject: breakpoint insert API (was: A patch for ia32 hardware watchpoint.) Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-ID: <5mitywc5ac.fsf@jtc.redbacknetworks.com> References: <200003080845.AAA18410@alabama.wrs.com> X-SW-Source: 2000-q1/msg00657.html Message-ID: <20000401000000.SdzyjrKcywSqJqWYpoKuJWB_Dwg3XFOXKR8tkp3VJog@z> >>>>> "Todd" == Todd Whitesel writes: jtc> I was planning to propose that the breakpoint pointer itself be passed jtc> to the target_{insert,remove}_{break,watch}point() functions, so this jtc> is as good of time as any. Todd> I say Just Do It. I am sitting on some local code here that tracks Todd> breakpoints added to the target by a third party, and I ended up needing Todd> the breakpoint shadow field to be available to those functions. I spent some time yesterday investigating what would be necessary to change the target_{insert,remove}_breakpoint() API to pass a pointer to struct breakpoint. What I have so far is change the API from: int foo_insert_breakpoint (CORE_ADDR addr, char *shadow_contents); to: int foo_insert_breakpoint (struct breakpoint *bp, CORE_ADDR addr); I would have prefered to pass only the breakpoint pointer, but the overlay support code in breakpoint.c calls target_insert_breakpoint() twice with different addresses; once for the VMA and once for the LMA. I don't want to address that, at least not yet. For the most part, this change was just tedious grunt work. All those targets to change... However, while I was editing my way through GDBs files, I noticed ARM RDI target also has breakpoints with "handles" and maintains a local database mapping handles to breakpoint. I'm pleased to see this, because this change could be taken advantage by a target already in the tree. One issue that I'm not sure how to address is that there are several places breakpoints are inserted where a breakpoint has not been constructed. Most of these occur in tdep code which implements single step with breakpoints on processors without a trace mode. For example, from arc-tdep.c: /* Always set a breakpoint for the insn after the branch. */ next_pc = pc + ((type == NORMAL8 || type == BRANCH8) ? 8 : 4); target_insert_breakpoint (next_pc, break_mem[0]); My current thinking about how to handle these cases is to create a new breakpoint type bp_singlestep and to use set_momentary_breakpoint() to create "real" breakpoints. I'd appreciate if anyone can share their thoughts on this matter. --jtc -- J.T. Conklin RedBack Networks