Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!gem.mps.ohio-state.edu!ginosko!uakari.primate.wisc.edu!nic.MR.NET!hal!ncoast!allbery From: allbery@NCoast.ORG (Brandon S. Allbery) Newsgroups: comp.sys.mac.programmer Subject: Re: Problem with LSC 4.0 debugger. Message-ID: <1989Sep29.030916.24282@NCoast.ORG> Date: 29 Sep 89 03:09:16 GMT References: <85031@pyramid.pyramid.com> <244@dbase.UUCP> <2693@husc6.harvard.edu> Reply-To: allbery@ncoast.ORG (Brandon S. Allbery) Followup-To: comp.sys.mac.programmer Distribution: na Organization: North Coast Public Access UN*X, Cleveland, OH Lines: 34 As quoted from <2693@husc6.harvard.edu> by siegel@endor.harvard.edu (Rich Siegel): +--------------- | 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 +--------------- Huh? All it would take is a reasonably standard function-entry procedure: every function starts with LINK, MOVE.M, and ADD/ADDQ/LEA in a particular order (what order doesn't matter that much for this purpose, only that the same order must be used in all functions; of course, the interaction between them mandates some order from the processor's standpoint, but I forget at the moment what it is), all optional. The debugger can then peek at the beginning of the function's code to see how to disentangle the stack. UNIX debuggers do this regularly. Or am I missing something? (I doubt that UNIX-vs.-MacOS is a relevant distinction, since ultimately what we're talking about is standard 68000 function entry sequences and the OS could care less about them.) (No, I'm not needling you or anything like that; after nursemaiding old ncoast for eight years, I like to think I've learned something about the care and feeding of a 68000 at the assembly-language level... and here you're suggesting to me that it doesn't work that way on a Mac, just after I finally buy a development system. I'm beginning to fear that I'm going to have to start all over again despite my past experience....) ++Brandon -- Brandon S. Allbery, moderator of comp.sources.misc allbery@NCoast.ORG uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu bsa@telotech.uucp, 161-7070 BALLBERY (MCI), ALLBERY (Delphi), B.ALLBERY (GEnie) Is that enough addresses for you? no? then: allbery@uunet.UU.NET (c.s.misc)