Tracing another stack

Tue Dec 1 08:57:00 GMT 2015

2015-11-30 17:27 UTC+01:00, Sterling Augustine <>:
> On Fri, Nov 27, 2015 at 10:01 PM, Celelibi <> 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

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,

More information about the Gdb mailing list