This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Tracing another stack
- From: Duane Ellis <duane at duaneellis dot com>
- To: Celelibi <celelibi at gmail dot com>
- Cc: gdb at sourceware dot org
- Date: Sat, 28 Nov 2015 05:37:23 -0800
- Subject: Re: Tracing another stack
- Authentication-results: sourceware.org; auth=none
- References: <CAJR2zJ_jwB14bPsMO_Gf661Atj+8GXncGX7dnEDLDhm3RN3Q3g at mail dot gmail dot com>
> On Nov 27, 2015, at 10:01 PM, Celelibi <celelibi@gmail.com> 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?)
What I do in these situations is this:
Step 1: I create a global âvolatileâ 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 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 exception handler return to the PREV or NEXT instruction instead of the instruction that failed
At that point you have the location where the error occurs.
Another approach is this:
If you know the offending addressâ you can often set a hardware *read* or *write* breakpoint on that location
-Duane