This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Tracing another stack
- From: Sterling Augustine <saugustine at google dot com>
- To: Celelibi <celelibi at gmail dot com>
- Cc: gdb at sourceware dot org
- Date: Mon, 30 Nov 2015 08:28:32 -0800
- Subject: Re: Tracing another stack
- Authentication-results: sourceware.org; auth=none
- References: <CAJR2zJ_jwB14bPsMO_Gf661Atj+8GXncGX7dnEDLDhm3RN3Q3g at mail dot gmail dot 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.