\\
.TITLE ^THEORY OF ^DEBUG ^AIDS
.SPACING 1
.FLAGS CAPITALIZE
.PAPER SIZE 60,80
.LEFT MARGIN 8
.RIGHT MARGIN 72
.C
^THEORY OF (^INTERACTIVE) ^DEBUGGERS
.SKIP 4
.C
<ABSTRACT
.P
^WE DEAL HERE WITH 3 CLASSES OF ISSUES IN DEBUGGERS:
CAPABILITIES THE DEBUGGERS OFFER TO USERS (WITH RANDOM
ILLUSTRATIONS OF THEIR USES), SUPPORT FACILITIES NEEDED
TO IMPLEMENT DEBUGGERS (HARDWARE SUPPORT AND WHAT
IT CAN DO FOR YOU, AND SOFTWARE SUPPORT IN TERMS OF WHAT
LANGUAGE PROCESSORS MAY PROVIDE, INCLUDING STRATEGIES
FOR SOURCE CODE REPLICATION), AND EFFECTS OF A DEBUG AID
ON THE CONTEXT OF THE PROCESS BEING DEBUGGED (ALSO THE
MULTI-TASK CONTEXT, TREATING A MULTITASKED APPLICATION AS
A CONTEXT TO BE DEBUGGED). ^THIS TALK IS A SURVEY OF SELECTED
DEBUGGERS AND IS NOT INTENDED TO BE EXHAUSTIVE OR TO TEACH
ANYONE TO USE A PARTICULAR DEBUG AID.
.P
^INTERACTIVE DEBUGGERS WORK BY ALLOWING PARTIAL EXECUTION OF
PROGRAMS AND SELECTIVE EXAMINATION OF A PROGRAM, REPLACING
THE DUMPS OF YESTERYEAR. ^THEY DO NOT SUBSTITUTE FOR COMPILER
ERROR CHECKERS, STRONGLY TYPED LANGUAGES, ETC., BUT ARE A
NECESSARY PART OF THE REAL WORLD OF GETTING CODE TO WORK
AS DESIGNED.
.SKIP 4
.TEST PAGE 20
.C
<DEBUG <FACILITIES
.P
^THERE ARE SEVERAL FACILITIES A DEBUG AID NEEDS TO BE USEFUL TO
THE PROGRAMMER. ^IN A ROUGH PRIORITY ORDER OF IMPORTANCE, THEY
INCLUDE THE FOLLOWING:
.LEFT MARGIN 14
.LE ^INSTRUCTION ^BREAKPOINTS (STOPS ON A GIVEN INSTRUCTION)
^IT IS PREFERABLE TO ALLOW MORE THAN ONE OF THESE.
.LE ^DATA ^MEMORY ^DISPLAY (THE MORE DATA TYPES KNOWN TO THE
DEBUGGER, THE BETTER; A GOOD DEBUGGER SHOULD KNOW ABOUT ALL TYPES
IN THE LANGUAGE BEING DEBUGGED)
^THE FIRST 2 LIST ITEMS PROVIDE THE MOST BASIC DEBUG FEATURES NEEDED,
ALLOWING PARTIAL EXECUTION OF PROGRAMS TO EXAMINE INTERMEDIATE RESULTS
FOR ERRORS.
.LE ^INSTRUCTION MEMORY DISPLAY (PREFERABLY IN THE LANGUAGE
BEING DEBUGGED)
.LE ^DATA ^MEMORY ^MODIFICATION (AGAIN MANY DATA TYPES SHOULD BE
USABLE)
.LE ^INSTRUCTION ^MEMORY ^MODIFICATION (PREFERABLY AT LEAST IN ASSEMBLER)
.LE ^MACHINE ^STATE ^DISPLAY (REGISTERS, <PSW\S, ETC.)
.LE ^MEMORY ^BREAKPOINTS (WITH SUBTYPES ALLOWING BREAKS ON ONLY WRITES,
ANY ACCESSES, MODIFICATION ACCESSES, INSTRUCTION MEMORY, OR DATA MEMORY)
^THIS IS HANDY WHERE YOUR PROGRAM IS CLOBBERING SOME MEMORY LOCATION
BEFORE IT DIES AND YOU NEED TO FIND OUT WHAT IS CLOBBERING MEMORY,
AND NOT THAT ZEROED MEMORY IS NOT YOUR PROGRAM. ^WITHOUT SOMETHING
LIKE THIS, LOCATING SUCH A BUG IS A MATTER OF TRIAL AND <MUCH ERROR.
.LE ^SINGLE ^STEPPING (WHICH IS HANDY WHERE LOGIC IS COMPLEX AND
INSERTING/REMOVING BREAKPOINTS WASTES TIME).
.LE ^TRACEBACKS AND ^HISTORY DISPLAYS
.LEFT MARGIN 8
.SKIP 1
^IT IS ALSO DESIRABLE TO SUPPORT ANY UNUSUAL FEATURES OF THE SYSTEM
SUCH AS OVERLAYS, WHEN THESE MIGHT AFFECT THE STATUS OF VISIBLE
MEMORY. ^THESE ARE THE BASIC FEATURES A GOOD DEBUG AID WILL OFFER.
^TO BE MOST USEFUL, THEY SHOULD WORK IN WHATEVER LANGUAGE THE
PROGRAM BEING DEBUGGED IS WRITTEN IN. ^THE FURTHER THE DEBUGGER IS
FROM THIS, THE HARDER IT IS TO USE. ^THUS, A PURELY NUMERIC
(E.G., OCTAL) DEBUGGER IS INFERIOR TO ONE THAT ALLOWS CODE TO BE
DISPLAYED OR ENTERED IN ASSEMBLER, AND THAT IS INFERIOR TO ONE
ALLOWING DISPLAY OR ENTRY IN, SAY, <PASCAL (WHERE <PASCAL IS THE
LANGUAGE IN USE; IT IS WORSE TO HAVE A PASCAL DEBUGGER WHEN YOUR
PROGRAM IS WRITTEN IN, SAY, <PL/I, THAN ONE SHOWING YOU ASSEMBLER
AND AT LEAST NOT MISINTERPRETING YOUR DATA STRUCTURES). ^ANOTHER
DESIRABLE FEATURE IS TO ALLOW USER SYMBOLS TO BE KNOWN TO THE
DEBUGGER, TO PERMIT HIM TO AVOID MAGIC NUMBERS AS HIS REFERENCES.
.P
^SYMBOLIC DEBUGGERS FOR <HOL\S GENERALLY DO NOT DISPLAY <HOL CODE
FROM MEMORY, SINCE THE TRANSLATOR WOULD BE EXPENSIVE EVEN IF
FEASIBLE. ^WHAT THEY NORMALLY OFFER IS THE ABILITY TO WORK WITH
NAMED SYMBOLS AND SOME COMPILER CONSTRUCTS (SUCH AS LINE NUMBERS)
TO CONTROL EXECUTION. ^CONSIDER <FDT AND <FODT FROM THE <RSX
<SIG TAPES; THEY ALLOW SYMBOLS TO BE ACCESSED AND EXECUTION OF
PROGRAMS TO PROCEED A LINE AT A TIME OR TO STOP ON A GIVEN LINE
NUMBER. ^THEY NEVER ATTEMPT TO SHOW <FORTRAN CODE, BUT ASSUME A
LISTING IS AVAILABLE. <ADT UNDER <UNIX KNOWS HOW TO DISPLAY
SYMBOLS USED IN <C, AND ALSO UNDERSTANDS THE <C STACK FRAMES SO
IT CAN SHOW CALLING TRACEBACK SEQUENCES AND ARGUMENTS. ^DISPLAY IS
IN ASSEMBLER FOR INSTRUCTIONS HOWEVER. ^VERY LITTLE IS REALLY NEEDED
TO SUPPORT A LANGUAGE WHERE COMPILERS AND LINKERS PRESERVE
SYMBOLS AND SOME UNIFORM CODE IDENTIFIERS (LINE NUMBERS, FOR INSTANCE).
^SOME DEBUGGERS HAVE DIFFERING COMMAND FEATURES DEPENDING ON
LANGUAGE TOO, BUT THE POINT IS THAT A SET OF MINIMAL FEATURES
CAN SUPPORT <HOL DEBUGGING AS WELL AS ASSEMBLER DEBUG, SO LONG
AS THIS IS UNDERSTOOD TO MEAN SYMBOL ACCESS, NOT INTERACTIVE
COMPILING / DECOMPILING. ^A GENERAL DEBUGGER MIGHT HAVE ANY OF THE
FEATURES MENTIONED ABOVE, THOUGH.
^THESE FEATURES EACH HAVE COSTS; ^I WILL NOW DISCUSS HOW SOME ARE
IMPLEMENTED ON VARIOUS MACHINES, WITH SPECIAL ATTENTION TO <PDP11.
.SKIP 3
.C
<SUPPORT <NEEDED
.P
^EVEN PROVIDING SIMPLE INSTRUCTION BREAKPOINTS CAN BE A TOUGH JOB
ON A MACHINE WITHOUT A BREAKPOINT TRAP. ^MACHINES LIKE THE
<PDP9 AND <PDP10 ENTER BREAKPOINTS BY OVERWRITING INSTRUCTIONS
WITH SUBROUTINE CALLS. ^THIS TRAPS THE EXECUTION OF THAT INSTRUCTION
ALL RIGHT, BUT WHEN ONE TRIES TO PROCEED FROM THE BREAK, THE
DEBUGGER MUST EMULATE THE INSTRUCTION IN SOFTWARE. ^ON THE <PDP11
THE DEBUGGER NEEDS ONLY TO REPLACE THE INSTRUCTION AND EXECUTE IT
<IN <PLACE WITH THE <T BIT SET TO TRAP AFTER IT FINISHES, THEN
REPLACE ITS TRAP AND GO ON. ^THE VERSIONS OF <DDT ON THE <PDP9 AND
<PDP10 THEREFORE CANNOT BREAKPOINT JUMPS AND SUBROUTINE CALLS
BECAUSE THEY CANNOT EMULATE THEM; ON THE 11, THE ONLY INSTRUCTIONS
THAT CAUSE TROUBLE ARE THE <RTI AND <RTT INSTRUCTIONS, WHICH ARE
(FORTUNATELY) RARE IN USER CODE. ^MACHINES WITH A HARDWARE BREAKPOINT
REGISTER MAY ACT EITHER WAY, DEPENDING ON DETAILS OF HOW IT WORKS.
^IN THE WORST CASE, IT MAY NOT BE POSSIBLE TO HAVE MORE THAN ONE
BREAKPOINT - A REAL DISADVANTAGE.
.P
^DISPLAY OF DATA AND INSTRUCTION MEMORY BY ADDRESS IS USUALLY NOT
DIFFICULT, AND DISPLAY OF MULTIPLE FORMATS REQUIRES ONLY THAT
MEMORY FOR SUITABLE CONVERSION ROUTINES BE AVAILABLE. ^ANYONE
WHO HAS TRIED DEBUGGING PROGRAMS THAT CONTAIN FLOATING POINT
NUMBERS WITH <ODT (^OCTAL ^DEBUGGING ^TOOL) WILL SEE THE VALUE
OF A DEBUGGER THAT CAN DISPLAY DATA IN MULTIPLE FORMATS. ^IF
A LANGUAGE SUPPORTS SOME STRANGE PACKED FORMATS, IT IS DESIRABLE
THAT ITS DEBUGGER BE ABLE TO MAKE THEM HUMAN READABLE. ^THERE ARE
PLACES WHERE THIS CAN BE A PROBLEM THOUGH. ^CONSIDER THE NEW
<MIL-<STD 1862 ARCHITECTURE. ^IT HAS PROTECTION MODES WHICH MAKE
CERTAIN PARTS OF THE PROCESS'S STATUS (E.G. CONTEXT STACK)
UNAVAILABLE TO THE REST OF THE PROCESS. ^A DEBUGGER THAT MUST
DISPLAY THIS INFORMATION MUST HOPE AN OPERATING SYSTEM CALL
IS AVAILABLE TO ALLOW IT TO OBTAIN THE INFORMATION. ^THIS SORT
OF PROBLEM CAN ARISE WHENEVER PROCESS-RELEVANT INFORMATION IS
FORCED TO BE HIDDEN; THE NORMAL PROCESS CODE WILL NOT NORMALLY
HAVE ANY BUSINESS OBTAINING THIS INFORMATION, BUT A DEBUGGER
OFTEN MUST BE ABLE TO. (^THIS IS A CAUTION TO MACHINE DESIGNERS
NOT TO TRY TOO HARD TO PROTECT USERS AGAINST THEMSELVES; IT CAN
RESULT IN PROTECTING THE MACHINE AGAINST BEING USED.)
.P
^MODIFICATION OF MEMORY IS NOT MUCH OF A PROBLEM UNLESS THERE
ARE ACCESS PROTECTIONS TO MEMORY, BUT MODIFICATION IN A <HOL
MAY INTERACT WITH DISPLAY IN THAT <HOL SINCE PARTS OF A COMPILER
AND CODE GENERATOR WOULD BE NEEDED TO INSERT CODE IN ANYTHING
HIGHER THAN ASSEMBLER, AND OPTIMIZATION DATA IS NOT AVAILABLE.
^I HAVE NEVER SEEN A DEBUGGER THAT GOES MUGH HIGHER THAN
ASSEMBLER IN INSERTING CODE.
^I ALSO DO NOT BELIEVE SUCH ENTRY WILL OFTEN BE WORTH WHILE
IN ANY HIGHER LEVEL THAN ASSEMBLER. ^WHERE PROVISION IS MADE
FOR DISPLAY OF SOURCE CODE, IT MAY BE NECESSARY TO FLAG AREAS
MODIFIED BY THE USER TO SHOW WHERE NEW CODE HAS BEEN INSERTED IF
CODE IS ALLOWED TO CHANGE. (^CHANGING CODE CAN REDUCE DEBUG TIME
CONSIDERABLY TO ONE WHO IS KNOWLEDGEABLE, THOUGH, BY MAKING
IT POSSIBLE TO DEFER A RE-ASSEMBLY/RELINK SEQUENCE.
^ENTERING DATA TO CORRECT THE FLOW
OF A PROGRAM THAT DEPENDS ON IT IS EASIER, AND THIS IS FAR
MORE COMMON. ^THE SAME CONSIDERATIONS AS MENTIONED IN DISPLAY
APPLY.
^DISPLAY OF MACHINE STATE IS GENERALLY NO HARDER (OR EASIER) THAN
MEMORY DISPLAY AND AGAIN, HARDWARE PROTECTION CAN MAKE LIFE
DIFFICULT.
.P
^MEMORY BREAKPOINTS OF MOST TYPES ARE VERY NEARLY IMPOSSIBLE WITHOUT
SOME HARDWARE ASSIST, AND EVEN WITH SOME FORMS OF ASSISTING HARDWARE
(WHICH MAY INTERRUPT WHEN THE MEMORY BUS SEES A PARTICULAR ADDRESS),
CACHE CAN MAKE READ BREAKPOINTS OCCUR IMPERFECTLY. ^WRITE BREAKPOINTS
ARE EASIER (SINCE MOST CACHE SYSTEMS USE WRITE-THROUGH) AND ARE
MORE INTERESTING. ^A TRUE WRITE BREAKPOINT WILL DETECT WRITING
THE SAME VALUE AS WAS IN A LOCATION. ^THIS REALLY CAN <ONLY BE HANDLED
WITH HARDWARE. ^ANOTHER TYPE OF PSEUDO-BREAKPOINT IS THE "WATCHPOINT"
AS IMPLEMENTED IN <DDT-11. ^THIS IS REALLY AN AUTOMATED SINGLE STEP
PROGRAM WHICH WILL STOP EXECUTION IF THE VALUE AT AN ADDRESS
CHANGES. ^BECAUSE EVERY INSRUCTION MUST BE STEPPED, THE DEBUGGER
MUST BE SURE NOT TO LOSE CONTROL (AN <RTI WILL DO IT IN).
^THE MAIN EFFECT IS TO <GREATLY SLOW DOWN THE PROGRAM. ^ON MACHINES
LIKE THE <PDP11 THERE IS LITTLE CHOICE, THOUGH. ^NOTICE THAT ON
MACHINES LIKE <PDP9 THIS WOULD HAVE BEEN MUCH HARDER BECAUSE BREAKS
CANNOT BE PLACED ON CALLS THERE.
.P
^SINGLE STEPPING IS A SHORTHAND FOR INSERTING BREAKPOINTS AND
PROCEEDING FROM OLD ONES. ^WHERE THERE IS A TRACE BIT (A LA <PDP11)
IT'S EASY. ^WITHOUT ONE, IT MAY REQUIRE INTERPRETIVE EXECUTION OF AN
ASSEMBLY LANGUAGE PROGRAM. ^SOME REFINEMENTS ON SINGLE STEPS
WHICH DO SIMPLE DECISIONS ABOUT WHETHER TO ACTUALLY ALLOW USER
INTERACTION WITH THE DEBUGGER ARE FAIRLY COMMON TOO. ^THESE MAY
INCLUDE REPEAT COUNTS OR TESTS OF SPECIAL CONDITIONS (E.G.,
BREAK IF ADDRESS FOOBAR IS NEGATIVE, NOT OTHERWISE), OR WHATEVER
SEEMS REASONABLE. ^A PARTICULARLY FLEXIBLE WAY TO HANDLE
THESE CONDITIONS IS TO ALLOW A SET OF STORED COMMANDS TO BE RUN AT
A BREAK TO DO THE DECISION. ^HOWEVER, VERY GENERAL FACILITIES OF
THIS KIND ARE HARD TO FIND THAT HELP MORE THAN A FEW REAL LIFE
PROBLEMS.
^TRACEBACKS OR CODE PROFILES ARE USUALLY EASY TO PRODUCE PROVIDED
THERE IS SPACE FOR THEM; EVERY BREAKPOINT FACILITY ^I KNOW OF
GIVES ACCESS TO THE PROGRAM LOCATION AT A BREAK, AND THAT IS
ENOUGH TO CONSTRUCT HISTOGRAMS OF HOW OFTEN EACH WAS REACHED.
.SKIP 2
.C
<SYMBOLIC <DISPLAYS
.P
^TO ALLOW DISPLAY OF INSTRUCTIONS OR VARIABLES SYMBOLICALLY, THERE
HAVE BEEN SEVERAL METHODS PROPOSED. ^THE MOST COMMON WAY TO ACCESS
USER SYMBOLS IS TO HAVE LANGUAGE PROCESSORS SAVE THEM IN FILES
THE DEBUGGER CAN ACCESS, EITHER BY HAVING THEM PRODUCE DATA STRUCTURES
IN THE DEBUGGER OR BY HAVING THEM READ OFF DISK. ^ON THE <PDP11 THIS
HAS NOT BEEN WELL SUPPORTED. ^THE TASKBUILDER OUTPUTS GLOBAL SYMBOLS,
BUT LOCAL ONES ARE NOT OUTPUT BY THE MORE COMMON <DEC LANGUAGES.
^SOME <DECUS WORKAROUNDS HAVE BEEN WRITTEN (MOST NOTABLY <FDT WHICH
PRODUCES SYMBOL FILES FROM LISTINGS AND MAPS), BUT THE PROBLEM REMAINS THAT
EVEN WHERE THE LANGUAGES SAVE INTERNAL SYMBOLS, <TKB DOES NOT. ^SINCE
MOST 11 USERS CANNOT RUN <LINKN11 ON A <PDP10, THIS DEFEATS ALL
BUT THE WORKAROUNDS THAT USE MAP FILES. ^ON OTHER MACHINES, SYMBOLS
ARE VERY OFTEN AVAILABLE. ^PROGRAM CODE IS GENERALLY DISPLAYED EITHER
IN A NUMERIC RADIX OR AS ASSEMBLY CODE VIA A DISASSEMBLER, WHICH
IS USUALLY NOT TOO HARD TO WRITE. ^WHERE A HIGHER ORDER LANGUAGE IS
REQUIRED, MUCH COOPERATION IS NEEDED WITH THAT LANGUAGE'S COMPILER.
^ONE METHOD OF CODE RECONSTRUCTION HAS COMPILERS PLACING TOKENS
IN THE OUTPUT TO TELL WHAT KIND OF STATEMENT IS IN USE. ^COMPILED
CODE THEN HAS CONSTRUCTS (POSSIBLY SWITCHABLE) WHICH LET A
DEBUGGER KNOW IT IS, SAY, IN THE MIDDLE OF A <DOWHILE CONSTRUCT.
^ANOTHER PROPOSAL SUGGESTED THE COMPILER SAVE THE ACTUAL SOURCE FILE
IN INDEXED FORM AND GENERATE POINTERS TO THAT FORM, SO A DEBUGGER
COULD EXTRACT THE COMPLETE SOURCE TEXT, WITH COMMENTS. ^OBVIOUSLY,
CHANGING THE PROGRAM WOULD INVALIDATE THIS DISPLAY.
.SKIP 4
.C
<CONTEXT
.P
^MOST OF US HAVE PROBABLY HAD THE EXPERIENCE OF LOADING A
DEBUGGER INTO A TASK AND HAVE IT NOT FIT, OR HAVING THE PROBLEM
THAT MADE US LOAD THE DEBUG AID GO AWAY MYSTERIOUSLY. ^THESE ARE
CONTEXT EFFECTS.
^THE CONTEXT OF A PROCESS AS USED HERE MEANS THE MACHINE
RESOURCES RELEVANT TO ITS COMPUTATION, WHICH MAY INCLUDE
MEMORY, PROCESSORS, TRAP VECTORS, AND SO FORTH.
^THE CONTEXT OF A DEBUGGER DEPENDS ON MACHINE AND OPERATING SYSTEM.
^IN <RSX-11, DEBUGGERS ARE NORMALLY PART OF THE SPACE OF A TASK
AND SHARE THE TRAPS OF THAT TASK, AND IN SINGLE USER SYSTEMS LIKE
<DOS-11 AND <RT11 THIS IS NECESSARILY THE CASE WHEN NO MAPPING IS
AVAILABLE. ^HOWEVER, <UNIX HAS DEBUGGERS NORMALLY OUTSIDE A PROCESS'
SPACE AND TRAPS ARE SEEN BY THE <OS FIRST, THEN PASSED TO A
DEBUGGER (LARGER CONTEXT OBJECTS THAN SINGLE TASKS ARE KNOWN).
<VAX CAN ALSO HANDLE LARGER OBJECTS THAN TASKS. ^AS DISTRIBUTED
APPLICATIONS EVOLVE, A CONTEXT MAY ENCOMPASS MORE THAN ONE
TASK AND MORE THAN ONE <CPU. ^DEBUGGING SUCH APPLICATIONS CAN
BE QUITE COMPLICATED BECAUSE THE IDEA OF A DEBUG AID IS TO ALLOW
EXAMINATION OF ANY PART OF THE APPLICATION, WHICH IS NOT FEASIBLE
IN SOME CASES.
.P
^WHERE A DEBUG AID IS PART OF THE SPACE OF A NORMAL TASK, LINKING
IT INTO THE TASK WILL OFTEN CHANGE ADDRESSES OF TASKS EVEN IF IT
FITS. ^THIS CAN CREATE OR MASK PROBLEMS. ^WHERE THE DEBUG AID CAN
BE IN A SEPARATE AREA OF MEMORY, THESE EFFECTS CAN BE MINIMIZED.
^THIS CAN USUALLY BE DONE GIVEN SOME SORT OF REASONABLE MULTIPROGRAMMING
ENVIRONMENT WITH SOME INTERTASK COMMUNICATION, BECAUSE THE AMOUNT
OF INFORMATION THAT MUST BE SENT TO A DEBUG AID AT A BREAKPOINT
IS FAIRLY SMALL. <DDT CAN GET BY EASILY WITH THE 13-WORD <RSX
PACKETS AND USE A SMALL "KERNEL" OF DEBUG FEATURES BUILT INTO
THE TASK, WITH THE BULK OF THE DEBUGGER IN A SEPARATE TASK. ^GIVEN
A TRANSPORT MECHANISM FOR THE PACKETS, TARGET AND DEBUGGING
TASKS COULD EVEN BE IN DIFFERENT MACHINES. ^THE WAY THIS WORKS IS
THAT TASK-LOCAL CONTEXTS ARE SAVED LOCALLY, SO ONLY THE
<PC AND <PS AND SOME POINTERS NEED BE PASSED. ^DATA CAN BE MOVED
EACH WAY BE SENDING PACKETS CONTAINING "<MOV" INSTRUCTIONS
WHICH MINIMIZES THE SIZE OF THE "KERNEL". ^BY SUITABLE EXEC
MODIFICATIONS, EVEN THIS KERNEL CAN BE ELIMINATED, AT LEAST
ON ANY SINGLE MACHINE, SINCE <RSX SAVES ALL THE INFORMATION
NEEDED ALSO. ^WHERE THE DEBUGGER IS ALREADY SEPARATE IN CONTEXT
(CONSIDER THE OLD <PDP1^X <ID DEBUGGER), INTERFERENCE WITH
ADDRESSES DOES NOT OCCUR. ^THIS IS LESS DISTURBING, BUT DOES
USUALLY HAVE SOME TIMING DISADVANTAGES WHERE SINGLE STEPPING
SHOULD BE KEPT QUICK; MORE SYSTEM CONTEXT SWAPPING IS NEEDED.
.P
^IN THE CASE OF MULTITASK APPLICATIONS, A USEFUL KIND OF
DEBUG AID WOULD ALLOW SEVERAL COMMUNICATING TASKS TO
BE DEBUGGED. ^I HAVE HEARD OF 2 WAYS TO APPROACH THIS.
^THE APPROACH TAKEN BY <DDT AND BY <SPEX <ODT IS TO SERIALLY
DEBUG ONE TASK AT A TIME IN ORDERS DETERMINED BY BREAKPOINTS
IN SEVERAL AT A TIME. ^THIS MEANS THAT A BREAKPOINT IN ONE
TASK HALTS THAT TASK AND ALLOWS EXAMINATION OF ITS ACTIONS,
BUT ALLOWS OTHERS TO KEEP RUNNING. ^THIS IS NOT A FAITHFUL
STOPPING OF TIME FOR THE SYSTEM, BUT MAY BE BETTER THAN
SUCH FOR FINDING ERRORS DUE TO LACK OF PROPER FLOW
CONTROL IN A SYSTEM'S INTERTASK DATA. ^THE OTHER APPROACH
WAS TAKEN BY A SPECIALLY MODIFIED <XDT CALLED <MDT WHICH
STOPS ALL OTHER PROCESSES (EXCEPT SOME ^I/^O) WHENEVER
ANY BREAKPOINT IS SEEN. ^THIS REALLY DOES PREVENT ERRORS
DUE TO IMPROPER TIMING RELATIONSHIPS, BUT CAN HAVE SOME
PROBLEMS WHERE SOME PARTS OF AN APPLICATION MUST RUN
CONTINUOUSLY (E.G., WATCHDOG SERVER PROCESSES, TO KEEP
ANOTHER PROCESSOR FROM CUTTING OUT). ^THE FIRST SCENARIO
IS FAR EASIER TO ARRANGE IN DISTRIBUTED SYSTEMS, BUT AT
TIMES THE SECOND MAY BE NEEDED.