This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: CRIS port; frame cleanup crash
Andrew Cagney wrote:
And callfuncs.exp, and a sequence like:
./gdb callfuncs
(gdb) break add
(gdb) break main
(gdb) run
(gdb) print add(1,2)
(gdb) bt
(gdb) print add(3,4)
(gdb) bt
add(3,4)
<dummy frame>
add (1,2)
<dummy frame>
main ()
(gdb)
is a good check of dummy frames
Ok, backtrace doesn't work at all. (find_dummy_frame() isn't able to locate the dummy frame because fp doesn't match dummyframe->top.) A couple of questions regarding this:
Ok, you've tripped over a bit of screwed up GDB history. 'till the
frame rewrite the choice of dummyframe->top was very arbitrary cf:
/* An older target that hasn't explicitly or implicitly
saved the dummy frame's top-of-stack. Try matching the
FP against the saved SP and FP. NOTE: If you're trying
to fix a problem with GDB not correctly finding a dummy
frame, check the comments that go with FRAME_ALIGN() and
UNWIND_DUMMY_ID(). */
frame_align(): this function is only concerned with architecture issues, and not ABI issues, right? What I mean is that we're not mimicking anything the compiler would do the way we do when we set up arguments for a function call. If the architecture has no alignment restrictions on the stack, then we shouldn't have to do any stack alignment, although the compiler might align it for performance reasons.
It's more an ABI issue.
Frame alighment is oftem more strict than ISA alignment. For instance,
a 32-bit machine may require 4-byte alignment, but the ABI might specify
that a stack must be 8 or even 16-byte aligned when entering a function.
push_dummy_call(): the CRIS code allocates more space on the stack than is actually needed; is this going to cause me problems? Since, as I understand it, the SP returned from push_dummy_call() must match the SP unwound when unwinding the dummy id I'm thinking I'll either have to get rid of the over-allocation on the stack (preferred) or compensate for it when unwinding the dummy id. Is this correct?
That is correct.
/* Sanity. The exact same SP value is returned by
PUSH_DUMMY_CALL, saved as the dummy-frame TOS, and used by
unwind_dummy_id to form the frame ID's stack address. */
As for which of the two choices is prefered, which ever makes your life
easier.
FWIW, everything up to and including the cmp10(...) test in callfuncs.exp works, so at least the argument setup seems ok.
ya!
Andrew