From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 104553 invoked by alias); 28 Nov 2015 13:37:28 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 104533 invoked by uid 89); 28 Nov 2015 13:37:27 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.2 X-HELO: p3plsmtpa06-03.prod.phx3.secureserver.net Received: from p3plsmtpa06-03.prod.phx3.secureserver.net (HELO p3plsmtpa06-03.prod.phx3.secureserver.net) (173.201.192.104) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Sat, 28 Nov 2015 13:37:26 +0000 Received: from [192.168.7.137] ([209.156.254.135]) by p3plsmtpa06-03.prod.phx3.secureserver.net with id n1dP1r00A2w30gp011dQaR; Sat, 28 Nov 2015 06:37:24 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Subject: Re: Tracing another stack From: Duane Ellis In-Reply-To: Date: Sat, 28 Nov 2015 13:37:00 -0000 Cc: gdb@sourceware.org Content-Transfer-Encoding: quoted-printable Message-Id: <6270C782-0078-4B91-B8FC-B51A6338EB5E@duaneellis.com> References: To: Celelibi X-IsSubscribed: yes X-SW-Source: 2015-11/txt/msg00043.txt.bz2 > On Nov 27, 2015, at 10:01 PM, Celelibi wrote: >=20 > Hello, >=20 > I use gdb with the gdb-stub of qemu to debug a boot loader. When a > memory fault occurs, a message is printed with the content of most > registers and a new stack is created to run the handler that never > terminates. >=20 > Can I tell gdb to examine the stack given the content of the stack > pointer, stack base and program counter of a stack that is not the > current one? >=20 > I tried setting $rsp and $rip to the values I got from the printed > message, but it turns out it confuses gdb. The "bt" commands shows the > right first stack frame, but the next ones are those of the interrupt > handler. >=20 >=20 > Thanks in advance. > Celelibi >=20 What is your target? (arm? x86? mips?) What I do in these situations is this: Step 1: I create a global =E2=80=98volatile=E2=80=99 variable that is set t= o zero Step 2: The code - loops on that variable until it is non-zero So in the normal (non-debugger-attached) case the system hangs, and a watch= dog reset occurs. But - when I have the debugger attached I set a breakpoint on that endless = loop so I get a breakpoint hit. And using the debugger i set that global variable to 1 Step 3: I can now step out of this code :-) and back through the exception = return Which will eventually land me back in the offending location. Depending upon the target (i.e.: ARM vrs X86) you might want to make this e= xception handler return to the PREV or NEXT instruction instead of the inst= ruction that failed At that point you have the location where the error occurs. Another approach is this: If you know the offending address=E2=80=A6 you can often set a hardware *r= ead* or *write* breakpoint on that location =09 -Duane