From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8876 invoked by alias); 8 Jun 2003 00:26:58 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 8817 invoked from network); 8 Jun 2003 00:26:57 -0000 Received: from unknown (HELO planck.amplepower.com) (216.39.162.139) by sources.redhat.com with SMTP; 8 Jun 2003 00:26:57 -0000 Received: from [192.168.8.29] (helo=bozoland.mynet) by planck.amplepower.com with esmtp (Exim 3.36 #1 (Debian)) id 19Onre-0006Zw-00; Sat, 07 Jun 2003 17:16:51 -0700 Date: Sun, 08 Jun 2003 00:26:00 -0000 From: "Theodore A. Roth" X-X-Sender: troth@bozoland.mynet To: Andrew Cagney cc: gdb@sources.redhat.com Subject: Re: avr and frame unwinding In-Reply-To: <3EE268FE.8050801@redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2003-06/txt/msg00092.txt.bz2 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