This is the mail archive of the
insight@sourceware.cygnus.com
mailing list for the Insight project.
Debugging without a frame pointer.
- To: insight at sourceware dot cygnus dot com
- Subject: Debugging without a frame pointer.
- From: Duane Ellis <duane_ellis at franklin dot com>
- Date: Thu, 27 Apr 2000 18:22:13 -0400
- Reply-to: 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.