From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5083 invoked by alias); 12 Oct 2004 06:57:24 -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 5071 invoked from network); 12 Oct 2004 06:57:23 -0000 Received: from unknown (HELO smtp.hispeed.ch) (62.2.95.247) by sourceware.org with SMTP; 12 Oct 2004 06:57:23 -0000 Received: from indel.ch (217-162-27-127.dclient.hispeed.ch [217.162.27.127]) by smtp.hispeed.ch (8.12.6/8.12.6/tornado-1.0) with SMTP id i9C6vLZl014710 for ; Tue, 12 Oct 2004 08:57:22 +0200 Received: from fabi.indel.ch [192.168.1.19] by indel.ch [127.0.0.1] with SMTP (MDaemon.v2.7.SP5.R) for ; Tue, 12 Oct 2004 08:55:45 +0200 Message-Id: <5.2.0.9.1.20041012085225.01cecd88@NT_SERVER> X-Sender: cenedese@NT_SERVER (Unverified) Date: Tue, 12 Oct 2004 14:03:00 -0000 To: From: Fabian Cenedese Subject: Re: View registers from stack frames In-Reply-To: <20041011115403.57327509@saguaro> References: <5.2.0.9.1.20041008105008.01d72828@NT_SERVER> <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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MDaemon-Deliver-To: gdb@sources.redhat.com X-Return-Path: cenedese@indel.ch X-SW-Source: 2004-10/txt/msg00293.txt.bz2 >> 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. Thanks for your extensive explanation, it looks more clear now why it is the way it is. The value I assumed to be in LR (PC in last frame) is still reported from gdb as "saved PC". Is there another possibility to get this value than the stack frame info? Is this maybe stored in some gdb internal variable? Thanks bye Fabi