From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15502 invoked by alias); 5 Oct 2004 13:53:56 -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 15463 invoked from network); 5 Oct 2004 13:53:54 -0000 Received: from unknown (HELO smtp.hispeed.ch) (62.2.95.247) by sourceware.org with SMTP; 5 Oct 2004 13:53:54 -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 i95DroAR027042 for ; Tue, 5 Oct 2004 15:53:51 +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, 05 Oct 2004 15:52:26 +0200 Message-Id: <5.2.0.9.1.20041005154532.01d52ec0@NT_SERVER> X-Sender: cenedese@NT_SERVER (Unverified) Date: Tue, 05 Oct 2004 14:02:00 -0000 To: gdb@sources.redhat.com From: Fabian Cenedese Subject: Re: View registers from stack frames In-Reply-To: <4162A185.2070409@gnu.org> References: <5.2.0.9.1.20041005142840.01d03818@NT_SERVER> <5.2.0.9.1.20041005142840.01d03818@NT_SERVER> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MDaemon-Deliver-To: gdb@sources.redhat.com X-Return-Path: cenedese@indel.ch X-SW-Source: 2004-10/txt/msg00086.txt.bz2 >>With the stack commands (frame, up, down) I can select a different >>stack frame. Local variables and arguments (even with same name) >>have different values, depending on the stack frame number. But it >>seems that registers aren't corrected for previous stack frames. Is >>this correct? e.g. the PC and LR should change their value on every >>frame, and the PC was the last LR. But "info reg" always shows the >>same values. Is there any way to get the previous frame's registers? >>When I do "info frame x" I get something like "saved pc 0x..." so at >>least this information is available, why isn't this put into the register >>overview? And what about the other SPRs and GPRs? > >You've just described the expected and correct behavior. That makes it so= und like an architecture specific bug. Which architecture system is this o= n, and can you post a transcript. I'm using a self built gdb-6.1.1 for PPC-targets and cygwin. The communication with the target is over a stub-server to a PPC-board. This is some sample session snippet: (gdb) thread 21 [Switching to thread 21 (Thread 1578452)]#0 CMyWorkerTask::Test ( this=3D0x1815d4, str=3D@0x18d734) at N:\Temp\SAMCLASS\Applicat\Src\Test1.cpp:476 476 while (uTest2 < 3000001){ (gdb) bt #0 CMyWorkerTask::Test (this=3D0x1815d4, str=3D@0x18d734) at N:\Temp\SAMCLASS\Applicat\Src\Test1.cpp:476 #1 0x00060564 in CMyWorkerTask::Test (this=3D0x1815d4, str=3D@0x18d734) at N:\Temp\SAMCLASS\Applicat\Src\Test1.cpp:469 #2 0x00060408 in CMyWorkerTask::Action (this=3D0x1815d4) at N:\Temp\SAMCLASS\Applicat\Src\Test1.cpp:433 #3 0x0008c8a8 in CINOSTask::MainLoop (this=3D0x1815d4) at N:\Temp\SAMCLASS\os\inos\Src\Inos.cpp:823 #4 0x0008c6bc in CINOSTask::CINOSTask (this=3D0x1815d4, aName=3D0x64646464 "|=F9\022", aStackSize=3D1684300900, aPriority=3D168= 4300900, aFloatingPoint=3D1684300900, aTimeSlice=3D1684300900, aInterruptsDisabled=3D1684300900, apHandler=3D0x64646464, apObject=3D0x= 132fb8) at N:\Temp\SAMCLASS\os\inos\Src\Inos.cpp:786 #5 0x32414000 in ?? () (gdb) p/x $pc $1 =3D 0x6056c (gdb) p/x $lr $2 =3D 0x60564 (gdb) f 1 #1 0x00060564 in CMyWorkerTask::Test (this=3D0x1815d4, str=3D@0x18d734) at N:\Temp\SAMCLASS\Applicat\Src\Test1.cpp:469 469 Test(str); (gdb) info frame 1 Stack frame at 0x18d6b4: pc =3D 0x60564 in CMyWorkerTask::Test(CINOSString &) (N:\Temp\SAMCLASS\Applicat\Src\Test1.cpp:469); saved pc 0x60408 called by frame at 0x18d6fc, caller of frame at 0x18d66c source language c++. Arglist at 0x18d6b4, args: this=3D0x1815d4, str=3D@0x18d734 Locals at 0x18d6b4, Previous frame's sp in r1 (gdb) p/x $pc $3 =3D 0x6056c (gdb) p/x $lr $4 =3D 0x60564 (gdb) frame 2 #2 0x00060408 in CMyWorkerTask::Action (this=3D0x1815d4) at N:\Temp\SAMCLASS\Applicat\Src\Test1.cpp:433 433 Test(str); (gdb) info frame 2 Stack frame at 0x18d6fc: pc =3D 0x60408 in CMyWorkerTask::Action(void) (N:\Temp\SAMCLASS\Applicat\Src\Test1.cpp:433); saved pc 0x8c8a8 called by frame at 0x18d7d4, caller of frame at 0x18d6b4 source language c++. Arglist at 0x18d6fc, args: this=3D0x1815d4 Locals at 0x18d6fc, Previous frame's sp in r1 (gdb) p/x $pc $5 =3D 0x6056c (gdb) p/x $lr $6 =3D 0x60564 My question is: why do pc and lr (and all other registers) always show the = same value even if I have selected another stack frame? I would have expected th= at pc changes to 0x60564 in frame 1 and 0x60408 in frame 2, lr likewise to 0x60408 in frame 1 and 0x8c8a8 in frame 2. Why is this not the case? That's a littl= e bit misleading. I would like not only to see variables and arguments in previous frames but also the registers. Thanks bye Fabi