From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7300 invoked by alias); 15 Oct 2004 22:34:13 -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 7292 invoked from network); 15 Oct 2004 22:34:12 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 15 Oct 2004 22:34:12 -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 i9FMYB3l014768 for ; Fri, 15 Oct 2004 18:34:12 -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 i9FMY1r08160; Fri, 15 Oct 2004 18:34:01 -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 i9FMY0Yo018508; Fri, 15 Oct 2004 18:34:00 -0400 Received: from saguaro (saguaro.lan [192.168.64.2]) by localhost.localdomain (8.12.11/8.12.10) with SMTP id i9FMXmB9013918; Fri, 15 Oct 2004 15:33:54 -0700 Date: Sat, 16 Oct 2004 15:11:00 -0000 From: Kevin Buettner To: Fabian Cenedese Cc: Subject: Re: View registers from stack frames Message-Id: <20041015153348.0085e482@saguaro> In-Reply-To: <5.2.0.9.1.20041012085225.01cecd88@NT_SERVER> 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> <5.2.0.9.1.20041012085225.01cecd88@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/msg00336.txt.bz2 On Tue, 12 Oct 2004 08:56:40 +0200 Fabian Cenedese wrote: > >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? >From the stack? If I'm not mistaken, the saved LR value should be at $sp+4. I'm not aware of any GDB internal variables which hold this value. Kevin