From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 634 invoked by alias); 5 Dec 2015 18:33:01 -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 581 invoked by uid 89); 5 Dec 2015 18:33:00 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-lb0-f171.google.com Received: from mail-lb0-f171.google.com (HELO mail-lb0-f171.google.com) (209.85.217.171) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Sat, 05 Dec 2015 18:32:58 +0000 Received: by lbbkw15 with SMTP id kw15so36708198lbb.0 for ; Sat, 05 Dec 2015 10:32:55 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.112.146.234 with SMTP id tf10mr10264493lbb.45.1449340375095; Sat, 05 Dec 2015 10:32:55 -0800 (PST) Received: by 10.25.197.5 with HTTP; Sat, 5 Dec 2015 10:32:54 -0800 (PST) In-Reply-To: <863D4E7B-2D4E-448B-8B41-EE97612A3BA3@duaneellis.com> References: <6270C782-0078-4B91-B8FC-B51A6338EB5E@duaneellis.com> <863D4E7B-2D4E-448B-8B41-EE97612A3BA3@duaneellis.com> Date: Sat, 05 Dec 2015 18:33: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/msg00007.txt.bz2 2015-12-01 14:24 UTC+01:00, Duane Ellis : > >>> 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) {}=E2=80=9D. > > > You are building UEFI =E2=80=A6 So why can=E2=80=99t you build replacemen= t library (or > object file) that you can use for the purposes of debug? Then remove this > later in production. > > >> >> 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? Turns out I just needed to set $rbp as well. However, this technique wouldn't restore the value of the registers. But those are printed by QEMU when it generates some exceptions like "Divide Error". So it should be possible to restore all the instructions that gdb allow me to access (unfortunately, very few special registers). >> >>> >>> 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=E2=80=9D? > > The structure of an exception handler is normally this: > > Entry: > Step 1: Save special registers. > Step 2: Establish *new* stack > Step 3: Possibly get an exception code or reason number (i.e.: IRQ umber= or > TRAP number) > Step 4: Call some handler function using the standard C calling protocol > Step 5: Cleanup after function call > Step 6: Go back to the original stack > Step 7: Restore special registers > Step 8: Perform the exception return instruction > > In your case, the =E2=80=9Csome handler=E2=80=9D is effectively a =E2=80= =9Cwhile(1) {}=E2=80=9D loop - (step > 4) and you have a breakpoint there. > > Your DIV0 or NULL POINTER access occurs and you hit the breakpoint >=20=09 > My earlier example the while() loop would become: > > 1: volatile int variable; > 2: some_handler(void) > 3: { > 4: variable =3D 1; > 5: while( variable !=3D 0 ){ } > 6: } > > In my example, I would set the variable to 0, then continue to step, > eventually I would step past line 6 and execute the function exit sequenc= e. Maybe the infinite loop in OVMF wasn't written in a facy way for nothing after all. VOID EFIAPI CpuDeadLoop ( VOID ) { volatile UINTN Index; for (Index =3D 0; Index =3D=3D 0;); } Index is volatile, so I should be able to apply your technique as well. I just tried and it works. Returning to the user code is just not as trivial as it could be. I guess I could just put a breakpoint on the iret instruction and automatically perform a "ni" command at that point. > > Important: Write the offending address down, and keep repeating the > experiment. Often you will see a common address or address range. > If you do find a pattern then set up the hardware rd/wr breakpoint on that > memory range. It is no exact science, and you might have to do this a few > times. Well, in QEMU, my bugs are usually very repeatable. Anyway, thanks for all the help. Best regards, Celelibi