Breakpoints

[Bill.Chiles@CHILES.SLISP.CS.CMU.EDU]

To: William.Lott@ARDATH.SLISP.CS.CMU.EDU
cc: ram@CS.CMU.EDU
Fcc: port
Subject: Re: breakpoint internals interface 
In-reply-to: Your message of Fri, 15 Feb 91 21:00:53 -0500.
             <5926.666669653@ARDATH.SLISP.CS.CMU.EDU> 
--------

   I propose that we isolate the machine specific aspects of installing and
   handling breakpoints in one small C module.  The reasons are this: it's
   much easier to that kind of system hackery in C, and it's much easier to
   express machine specific dependencies in C.

Why is it easier to express machine specific dependencies in C?  I'm not
bucking you basic approach; I'm just curious.


I imagined something more basic in C than you described, leaving more work
in Lisp.  I see the following four Lisp functions:
   STORE-BREAK-INSTRUCTION component pc-offset breakpoint
   REMOVE-BREAK-INSTRUCTION component pc-offset breakpoint
   STORE-AFTER-BREAK-INSTRUCTION component pc-offset breakpoint
   REMOVE-AFTER-BREAK-INSTRUCTION component pc-offset breakpoint

STORE-BREAK-INSTRUCTION establishes a mapping from component cross
pc-offset to the breakpoint structure passed in and calls your
INSTALL_BREAKPOINT on the component and pc-offset.  It also sets the status
of the breakpoint to :active.  Your routine simply plugs a breakpoint
instruction in, doing whatever is necessary to remember what was there
previously.  Assuming all machines allow you to tag break instructions,
which we have already done in the system, the C routine tags this
instruction with some number that says "I'm a debugging tool breakpoint."
If I must supply this tag, then fine; you and Rob can determine whether it
is hard or stylistically poor to simply have the C code know this tag which
seems to be the stance you took in your design spec.

STORE-AFTER-BREAK-INSTRUCTION calls the C routine INSTALL_AFTER_BREAKPOINT
on the component and pc-offset.  Your routine looks at the code location
and figures out whatever is necessary to stop execution one instruction
after the indicated code location, and it returns to me one or two
pc-offsets.  STORE-AFTER-BREAK-INSTRUCTION then creates one or two
after-breakpoints and establishes a mapping for each from component cross
pc-offset to the appropriate after-breakpoint.

REMOVE-BREAK-INSTRUCTION calls UNINSTALL_BREAKPOINT and removes the mapping
established by STORE-BREAK-INSTRUCTION.  This sets the state of breakpoint
to :inactive.

REMOVE-AFTER-BREAK-INSTRUCTION calls UNINSTALL_AFTER_BREAKPOINT and removes
any mapping established by STORE-AFTER-BREAK-INSTRUCTION.

When execution encounters a break instruction, the C code determines via
the tag that it is a debugging-tool-breakpoint and calls a Lisp function,
HANDLE-DEBUGGING-TOOL-BREAKPOINT.  This function determines the appropriate
component and pc-offset, which would most easily be done by looking at
arguments passed in from C if that is possible, and maps their combination
to a basic-breakpoint using the mapping mechanism filled in by
STORE-BREAK-INSTRUCTION and STORE-AFTER-BREAK-INSTRUCTION.  Then it does
two different things depending on the type of the result of the mapping:
   breakpoint
      Unless the breakpoint is :active, it signals an error.  It sets the
      status to :running, invokes UNINSTALL_BREAKPOINT on the component and
      pc-offset, and invokes STORE-AFTER-BREAK-INSTRUCTION on the component and
      pc-offset.  This probaby all occurs within some context where interrupts
      are inhibits, possibly inherently from the interrupt handling mechanism
      itself.
   after-breakpoint
      Unless the AFTER-BREAKPOINT-BREAKPOINT's status is :running, it signals
      an error.  It sets the status to :active, and it invokes
      STORE-BREAK-INSTRUCTION on the AFTER-BREAKPOINT-BREAKPOINT, its
      component, and its pc-offset.  Then it invokes
      REMOVE-AFTER-BREAK-INSTRUCTION on this after-breakpoint, the component
      from the arguments HANDLE-DEBUGGING-TOOL-BREAKPOINT, and the pc-offset.
      It also does this for after-breakpoint's partner if it exists which is
      discernible from the after-breakpoint.

*****
Okay, that's all I can do now in the state I'm in.  I've left out actually
invoking the breakpoint's hook-function and some other "obvious" stuff.  I
wanted to get this out in hope that William would see it before tomorrow
evening.  In a perfect world, besides accidents never happening, William
and Rob would show up at 1:00 p.m. before the meeting to discuss this and
flesh it out before the meeting.

WAhoooooo!  Fucking A, Dudes!!!!  Poor me anothe Jack sister, and grab that
chair.

Bill