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."