Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!mit-eddie!uw-beaver!tektronix!tekcrl!terryl
From: terryl@tekcrl.UUCP
Newsgroups: comp.sys.m68k
Subject: Re: stack backtrace on a 68010
Message-ID: <1565@tekcrl.TEK.COM>
Date: Tue, 7-Apr-87 14:24:56 EST
Article-I.D.: tekcrl.1565
Posted: Tue Apr  7 14:24:56 1987
Date-Received: Sat, 11-Apr-87 00:12:33 EST
References: <18534@ti-csl.CSNET>
Reply-To: terryl@tekcrl.tek.com
Organization: Tektronix, Inc., Beaverton, OR.
Lines: 74
Keywords: 68k stack

In article <18534@ti-csl.CSNET> peters@ti-csl.CSNET (Pat Peters) writes:
>
>I am trying to construct a stack backtrace routine to run on a 68010
>system we are building (Internal use only.  This is not a product 
>announcement.).  I'm after the sort of thing that adb will give
>you when you use the $c command.  Unfortunately, all of our Unix
>source is for the Vax, so I can't just lift the algorithm from adb.
>
> ....Delete many lines about A6, etc.....
>

     Well, unfortunately, you don't say what system, or more importantly,
what compiler you are using. I'll describe things the way the MIT C compiler
works for a 68k machine:

     As you commented, A6 always points to the TOP of the stack frame (where
TOP is defined as a HIGHER address than the BOTTOM of the stack frame, where
stack frames grow DOWNWARDS) of the current procedure. At the TOP of the stack
frame (i.e. what A6 points to) is the previous value of A6 (i.e. the TOP of the
previous stack frame of the procedure that called the current procedure). Above
the TOP of the stack frame is the return address of the procdeure that called
the current procedure; above this is the arguments to the current procedure,
and above that are the local variables and temporaries of the previous proce-
dure. Believing that a picture is worth more than a thousand words, here is
a graphical representation:

				+-------------------------------+
	(Higher addresses)	| Top of previous stack frame	|
				| Local variables, temporaries	|
				| and saved registers of pre-	|
				| vious stack frame.		|
				| Arguments to next frame.	|
				| Return address to return to	|
				| after next procedure is	|
				| finished.			|
				|-------------------------------|
				| Previous value of A6 (i.e. the|
				| address of the top of the pre-|
				| vious stack frame).		|
				| Local variables, etc.		|
	(Lower addresses)	+-------------------------------+

     So now what you need to do a complete C stack trace back is: The current
value of A6 (so you can find the current value of the TOP of the current stack
frame), and the Program Counter (so you can tell what procedure you are in).
Everything else can be found from the above description. A6 points to the TOP
of the previous stack frame; at A6+4 is the return address, so now you can find
what procedure called this procedure. Keep following this chain until you find
the end of the stack frames (unfortunately, this is not compiler specific but
system specific. For our 68k systems, in the C runtime startup, we put a zero
value into A6, so when we have a zero value for the TOP of the previous stack
frame, we know we are done).

     Well, what about arguments to routines, you ask??? Well, again, this is
compiler specific. There is no way to explicitly know how many arguments are
passed to a routine, unlike the VAX where the calling convention says you have
to specify it. Luckily, some compilers help us out on this respect. Speci-
fically, the MIT C compiler always returns to an add-type instruction to pop
off the arguments, so if you look up the instruction to return to, you can
find out how many bytes were passed as arguments. Even luckier, the MIT C
compiler also pushes ALL non-floating point and structure arguments as a four-
byte quantity; it pushes floating point arguments as doubles, and structures
as-is. So without more knowledge about what kind of arguments were pushed,
you can only make a guess, usually that all arguments are simple four-byte
non-floating point, non-structure type arguments.

     Also note that arguments to routines are actually part of the calling
routine's stack frame, and are not part of the called routine's stack frame.

     Hope this helps soemwhat.

				Terry Laskodi
				     of
				Tektronix