public inbox for insight@sourceware.org
 help / color / mirror / Atom feed
* Debugging without a frame pointer.
@ 2000-04-27 15:22 Duane Ellis
  2000-05-08  8:01 ` Jim Blandy
  0 siblings, 1 reply; 2+ messages in thread
From: Duane Ellis @ 2000-04-27 15:22 UTC (permalink / raw)
  To: insight

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.

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Debugging without a frame pointer.
  2000-04-27 15:22 Debugging without a frame pointer Duane Ellis
@ 2000-05-08  8:01 ` Jim Blandy
  0 siblings, 0 replies; 2+ messages in thread
From: Jim Blandy @ 2000-05-08  8:01 UTC (permalink / raw)
  To: duane_ellis; +Cc: insight

GDB does support debugging functions lacking frame pointers on some
architectures.

If there isn't any more reliable source of information, GDB handles
these cases by actually analyzing the first few instructions of the
function, looking for an instruction that adjusts the stack pointer.
Usually, if you can discover where the stack pointer was on entry to
the function, you can find the saved return address; there's no harm
in choosing a convention here and making GCC stick to it.

For an example of a port that works this way, you might want to check
out mn10200_analyze_prologue in mn10200-tdep.c.

Handling functions whose frame size varies (because they call alloca,
use GCC's variable-sized arrays, etc.) is a challenge.  GDB pretty
much requires that such functions use a frame pointer register.  But
I don't see how GCC could find the local variables reliably unless
there was a frame pointer there for GDB to find.

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2000-05-08  8:01 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-04-27 15:22 Debugging without a frame pointer Duane Ellis
2000-05-08  8:01 ` Jim Blandy

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).