This is the mail archive of the gdb@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: avr and frame unwinding


On Sat, 7 Jun 2003, Theodore A. Roth wrote:

:)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));
:):)>             }

I think found the root of the ugliness. When the avr performs a call 
instruction the PC is pushed onto the stack, but it turns out that it is 
pushed in big endian order. For the most part though, the avr is little 
endian.

Ted Roth


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