Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!dewey.soe.berkeley.edu!oster
From: oster@dewey.soe.berkeley.edu (David Phillip Oster)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Problem with LSC 4.0 debugger.
Message-ID: <31520@ucbvax.BERKELEY.EDU>
Date: 26 Sep 89 04:00:08 GMT
References: <244@dbase.UUCP> <3424@cbnewsc.ATT.COM> <1563@atanasoff.cs.iastate.edu>
Sender: usenet@ucbvax.BERKELEY.EDU
Reply-To: oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster)
Distribution: na
Organization: School of Education, UC-Berkeley
Lines: 50

In article <1563@atanasoff.cs.iastate.edu> jwright@atanasoff.cs.iastate.edu.UUCP (Jim Wright) writes:
>How should recursive functions be handled?  Are they a special case at all?
>Do you really want to allow local variables be changed in calling functions?

Just handle this problem the same way it is already handled: you set a
context in the program window by using the pop-up menu at the bottom of
the window.  If you enter variable names in the data window, they are
interpreted in the program window's current context.  Since the compiler
generated the code in the first place, it is easy for it to remember
whther there is a stack frame, and as for register variables, a simple
integer remembers them, since they are allocated sequentially. At the
worst, you could add a single bit for "this frame is too complex to
remember". A debugger that let me look at variables up the stack is still
better than what I've got. 

While you are at it: how about letting me save the debugger state in a
file, so I can reload it when I run the program again, and have the
debugger know what files and what variables I was looking at, and what
breakpoints I set.

How about treating the parameter list of a procedure, and the set of local
variables of a procedure as a pseudo-struct, so I can look at the whole
set of them in their own window, as I look at structs now. In fact, this
would be a reasonable interpretation of typing a procedure name into the
data window, in that procedure's context: it would have the value "stack
frame 0x0000", and double clicking on it would bring up a stack-like
window of all the locals and parameters.  Many lisp debuggers work this
way.

As it stands, the popup menu at the bottom of the program window is really
an annoying feature: I can point at nested stack frames, but having
pointed at them the debugger won't let me do anything meaningful with
them.

Also, how about debug time variables or at least macros, so I don't have
to refer to a structure as (**(**(**(**foo).fum).fie).fazzle).fop simply
because my progragram doesn't happen to assign
(**(**(**foo).fum).fie).fazzle to a variable.  I should be able to assign
it to a variable, say "piggins" at debug time, so I could just type
(**piggins).fop  rather than the whole tedious expression. I'd even be
happy if it were really a macro, and not a true variable.

Also, how about making the debugger trust the Make command: if I use the
make command to tell the compiler that I know fiels a.c, b.c, and c.c
weren't really modified by a change to a .h file, the debugger doesn't
believe me and refuses to let me debug any functions in those files until
I do a full recompile. Why?

Don't get me wrong, I still think it is a great debugger, I just wish that
Lightspeed C version 4 had improved on it a little.