From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18439 invoked by alias); 7 Jun 2003 20:23:49 -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 18381 invoked from network); 7 Jun 2003 20:23:48 -0000 Received: from unknown (HELO planck.amplepower.com) (216.39.162.139) by sources.redhat.com with SMTP; 7 Jun 2003 20:23:48 -0000 Received: from [192.168.8.29] (helo=bozoland.mynet) by planck.amplepower.com with esmtp (Exim 3.36 #1 (Debian)) id 19Ok4N-0000EF-00; Sat, 07 Jun 2003 13:13:44 -0700 Date: Sat, 07 Jun 2003 20:23: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: <3EDFF5D5.5060704@redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2003-06/txt/msg00090.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. 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)); pc = (extract_unsigned_integer (buf, 2) * 2) >> 8; memcpy (bufferp, &pc, sizeof(pc)); } else { read_memory (this_saved_regs[regnum], bufferp, register_size (current_gdbarch, regnum)); } } return; } /* No luck, assume this and the next frame have the same register value. If a value is needed, pass the request on down the chain; otherwise just return an indication that the value is in the same register as the next frame. */ frame_register_unwind (next_frame, regnum, optimizedp, lvalp, addrp, realnump, bufferp); } 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? Ted Roth