This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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:


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.

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?

FWIW, everything up to and including the cmp10(...) test in callfuncs.exp works, so at least the argument setup seems ok.

Thanks,
Orjan

--
Orjan Friberg
Axis Communications



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]