Path: utzoo!attcan!uunet!ginosko!gem.mps.ohio-state.edu!wuarchive!husc6!endor!siegel
From: siegel@endor.harvard.edu (Rich Siegel)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Problem with LSC 4.0 debugger.
Message-ID: <2693@husc6.harvard.edu>
Date: 23 Sep 89 15:35:29 GMT
References: <85031@pyramid.pyramid.com> <244@dbase.UUCP>
Sender: news@husc6.harvard.edu
Reply-To: siegel@endor.UUCP (Rich Siegel)
Distribution: na
Organization: Symantec Language Products Group
Lines: 58

In article <244@dbase.UUCP> awd@dbase.UUCP (Alastair Dallas) writes:
>In article <85031@pyramid.pyramid.com>, bjb@pyramid.pyramid.com (Bruce Beare) writes:
>> The think C 4.0 debugger is not able to show stack variables for
>> functions that are 1 or more calling frames "up" the stack. 
>>
>> This behavior of LSC's Debugger is silly. It has all of the information
>> it needs - it knows the stack offset of WINDid (it can display it if
>> we put a breakpoint in the function Cwindow:Iwindow - before calling 
>> CheckResource), and it knows how to trace through the stack frames.
>> It just doesn't bother to display the information.

(In advance, please excuse any rampant sarcasm. I'm having a tough time.)

It's quite clear that you didn't consider all of the issues before posting
your article. For example:

	The debugger is able to do its trace of the procedure call chain by
examining return addresses, not by examining stack frames? Why? Simple: not
all routines generate a LINK/UNLK pair; if a function has no arguments, no
local variables, and no compiler-generated temps, then there will be
no LINK/UNLK pair, and therefore there's no way to trace the call chain
for that routine. Hence, the debugger traces return addresses instead of
A6 frames.

	Furthermore, it's currently impossible to find variables in frames
other than the current activation. Why? Because if the variable is allocated
in a register, it's been saved *somewhere* on the stack by a MOVEM instruction.
Currently, the compiler does not retain the information as to where the
saved registers are, or what they are, and there's no heuristic that the
debugger can apply in order to find the saved registers. Non-register
variables can't be examined either, for similar reasons; the debugger
hasn't a clue as to where the saved A6 is, or even if there is one.

"But THINK Pascal can do it,", I hear you say. Quite true, but THINK Pascal's
fundamentally different in its architecture - both in the way it maintains
its debugging information, and in the way that the debugger works. Several
informed design decisions were made for the THINK C debugger, and they
were good ones.

I agree that it's inconvenient to not be able to display non-local variables,
and I've tried to explain why, given that the reasoning you presented is
incorrect.

R.



~~~~~~~~~~~~~~~
 Rich Siegel
 Staff Software Developer
 Symantec Corporation, Language Products Group
 Internet: siegel@endor.harvard.edu
 UUCP: ..harvard!endor!siegel

"There is no personal problem which cannot be solved by sufficient
application of high explosives."

~~~~~~~~~~~~~~~