From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5943 invoked by alias); 11 Oct 2004 18:54:16 -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 5929 invoked from network); 11 Oct 2004 18:54:15 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 11 Oct 2004 18:54:15 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.10) with ESMTP id i9BIsFhd028479 for ; Mon, 11 Oct 2004 14:54:15 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i9BIsAr07233; Mon, 11 Oct 2004 14:54:10 -0400 Received: from localhost.localdomain (vpn50-43.rdu.redhat.com [172.16.50.43]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id i9BIs9Q7005530; Mon, 11 Oct 2004 14:54:09 -0400 Received: from saguaro (saguaro.lan [192.168.64.2]) by localhost.localdomain (8.12.11/8.12.10) with SMTP id i9BIs3oa027437; Mon, 11 Oct 2004 11:54:04 -0700 Date: Mon, 11 Oct 2004 19:16:00 -0000 From: Kevin Buettner To: Fabian Cenedese Cc: Subject: Re: View registers from stack frames Message-Id: <20041011115403.57327509@saguaro> In-Reply-To: <5.2.0.9.1.20041008105008.01d72828@NT_SERVER> References: <5.2.0.9.1.20041007134711.01d12d90@NT_SERVER> <5.2.0.9.1.20041007134711.01d12d90@NT_SERVER> <5.2.0.9.1.20041008105008.01d72828@NT_SERVER> Organization: Red Hat Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SW-Source: 2004-10/txt/msg00286.txt.bz2 On Fri, 08 Oct 2004 10:54:34 +0200 Fabian Cenedese wrote: > >> In frame 0 pc and lr are correct (different), but in the other frames > >> they always have the same value whereas lr should have the > >> value of the pc of the next frame, right? > > > >Recent versions of GDB show the same value for lr and pc for the later > >frames. I think this is okay. > > > >Kevin > > I have only tested the --target=powerpc-eabi version so I don't know about > other processors. Is this true that gdb is supposed to show pc and lr with > the same values for stack frames >0? Isn't the purpose of the lr to point > to the previous stack frame (and so be different from the actual pc)? > And if the actual behaviour is correct then why is it different for frame 0? I agree that this seems counter-intuitive, particularly after working with it behaving the "other" way for so long. If you set a breakpoint at the start of a function and the run until that breakpoint, you'll find that LR does indeed point to the address at which execution will continue when the current function returns in a normal manner. PC will be the address of the instruction at which you've stopped. These values should be different. Now, suppose you step through the function until you reach a call. If you step over that call and examine PC and LR, you'll find that they have the same value. Why is this so? It's because the "call" (bl) instruction puts pc+4 into LR and branches to the function. Since you've stepped over the function, and since LR is restored in that function's prologue, you'll find that LR contains the address at which you're currently stopped which is in fact the current PC value. Those lower frames are in the same situation that our top-most frame is in in the second case. A "call" was the last instruction to be executed in that frame; this means that the LR value is actually set to the value of the PC just after the call. Looking at it another way, the reason that PC and LR are the same value for frames other than the topmost frame (excluding possible sigtramp frames, where they may in fact be different), is because LR changes over the lifetime of the function. GDB is reporting this as accurately as it can. Kevin