From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13909 invoked by alias); 23 Apr 2018 01:37:58 -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 13889 invoked by uid 89); 23 Apr 2018 01:37:57 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy=H*r:10.0.0, pc, coredumps, H*Ad:D*ca X-HELO: simark.ca Received: from simark.ca (HELO simark.ca) (158.69.221.121) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 23 Apr 2018 01:37:55 +0000 Received: from [10.0.0.11] (unknown [192.222.164.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 790D81E4F4; Sun, 22 Apr 2018 21:37:53 -0400 (EDT) Subject: Re: [Qemu-devel] [PATCH] scripts/qemugdb: support coroutine backtrace in coredumps To: Stefan Hajnoczi , Vladimir Sementsov-Ogievskiy Cc: Stefan Hajnoczi , qemu-devel@nongnu.org, gdb@sourceware.org References: <20180404103440.19546-1-stefanha@redhat.com> <008ac6e8-1e68-b0f6-7e75-77453721d031@virtuozzo.com> <20180410020823.GB11203@stefanha-x1.localdomain> From: Simon Marchi Message-ID: Date: Mon, 23 Apr 2018 09:33:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20180410020823.GB11203@stefanha-x1.localdomain> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2018-04/txt/msg00017.txt.bz2 On 2018-04-09 10:08 PM, Stefan Hajnoczi wrote: > I wonder what the point of select-frame is then... > > I have CCed the GDB mailing list. Maybe someone can help us. Context: > > QEMU implements coroutines using jmpbuf. We'd like to print coroutine > call stacks in GDB and have a script that works when a process is being > debugged (it sets the registers). > > Now we'd like to extend the script to work on core dumps where it's not > possible to set registers (since there is no process being debugged). > > Is there a way to backtrace an arbitrary call stack in a core dump? Not that I know of. The "frame " form of the frame command sounds like it should be usable to achieve that, but it doesn't seem to work in that way. I really wonder if it's working as it was intended initially. I guess using that form of the frame command should override/mask the real current values of $sp and $pc? Simon