Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!husc6!seismo!ut-sally!ut-ngp!infotel!pollux!ti-csl!peters From: peters@ti-csl.UUCP Newsgroups: comp.sys.m68k Subject: Re: stack backtrace on a 68010 Message-ID: <18700@ti-csl.CSNET> Date: Wed, 8-Apr-87 08:19:11 EST Article-I.D.: ti-csl.18700 Posted: Wed Apr 8 08:19:11 1987 Date-Received: Sat, 11-Apr-87 08:13:35 EST References: <755@killer.UUCP> Organization: TI Computer Science Center, Dallas Lines: 42 in article <755@killer.UUCP>, jfh@killer.UUCP (John Haugh) says: > > 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.... > > The stack on a M68000 looks something like this: > > SP + a bunch: > . > . > > > FP: ..... > Take that return address and find the instruction after the > jsr instruction. (Easy - it is at the return address.) Decode this > instruction to figure out how many arguments there were. Nice thought (in fact one I already had) but, 1. Inconvenient because the compiler will use several (I believe at least three different) ways of unwinding the stack. They are documented, however. 2. I've seen the compiler decide to unwind the stack at some time other than on return (the instruction at the return address may not be the one that restores the stack pointer). In case you're wondering, we use Green Hills C. The optimizer does some wonderful (but strange) things to the code. There is an option that will force generation of stack frames (put in specifically to facilitate back tracing the stack), but I don't see anywhere in the manual where they promise that the instruction pointed to by the return address is the one (of three types) that will restore the stack pointer. -- Patrick Peters UUCP: ut-sally!im4u!ti-csl!tifsie!pat Texas Instruments sun!texsun!ti-csl!tifsie!pat PO Box 655012 M/S 3635 uiucdcs!convex!smu!tifsie!pat Dallas, TX 75265 Voice: (214)995-2786