Re: Tracing another stack

> On Nov 27, 2015, at 10:01 PM, Celelibi <[email protected]> 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