From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16231 invoked by alias); 7 Jun 2003 22:37:04 -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 16051 invoked from network); 7 Jun 2003 22:36:56 -0000 Received: from unknown (HELO localhost.redhat.com) (24.157.166.107) by sources.redhat.com with SMTP; 7 Jun 2003 22:36:56 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 294FF2B5F; Sat, 7 Jun 2003 18:36:46 -0400 (EDT) Message-ID: <3EE268FE.8050801@redhat.com> Date: Sat, 07 Jun 2003 22:37:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Theodore A. Roth" Cc: gdb@sources.redhat.com Subject: Re: avr and frame unwinding References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-06/txt/msg00091.txt.bz2 > On Thu, 5 Jun 2003, Andrew Cagney wrote: > > :)Can you try the exact same operation with a GDB that doesn't have the > :)changes? That way it should be possible to compare the two traces > :)side-by-side and see where things are going wrong. > :) > :)A guess is that it is getting the unwound PC value wrong. For the d10v > > That was the problem. I've got it working, but the solution was ugly (see > below). > > :)I had to make two tweaks: > :) > :)- abort the prologue scanner when it reached PC if that is before the > :)end of the prologue > :)This stopped the prologue getting the unwound PC's location wrong. It > :)may not have yet executed the save PC instruction. > > This seems to also hold for the avr. Adding the extra pc check before > prologue scanning like the d10v does got things working as far as stepping > and backtracing go. > > :) > :)- track the register that the PC is in before it is saved > :)The code needs to be able to unwind the PC value in the prologue before > :)it has been saved on the stack. > :) > :)Andrew > :) > > Thanks for the nudge Andrew. > > 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? > 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; this memcpy will need to be a store_unsigned_integer (bufferp, pc, SIZEOF_AVR_PC); > 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. Andrew