Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!rutgers!uwvax!rang
From: rang@cs.wisc.edu (Anton Rang)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Problem with LSC 4.0 debugger.
Message-ID: 
Date: 26 Sep 89 05:14:00 GMT
References: <244@dbase.UUCP> <3424@cbnewsc.ATT.COM>
	<1563@atanasoff.cs.iastate.edu>
Distribution: na
Organization: UW-Madison CS department
Lines: 46
In-reply-to: jwright@atanasoff.cs.iastate.edu's message of 25 Sep 89 23:42:43 GMT

In article <1563@atanasoff.cs.iastate.edu> jwright@atanasoff.cs.iastate.edu (Jim Wright) writes:
>In article <3424@cbnewsc.ATT.COM> fjo@cbnewsc.ATT.COM (frank.j.owen) writes:
>| All the variables of each function are in the stack frame
>| for that function and CAN be displayed and even modified. Of course you
>| must in some way tell the debugger WHICH stack frame you are talking about,
>| in case there are locals of different functions with the same name, but
>| that is a do-able thing.
>
>How should recursive functions be handled?  Are they a special case at all?

  If you have some way to point at a stack frame, there isn't much of
a problem with this.  The easiest thing would be a pop-up menu (I
gather there is one already from some other discussion).  "Up" and
"Down" commands to move up and down the stack would be nice.

>Do you really want to allow local variables be changed in calling functions?

  If the compiler does good optimization, changing non-local variables
is a big no-no.  Why?  Because other values in the routine could
depend on them.  For instance,

		n = 8;
		for (i=1; i<=n+2; i++)
		  call_some_function();

The compiler could figure out that n+2 can be computed outside of the
loop, and stick it in a register.  Changing N will then not change
N+2.  Of course, you could always turn off optimizations if you're
debugging, but this is...well, not necessarily good.  It might be nice
to just to warn the programmer: "If you change a variable which is not
local to the current procedure, bad things may happen."

  Actually, it shouldn't be too hard to implement a multiple-context
debugger.  The compiler has to generate a mapping of what variables
are in which register, and which registers are saved on the stack, at
the time of a function call.  This should be enough information for
the debugger to walk back up the stack, "restoring" registers so that
it can figure out what their values would be after some call returns
(and thus when that function's context is reentered).
   
+----------------------------------+------------------+
| Anton Rang (grad student)        | rang@cs.wisc.edu |
| University of Wisconsin--Madison |                  |
+----------------------------------+------------------+

"You are in a twisty little maze of Unix versions, all different."