From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1856 invoked by alias); 6 Oct 2004 06:53:45 -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 1844 invoked from network); 6 Oct 2004 06:53:44 -0000 Received: from unknown (HELO smtp.hispeed.ch) (62.2.95.247) by sourceware.org with SMTP; 6 Oct 2004 06:53:44 -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 i966rgpd015327 for ; Wed, 6 Oct 2004 08:53:43 +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 ; Wed, 06 Oct 2004 08:52:42 +0200 Message-Id: <5.2.0.9.1.20041006084237.01cf98c0@NT_SERVER> X-Sender: cenedese@NT_SERVER (Unverified) Date: Wed, 06 Oct 2004 07:18:00 -0000 To: gdb@sources.redhat.com From: Fabian Cenedese Subject: Re: View registers from stack frames In-Reply-To: <41634E72.70205@gnu.org> References: <5.2.0.9.1.20041005171658.01d208e0@NT_SERVER> <20041005140227.GA13586@nevyn.them.org> <5.2.0.9.1.20041005154532.01d52ec0@NT_SERVER> <5.2.0.9.1.20041005142840.01d03818@NT_SERVER> <5.2.0.9.1.20041005142840.01d03818@NT_SERVER> <5.2.0.9.1.20041005154532.01d52ec0@NT_SERVER> <5.2.0.9.1.20041005171658.01d208e0@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/msg00112.txt.bz2 >>It is better in so far as the pc did change from frame 0 to frame 1. >>But now reading the whole call stack is messed up. Funny though >>that only the pc stays the same, other values do change. > >That's a separate bug - the new frame unwind code is running into trouble.= I'd check a current gdb (:-/), and if no luck, post more details here - K= evinB is the PPC maintainer. I just tried with gdb-6.2.1 but it has the same errors in the unwinding. Here is a bt with gdb-6.2.1 of the halted thread: GNU gdb 6.2.1 --snip-- This GDB was configured as "--host=3Di686-pc-cygwin --target=3Dpowerpc-eabi= "... (gdb) bt #0 CMyWorkerTask::Test (this=3D0x1815d4, str=3D@0x18d734) at N:\Temp\SAMCLASS\Applicat\Src\Test1.cpp:456 #1 0x00060564 in CMyWorkerTask::Test (this=3D0x1815d4, str=3D@0x18d734) at N:\Temp\SAMCLASS\Applicat\Src\Test1.cpp:469 #2 0x00060564 in CMyWorkerTask::Test (this=3D0x1815d4, str=3D@0xa) at N:\Temp\SAMCLASS\Applicat\Src\Test1.cpp:469 #3 0x00060564 in CMyWorkerTask::Test (this=3D0x1815d4, str=3D@0x0) at N:\Temp\SAMCLASS\Applicat\Src\Test1.cpp:469 #4 0x00060564 in CMyWorkerTask::Test (this=3D0x1815d4, str=3D@0x64646464) at N:\Temp\SAMCLASS\Applicat\Src\Test1.cpp:469 #5 0x00060564 in CMyWorkerTask::Test (this=3D0x1815d4, str=3D@0x32414000) at N:\Temp\SAMCLASS\Applicat\Src\Test1.cpp:469 Previous frame inner to this frame (corrupt stack?) Here is a bt of the same target with gdb-6.1.1 (last working gdb): GNU gdb 6.1.1 --snip-- This GDB was configured as "--host=3Di686-pc-cygwin --target=3Dpowerpc-eabi= ".. (gdb) bt #0 CMyWorkerTask::Test (this=3D0x1815d4, str=3D@0x18d734) at N:\Temp\SAMCLASS\Applicat\Src\Test1.cpp:456 #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 ?? () (It's possible that frames 4 and 5 have wrong data as the start of our call stack is maybe not properly initialized. 0x64646464 is our pattern of uninitialized memory.) The first two frames seem ok, only frame 3 and more are wrong. If more info is needed (e.g. the remote debug protocol) I can also post it here or send to anyone. Well, that only leaves me with the cvs version... Thanks bye Fabi