breakpoint insert API (was: A patch for ia32 hardware watchpoint.)

[jtc at redback dot com (J.T. Conklin)]

>>>>> "Todd" == Todd Whitesel <toddpw@windriver.com> 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