sysdoc/pclsr.test

   1 Copyright (c) 1999 Massachusetts Institute of Technology
   2
   3 This program is free software; you can redistribute it and/or modify
   4 it under the terms of the GNU General Public License as published by
   5 the Free Software Foundation; either version 3 of the License, or (at
   6 your option) any later version.
   7
   8 This program is distributed in the hope that it will be useful, but
   9 WITHOUT ANY WARRANTY; without even the implied warranty of
  10 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
  11 General Public License for more details.
  12
  13 You should have received a copy of the GNU General Public License
  14 along with this program; if not, write to the Free Software
  15 Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
  16 ------------------------------
  17
  18 06/07/87 21:26:03,4751;000000000000
  19 Date: Sun,  7 Jun 87 21:13:07 EDT
  20 From: Alan Bawden <ALAN at AI.AI.MIT.EDU>
  21 To:   DLW at SCRC-STONY-BROOK.ARPA
  22 cc:   ALAN at AI.AI.MIT.EDU, MOON at AI.AI.MIT.EDU, TK at AI.AI.MIT.EDU
  23 Re:   PCLSR test mode
  24
  25     Date: Sat, 6 Jun 87 17:33 EDT
  26     From: Daniel L. Weinreb <DLW at Symbolics.COM>
  27     Hi.  Have you ever used ITS's PCLSR test mode?
  28
  29 Nope.  I've never written anything that warranted it.
  30
  31     I'm thinking about trying to implement something analogous, to help
  32     people debug "transactions", which can abort and restart and so are
  33     essentially subject to something much like PCLSRing.  How does the test
  34     mode work, and is it useful?  Thanks.
  35
  36 Its kind of a kludge actually.
  37
  38 I guess you remember that if you want a particular piece of code to be
  39 tested, you insert calls to this macro (PCLT) at points where you want to
  40 be PCLSRed from (typically right before you might go blocked).  Then PCLSR
  41 test mode lets you run the system call until it reaches one of the test
  42 points you have marked.
  43
  44 There are three modes that control what happens each time the job being
  45 tested reaches one of the test points:
  46
  47 1.  In "hold" mode, ITS PCLSR's the job and stops it as if the hacker had
  48 just typed a ^Z.  If the hacker \eP's the job, it will run to the exactly
  49 the same test point and then PCLSR and halt again.  Thus the hacker can
  50 test the same point over and over again.
  51
  52 2.  In "advance" mode, each time the hacker \eP's the job it runs to the
  53 same test point as last time, and then sets a flag that causes the job to
  54 PCLSR and halt at the -next- test point, where and whenever that happens to
  55 occur.  Thus the hacker can test all of the test points in succession in a
  56 particular path through a system call.
  57
  58 3.  "Advance but don't halt" mode is just like advance mode except that the
  59 job is not halted each time it is PCLSRed, it just keeps running and thus
  60 immediately starts the system call over.  This lets the hacker exercise a
  61 system call over and over, presumably waiting for a bug-check to trip.
  62
  63 The kludge is how ITS decides you have reached "the same test point".  You
  64 can't just test the PC where the PCLT macro occured, because that might be
  65 in a subroutine that was called from several places.  So ITS crawls down
  66 the stack looking for likely return addresses to try and figure out the
  67 call-chain that got to the current routine.  (Its heuristic is that any
  68 word whose right half address a word in system code that immediately
  69 follows any PUSHJ P, is a return address.)  These return addresses are all
  70 hashed together, and the pair consisting of this hash and the PCLT's PC are
  71 used to distinguish one test point from another.
  72
  73 (Actually you could hash the PCLT's PC in with the others, but keeping it
  74 separate means that you can -first- compare the current PCLT's PC with the
  75 one you are looking for, and if it doesn't match you don't have to bother
  76 with the slow hash computation.)
  77
  78 Additionally, it is possible that a PCLT might occur in the middle of a
  79 loop so that neither its location, nor the call-chain, can be used to
  80 distinguish what the hacker might want to treat as separate test points.
  81 To cover this case there is a location (PCLIDX) whose contants are always
  82 hashed in with the return addresses.  By storing the loop-counter, or
  83 something else that varies each time around the loop, in PCLIDX, the hacker
  84 can cause these test points to be distinguished.  (This mechanism doesn't
  85 extend to nested loops, but it's only used in a single place.)
  86
  87 Of course there are lots of ways you can imagine this hash test becoming
  88 confused (by extra gubbish on the stack that only -looks- like a return
  89 address and that happens to vary from call to call, or by routines that use
  90 other calling conventions, etc.), but I imagine that in practice the hacker
  91 doesn't get shafted all that often.
  92
  93 Here is another hazard that can bite the hacker using this feature:  In
  94 advance mode, after ITS has found the previous test point and has set the
  95 flag that causes the next test point to trap, but before it actually gets
  96 there, it may happen that the job is PCLSR'd for some ordinary reason (like
  97 the job being swapped out).  Then the next time the job does any system
  98 call the -first- test point in that system call will trap.  This is
  99 probably sufficiently unlikely that its not worth fixing; if it ever
 100 happened to anyone, he would just grumble and start over.
 101
 102 Is it usefull?  I don't really know.  It has never been used in my memory,
 103 but ITS hasn't changed all that much during that time.  I seem to recall
 104 Moon once remarking that he had never seen it used either, but I believe
 105 that TK once told me that it had flushed its share of bugs.