Debugging without a frame pointer.

[Duane Ellis <duane_ellis at franklin dot com>]

Hi all,

I'm working on a custom GDB port for our custom RISC CPU chip we have
had GCC and Insight up and running (have had it going for 6+ months
now) (We don't use GAS or LD, we use our own assembler & linker)

One problem we have is we don't have a stack frame register and there
is no real easy way of doing it.

The debug format we are using is 'COFF'.

I'm trying to add the abilty to go up/down in the stack frame to
Insight for our custom CPU.

I think I have a solution but I wanted to know if this type of stuff
has been done before or not for other CPU chips.

We don't have a frame register - but we do have symbolic information
from the compiler.... I was thinking that I could

(A) In GCC's FUNCTION_PROLOGUE() macro I could output an additional
    local stack based symbol (these work) say the 'coff' stuff looks
    like this:

	.stack XX, rEtUrNaDdReSs, $f

   Where 'XX' is the offset into the stack frame that holds the return
   address of the function.
   
   The fields for this pseudo op are:
       1) - offset to variable
       2) - variable name
       3) - variable type, $f happens to mean unsigned long.

(B) Inside of INSIGHT, when I need to find the stack frame, I can go
    up/down the stack frame and find variables I should be able to:

       Step 1: Take current PC - find the name of the function
	       that I am within.

       Step 2: Look for my 'magic symbol', as a stack local symbol
	       and extract it's value.

       Step 3: Peek into the stack and get the return address.

       Step 4: Try in some way to validate the return address.
	       ie: Does the return address point within some
	       real function that makes sense? (vrs into data area)
	       
	       If the sniffed out return address is bogus, tell gdb -
	       Sorry you are at the top stack frame...  or something
	       like that.

    The only downside of this is if the code adjusts the stack pointer
    in any way in the middle of the function and the user is single
    stepping assembly language instructions.

Anybody see anything wrong with this approach?

is this idea crazy?

or does it sound like a plan?

-Duane.