From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 87054 invoked by alias); 27 Dec 2018 17:36:15 -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 86988 invoked by uid 89); 27 Dec 2018 17:36:11 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy=backed, comfortable, we'd, initially X-HELO: EUR02-AM5-obe.outbound.protection.outlook.com Received: from mail-eopbgr00131.outbound.protection.outlook.com (HELO EUR02-AM5-obe.outbound.protection.outlook.com) (40.107.0.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 27 Dec 2018 17:36:08 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuozzo.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=C1R6Xt266xv8jDqxloE3PPk3PJ7cPlfclFPDtfWU5so=; b=Nx+M2AuKtxa2B/itrr0wB01F9IpluLvfexfO+eRKEFmYSk0XcRn8pSXTlYolzKJWXhyHlhWrammnIcZMk6TWOx4qvC0zIhxCqwrWViWYpV/twGsNn+DjqcL9Ie6xEIE89pCv/kmOOC6uRmRoN6XgJr3+FLGrm6/vDLKrRGbNtt8= Received: from DB7PR08MB3851.eurprd08.prod.outlook.com (20.178.46.222) by DB7PR08MB3532.eurprd08.prod.outlook.com (20.177.120.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1471.20; Thu, 27 Dec 2018 17:36:04 +0000 Received: from DB7PR08MB3851.eurprd08.prod.outlook.com ([fe80::e5db:cc9f:95ac:87c5]) by DB7PR08MB3851.eurprd08.prod.outlook.com ([fe80::e5db:cc9f:95ac:87c5%3]) with mapi id 15.20.1471.019; Thu, 27 Dec 2018 17:36:04 +0000 From: Vladimir Sementsov-Ogievskiy To: Pedro Alves , Simon Marchi , Stefan Hajnoczi CC: Stefan Hajnoczi , "qemu-devel@nongnu.org" , "gdb@sourceware.org" Subject: Re: [Qemu-devel] [PATCH] scripts/qemugdb: support coroutine backtrace in coredumps Date: Thu, 27 Dec 2018 17:36:00 -0000 Message-ID: <0ebf0044-d45c-74b4-d323-2391daa12a0c@virtuozzo.com> References: <20180404103440.19546-1-stefanha@redhat.com> <008ac6e8-1e68-b0f6-7e75-77453721d031@virtuozzo.com> <20180410020823.GB11203@stefanha-x1.localdomain> <788e662d-0fb6-8db8-a049-3714eaa32869@redhat.com> In-Reply-To: <788e662d-0fb6-8db8-a049-3714eaa32869@redhat.com> authentication-results: spf=none (sender IP is ) smtp.mailfrom=vsementsov@virtuozzo.com; received-spf: None (protection.outlook.com: virtuozzo.com does not designate permitted sender hosts) Content-Type: text/plain; charset="Windows-1252" Content-ID: <1B18244572BFC34F85B3525F6CAC1307@eurprd08.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-SW-Source: 2018-12/txt/msg00017.txt.bz2 23.04.2018 16:28, Pedro Alves wrote: > On 04/23/2018 02:37 AM, Simon Marchi wrote: >> 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? >=20 > Yeah, "frame " has a lot of problems. >=20 > This series was working toward sorting out the "frame" command: >=20 > https://sourceware.org/ml/gdb-patches/2015-09/msg00248.html >=20 > Follow the urls there for more background. >=20 > To me, the important questions to answer are here: > https://sourceware.org/ml/gdb-patches/2015-09/msg00658.html >=20 > Unfortunately, I don't think the series moved past that point. >=20 > Thanks, > Pedro Alves >=20 Hi Pedro! Hmm, returned to this topic. I've spent this day digging in gdb code, and f= ound it much more difficult than qemu).. I've failed to find something like create_frame_with_registers, or create_thread_with_registers.. Looks like r= egisters comes from some register caches, backed by different sources of registers or some= thing like this. So, I'd like to ask several questions: 1. Any news on the topic since April? 2. Can you propose a simple (maybe hacky) way (with or without patching gdb= ) to achieve the behavior like set $rsp =3D ... set $rbp =3D ... set $rip =3D ... bt #prints bt, starting from the frame corresponding to register values set fr 5 #goes to frame in this bt, and allow to examine local variables for debugging core-dumps? *** May be, we can allow set registers while debugging core-dump? Why we can't = set them? We have same register caches, and anyway we can move between threads and frames and= registers are changed... May be, we can somehow add separate thread with given registers from user, = like they are created from coredump file.. Anything else? *** For me, still, the simplest way is to add additional note segments to cored= ump file, to specify needed frames.. But it is not very comfortable, to recreate and reopen core file, when foun= d new coroutine. --=20 Best regards, Vladimir