Re: Tracing another stack

[Celelibi <celelibi at gmail dot com>]

2015-11-28 14:37 UTC+01:00, Duane Ellis <duane@duaneellis.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?)

My target is x86_64 with OVMF as UEFI firmware.


>
> 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

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â 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