🚀 go-pugleaf

| From: bothner@CS.WISC.EDU (Per Bothner)
| Newsgroups: gnu.gdb.bug
| Date: 18 Jun 90 05:27:02 GMT
| Distribution: gnu
| Organization: U of Wisconsin CS Dept
| 
| Single stepping over source lines by setting a breakpoint at the next
| line might work *if* there is no transfer of control
| in the current statement. Lacking stabs modifications,
| this can only be done by dis-assembling the code,
| and checking for jump/call instructions, not a trivial matter.

There are other ways to do this.  The Data General debugger SWAT for
the AOS/VS and AOS/VS-II operating systems 'solved' the single step
problem by putting a breakpoint at single statement (the compilers
would obligingly put a NOP at the beginning of each statement, and
there was a bit to say that the NOP's were there).  With the NOP at
the beginning of the statement, the debugger didn't have to worry
about restoring or simulating the instruction.

Another SWAT hack may not have general revelance, but here goes....
On the DG MV/Eclipse computers, the breakpoint instruction went to a
user-specified trap handler (rather than causing a signal to the
kernel like it does in most machines).  The normal codepath of a
breakpoint was to send an IPC to the debugger, but if you were
watching a variable for changes, the debugger would send the addresses
to watch to the breakpoint handler, and the instruction stream would
continue without sending the IPC.

I've often times wishes for UNIX debuggers to be able to send code to
the slave process, and do things like single step instructions
completely within the slave, without having to go back and forth
between the debugger and the slave process.  This is especially true,
if it takes a long period of time to get to the point where something
breaks without having to incur a 100-1 slowdown.....

It's also interesting to note that the UNIX debugger that DG produced
for the MV did not use the above features.  This was because of
politics and personalities -- the Unix debugger was done as the last
vestage of the original North Carolina languages group as opposed to
the Massachusetts languages group.  The North Carolina people were
'software engineer' types, and having the debugger insert code into
the slave project was not elegant enough.  As a consequence, I
debugged the UNIX C compiler on an AOS/VS system, where the debugger
was much faster.  However, this is getting off of the point.....