From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-44842-listarch-gdb=sources.redhat.com@sourceware.org>
Received: (qmail 63172 invoked by alias); 30 Nov 2015 16:28:35 -0000
Mailing-List: contact gdb-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb.sourceware.org>
List-Subscribe: <mailto:gdb-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb/>
List-Post: <mailto:gdb@sourceware.org>
List-Help: <mailto:gdb-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-owner@sourceware.org
Received: (qmail 62015 invoked by uid 89); 30 Nov 2015 16:28:35 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2
X-HELO: mail-ob0-f175.google.com
Received: from mail-ob0-f175.google.com (HELO mail-ob0-f175.google.com) (209.85.214.175) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Mon, 30 Nov 2015 16:28:34 +0000
Received: by obdgf3 with SMTP id gf3so132536367obd.3        for <gdb@sourceware.org>; Mon, 30 Nov 2015 08:28:32 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;        d=1e100.net; s=20130820;        h=x-gm-message-state:mime-version:in-reply-to:references:date         :message-id:subject:from:to:cc:content-type;        bh=HWYxXHyGvl029EEel0r8qHmX3X4BRoXg2FrcIn0pqMM=;        b=LNd6A6FgjbDDPsh0xqPRsAk1hUNYHl5Wth1zto7NdDQBo8fKUY3WI41bouU3BaU9/s         SidSusY4W8xaJB8uQ+zKYpa9wM8SrrR1XXA1dK1BKrCfB7OEig4qxHr3CIoIpFY9cwde         9lk03VV0X6VqiJe9M6R1sAFzgdiYZm/sYiD00gl+ya/OU5W/HHG1/3k3CPr8RufI6Omm         KeHxDNzrN7xQf8602KU5ebJJZffkJMG0KiPc1eu1MIkGfxltjJ0KXEJBVa1MN7/Yt7wp         Yw4t6PUjmEA6D8rkOWHiqG1H9o38SRZiqvaws3oC7L6s5ysvq6PYyg6mhV8hIkCm6MBz         YGCQ==
X-Gm-Message-State: ALoCoQnU48GA9+fRrZf6EWRgfc3c1BeOZ7PM8Hvi2AHDfVvOMUUowwj6vmZiFzaeA/6Eg+P2HuS1
MIME-Version: 1.0
X-Received: by 10.182.251.170 with SMTP id zl10mr43929909obc.8.1448900912081; Mon, 30 Nov 2015 08:28:32 -0800 (PST)
Received: by 10.202.240.193 with HTTP; Mon, 30 Nov 2015 08:28:32 -0800 (PST)
In-Reply-To: <CAJR2zJ_jwB14bPsMO_Gf661Atj+8GXncGX7dnEDLDhm3RN3Q3g@mail.gmail.com>
References: <CAJR2zJ_jwB14bPsMO_Gf661Atj+8GXncGX7dnEDLDhm3RN3Q3g@mail.gmail.com>
Date: Mon, 30 Nov 2015 16:28:00 -0000
Message-ID: <CAEG7qUxOeJZVDPzpcbsp0dVu_3mWsxxTA-6jKkZY5avszWBDcA@mail.gmail.com>
Subject: Re: Tracing another stack
From: Sterling Augustine <saugustine@google.com>
To: Celelibi <celelibi@gmail.com>
Cc: gdb@sourceware.org
Content-Type: text/plain; charset=UTF-8
X-IsSubscribed: yes
X-SW-Source: 2015-11/txt/msg00047.txt.bz2

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.