Re: Tracing another stack

[Celelibi <celelibi@gmail.com>]

2015-11-30 17:27 UTC+01:00, Sterling Augustine <saugustine@google.com>:
> On Fri, 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.
>>
>
> If you have a reasonably mature gdb-stub, you can use the following
> commands:
>
> # print a list of all threads known to gdb, with numbers
> info threads
>
> # switch to a thread numbered X from the above list
> thread X
>
> You can now get the back trace for that particular thread with "bt"
>
> You could also do:
>
> thread apply all backtrace
>
> To get a back trace of every thread.
>
> This may not work with certain immature stubs, but it should work with
> most.
>

Well, I think you missed 2 important informations. The stub I use is
that of qemu, its threads are mapped to the CPUs available. Second,
there is a single thread, the new stack is created by an interrupt
handler.

Having a single thread isn't incompatible with having several stacks.
Asynchronous events can run some code in a new and completely
different stack designed specifically for event handlers. AFAIK,
signal handlers in Linux can use a specific stack with the SA_ONSTACK
option of sigaction(2).


Best regards,
Celelibi