From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id 00E323894428 for ; Mon, 17 May 2021 19:02:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 00E323894428 Received: from fencepost.gnu.org ([2001:470:142:3::e]:57672) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1liiV5-0006Mb-Dx for gdb@sourceware.org; Mon, 17 May 2021 15:01:59 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:33612) by fencepost.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1liiV4-0008Or-V3 for gdb@gnu.org; Mon, 17 May 2021 15:01:59 -0400 Received: from mail-ed1-x52c.google.com ([2a00:1450:4864:20::52c]:39892) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1liiV2-0006J5-Gj for gdb@gnu.org; Mon, 17 May 2021 15:01:58 -0400 Received: by mail-ed1-x52c.google.com with SMTP id h16so8162337edr.6 for ; Mon, 17 May 2021 12:01:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=VqhSl3VfGpLttd+fJjV0hbZDkOHjPTqBGXfw/MCo440=; b=XoNF+sw40ms1dLWLqhnZgqMu/a6ZZ5lHQEYQnZDZhZsb25U0hU0g+ggogrFj+DxkW1 8/vmDPKhWY6pbhUEdhZZ8c2gXCZd6XfznJvpwOqB86nC6L8R41D/s5nUsq5Gj5/ayhHs QV+L6+MupQqfIJdBYbQ4cMA2OoIkwJ2TbVT/jF6Bt5zQqd2FyrABQQUDmWEtJySezcqj 3+i5O87y/di8m7I8Y7SU0J1Wf6BawbmJiyokLS4y4IuD5mm6o91w4z5KHX8ATA+kxs9w zXzJYockyKOsY9Ex9ZT/WttrdRJQ18Bthpftgg/irS/FzAlv3daanoL6AaStL4z59VVz kDiA== X-Gm-Message-State: AOAM532jFe4cssixtG1sA9nHtQIzQ0dnCEGN3AM5yT6fdPHX4uazqJ5L nU7IG4V65zgtHCXG/J4Z/8WuORZsNv+PSa7dcqfxwyM+Kpk= X-Google-Smtp-Source: ABdhPJxnmQyGPIXR8sBs7XZJm84Z55PFde3HKdMerXMuocP53561QywAwgG+kdGgqMSdTE9gCMQAZK8eZFaGb8sNPvM= X-Received: by 2002:a05:6402:203c:: with SMTP id ay28mr1843905edb.100.1621278113054; Mon, 17 May 2021 12:01:53 -0700 (PDT) MIME-Version: 1.0 References: <87y2chjmsf.fsf@linaro.org> <6c8845b7-cc60-c8ba-3ada-6d0c6e65d8a5@linaro.org> <87bl99e03j.fsf@linaro.org> In-Reply-To: <87bl99e03j.fsf@linaro.org> From: Peter Maydell Date: Mon, 17 May 2021 20:01:37 +0100 Message-ID: Subject: Re: Best approach for supporting snapshots for QEMU's gdbstub? To: =?UTF-8?B?QWxleCBCZW5uw6ll?= Cc: Luis Machado , =?UTF-8?Q?Daniel_P=2E_Berrang=C3=A9?= , gdb@gnu.org, Pavel Dovgalyuk , QEMU Developers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=2a00:1450:4864:20::52c; envelope-from=peter.maydell@linaro.org; helo=mail-ed1-x52c.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, SPF_HELO_PASS, SPF_SOFTFAIL, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2021 19:02:02 -0000 On Mon, 17 May 2021 at 18:37, Alex Benn=C3=A9e wro= te: > Luis Machado writes: > > Right. We don't support reverse step/next/continue for remote targets. > > I think this would be the most appropriate way to implement this > > feature in GDB. But it is not trivial. > > You do because ";ReverseStep+;ReverseContinue+" is part of the gdbstub > negotiation handshake. > > Out of interest how is rr implemented? It presents a gdb interface so I > thought it was some implemented using some remote magic. AIUI rr just implements the reverse-step/reverse-continue parts of the gdb remote protocol. It makes them fast by internally to its implementation saying "ah, you wanted to do a reverse-step, I can do that by starting from the best available checkpoint and going forwards" and by automatically creating checkpoints at points that it thinks will be useful. gdb and the remote protocol know nothing about these checkpoints -- they are purely created and managed under the hood by rr as an optimisation so that reverse-step is decently fast. (Given that it's the rr end that knows best about what checkpoints are available, how expensive it is to create a checkpoint, etc, that seems not unreasonable.) There are also a handful of rr-specific gdb commands kind of like the QEMU-specific ones, which the user can use to say things like "go directly to this point in time T" which the gdb UI doesn't have a concept of. (Also because rr starts the gdb for you it gets a chance to feed it a few gdb macro definitions which I think mostly just make the debugging experience a bit smoother rather than being critical parts of the gdb-to-stub communication.) thanks -- PMM