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