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)