From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 38370 invoked by alias); 1 Dec 2015 08:57:33 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 38350 invoked by uid 89); 1 Dec 2015 08:57:32 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-lf0-f48.google.com Received: from mail-lf0-f48.google.com (HELO mail-lf0-f48.google.com) (209.85.215.48) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Tue, 01 Dec 2015 08:57:31 +0000 Received: by lfdl133 with SMTP id l133so229736146lfd.2 for ; Tue, 01 Dec 2015 00:57:27 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.25.156.73 with SMTP id f70mr27193644lfe.70.1448960247450; Tue, 01 Dec 2015 00:57:27 -0800 (PST) Received: by 10.25.197.5 with HTTP; Tue, 1 Dec 2015 00:57:27 -0800 (PST) In-Reply-To: References: Date: Tue, 01 Dec 2015 08:57:00 -0000 Message-ID: Subject: Re: Tracing another stack From: Celelibi To: Sterling Augustine Cc: gdb@sourceware.org Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-12/txt/msg00001.txt.bz2 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 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