Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!ucsd!ucbvax!hplabs!pyramid!bjb
From: bjb@pyramid.pyramid.com (Bruce Beare)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Problem with LSC 4.0 debugger.
Message-ID: <85348@pyramid.pyramid.com>
Date: 25 Sep 89 03:25:47 GMT
References: <85031@pyramid.pyramid.com> <244@dbase.UUCP> <2693@husc6.harvard.edu>
Reply-To: bjb@pyramid.pyramid.com (Bruce Beare)
Distribution: na
Organization: Pyramid Technology Corp., Mountain View, CA
Lines: 68

In article <2693@husc6.harvard.edu> siegel@endor.UUCP (Rich Siegel) writes:
>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."
>
>~~~~~~~~~~~~~~~

No Rich, I did not research how the compiler handles its calling sequence.
I did/do not feel that it is necessary. If the compiler does not leave enough
information around for the debugger to determine what is going on, I can
suggest a simple solution - fix the compiler to provide the required 
information.


Bruce Beare