Re: avr and frame unwinding

["Theodore A. Roth" <troth@openavr.org>]

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