From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15780 invoked by alias); 1 Dec 2015 08:46:54 -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 15656 invoked by uid 89); 1 Dec 2015 08:46:53 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_20,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-lf0-f47.google.com Received: from mail-lf0-f47.google.com (HELO mail-lf0-f47.google.com) (209.85.215.47) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Tue, 01 Dec 2015 08:46:51 +0000 Received: by lfdl133 with SMTP id l133so229420162lfd.2 for ; Tue, 01 Dec 2015 00:46:48 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.25.169.15 with SMTP id s15mr27617346lfe.20.1448959608073; Tue, 01 Dec 2015 00:46:48 -0800 (PST) Received: by 10.25.197.5 with HTTP; Tue, 1 Dec 2015 00:46:47 -0800 (PST) In-Reply-To: <6270C782-0078-4B91-B8FC-B51A6338EB5E@duaneellis.com> References: <6270C782-0078-4B91-B8FC-B51A6338EB5E@duaneellis.com> Date: Tue, 01 Dec 2015 08:46:00 -0000 Message-ID: Subject: Re: Tracing another stack From: Celelibi To: Duane Ellis Cc: gdb@sourceware.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2015-12/txt/msg00000.txt.bz2 2015-11-28 14:37 UTC+01:00, Duane Ellis : > >> On Nov 27, 2015, at 10:01 PM, Celelibi wrote: >> >> Hello, >> >> 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. >> >> 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? >> >> 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. >> >> >> Thanks in advance. >> Celelibi >> > > What is your target? (arm? x86? mips?) My target is x86_64 with OVMF as UEFI firmware. > > What I do in these situations is this: > > Step 1: I create a global =E2=80=98volatile=E2=80=99 variable that is set= to 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 wat= ch > 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 Attaching the debugger soon enough isn't a problem. The problem is that when an interrupt occurs (like a division by zero), the code that gets executed isn't mine. And this code sets up a new stack and goes into a fancy "while (1) {}". I just found a solution that consists in setting a breakpoint directly in the interrupt handler, before the stack is modified. But this is definitely not as generic as examining another stack given its address. Maybe what I did by setting $rip and $rsp was good but gdb had a cache of the stack frame? > > 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. What do you call "the exception return"? > > Depending upon the target (i.e.: ARM vrs X86) you might want to make this > exception handler return to the PREV or NEXT instruction instead of the > instruction that failed This is has been decided by Intel whether the stacked instruction pointer is the address of the buggy instruction or the next one. I'm not sure what you mean then. > Another approach is this: > If you know the offending address=E2=80=A6 you can often set a hardware = *read* or > *write* breakpoint on that location That's what I'd do if I knew what instructions trigger the bugs. :) My goal is to set some memory protections (pages not executable or not writable) and catch the memory errors of a complex piece of software (the boot loader syslinux). So I have pretty much no clue about where the offending addresses will be. Best regards, Celelibi