This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: avr and frame unwinding
- From: "Theodore A. Roth" <troth at openavr dot org>
- To: Andrew Cagney <ac131313 at redhat dot com>
- Cc: gdb at sources dot redhat dot com
- Date: Sat, 7 Jun 2003 17:25:02 -0700 (PDT)
- Subject: Re: avr and frame unwinding
On Sat, 7 Jun 2003, Andrew Cagney wrote:
:)> Any idea how to make this piece of code sane? I'm not thrilled with what I
:)> had to do to get the PC read and converted then finally stored in bufferp.
:)> This function is analogous to saved_regs_unwinder() in d10v-tdep.c.
:)>
:)> static void
:)> avr_saved_regs_unwinder (struct frame_info *next_frame,
:)> CORE_ADDR *this_saved_regs,
:)> int regnum, int *optimizedp,
:)> enum lval_type *lvalp, CORE_ADDR *addrp,
:)> int *realnump, void *bufferp)
:)> {
:)> if (this_saved_regs[regnum] != 0)
:)> {
:)> *optimizedp = 0;
:)> *lvalp = lval_memory;
:)> *addrp = this_saved_regs[regnum];
:)> *realnump = -1;
:)> if (bufferp != NULL)
:)> {
:)> /* Read the value in from memory. */
:)>
:)> if (regnum == AVR_PC_REGNUM)
:)> {
:)> /* Reading the return PC from the PC register is slightly
:)> abnormal. register_size(AVR_PC_REGNUM) says it is 4 bytes,
:)> but in reality, only two bytes (3 in upcoming mega256) are
:)> stored on the stack.
:)
:)Is the PC 2 bytes, or that only two bytes are saved? You don't have a
:)d10v PC which is 2 bytes but addresses words?
The PC is stored on the stack as an unsigned 16-bit value which addresses
64K of 16-bit wide instructions. The problem is our remote targets perform
the word to byte addressing convertion before sending the PC register value
over the RSP. In this case, I have to read the PC from memory, so the remote
target only thinks it is making a memory read (which by the way uses a byte
addressing scheme). After reading the PC from memory, I need to convert it
to a byte address (multiply by 2).
:)
:)> Also, note that the value on the stack is an addr to a word
:)> not a byte, so we will need to multiply it by two at some
:)> point. */
:)>
:)> ULONGEST pc;
:)> unsigned char buf[2];
:)>
:)> read_memory (this_saved_regs[regnum], buf, sizeof (buf));
:)
:)Is this arrithmetic correct - I understand the ``* 2'' but not the ``>>8''.
:)
:)> pc = (extract_unsigned_integer (buf, 2) * 2) >> 8;
That's the ugly part I don't understand. It seems to give the correct
result, but now that I think about it more, it could mean that my memory
address is off by 1. I will have to re-examine that.
:)
:)this memcpy will need to be a
:)
:) store_unsigned_integer (bufferp, pc, SIZEOF_AVR_PC);
:)
I tried that, but it performed a endian byte swap and the PC came out wrong.
I dug around and saw what looked to be too many byte swaps.
:)> memcpy (bufferp, &pc, sizeof(pc));
:)> }
:)> else
:)> {
:)> read_memory (this_saved_regs[regnum], bufferp,
:)> register_size (current_gdbarch, regnum));
:)> }
:)
:)> The last problem I need to solve I think is also related to register
:)> unwinding. If I step down into a function, then 'up' to move up the stack
:)> frame, examining a local variable gives the wrong value. I need to do some
:)> more research into why this is happening though. Am I on the right track
:)> with thinking the register unwinding could be the problem? Maybe I'm setting
:)> the frame base incorrectly since it doesn't seem to resolve the variable's
:)> memory address?
:)
:)Sounds like you're on the right track. The new unwind code typically
:)has different:
:)
:) frame ID.stack_addr
:) frame {base,locals,args} address
:)
:)the former is the address of the previous frame's inner-most stack
:)address while the latter is the clasic frame pointer.
Thanks.
Now back to getting my brain wrapped around this.
Ted Roth