From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id qrMHIll1lmYQbCgAWB0awg (envelope-from ) for ; Tue, 16 Jul 2024 09:27:53 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=TJVaOWWy; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 7C8091E097; Tue, 16 Jul 2024 09:27:53 -0400 (EDT) Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 61FAF1E097 for ; Tue, 16 Jul 2024 09:27:51 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id B5B99384A077 for ; Tue, 16 Jul 2024 13:27:50 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B5B99384A077 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1721136470; bh=te8i7tD9idzUSFHAV0LmJsvrEgJ9hIX8S9B3t/1tygY=; h=Date:Subject:To:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=TJVaOWWyCcCLVyFaA9hGOebjnD4FWaJxlheWQwwqBwZGPro4UJsB5pLU0/IsIEs+E 1bUfnLUtLee8mD3CM14aLz2/kG+9qFREWBheGY2pJ7oMVZ/Qi1xuTELHzPdJQGHZO0 aBdcDRb48whUmlOMz/U1lN3T6ikIEdea9tkOoS2k= Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id BA80E384A407 for ; Tue, 16 Jul 2024 13:27:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BA80E384A407 ARC-Filter: OpenARC Filter v1.0.0 sourceware.org BA80E384A407 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1721136433; cv=none; b=g1qTymKupydKvpwULQZrlgZhfJb5DPk3KS/9atYoNs64cIwJ5GCGLMKHgoFyeTI/vJgXCD0gC+B4BIKj6cIzq3O07bz9ecFb9DGVj3XTnN0hYaSxfy5bwQZ369Ed72Ov0sGtbrlj/Uhgsk3yRwW+VYq3QqeYTrm+u6+TWrnokzU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1721136433; c=relaxed/simple; bh=MeOTYt/sPAQsXr3dWZhG9Y6H12XoKQ05Jbbkon0XiBM=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=JiXf9raFfJo0xNaZp6SAFAg/DZ0GdsE0uLDClyWBGsijSc4C1SDluIwpJ7j0k8Q3LCWTDY0Njyoh1TfdjL8TIxjfB5Xx0dBl85MO/NUCqs24HMrLQuKf9jyd8YF9CKdFGG67FurkQfLfTL21OojkFxIlvkvklpuJqLQzSwTjzZw= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from mail-qt1-f198.google.com (mail-qt1-f198.google.com [209.85.160.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-606-wLNDfULwMHez8qzd4cjg9g-1; Tue, 16 Jul 2024 09:27:09 -0400 X-MC-Unique: wLNDfULwMHez8qzd4cjg9g-1 Received: by mail-qt1-f198.google.com with SMTP id d75a77b69052e-44e0507a7ddso66615591cf.2 for ; Tue, 16 Jul 2024 06:27:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721136429; x=1721741229; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=te8i7tD9idzUSFHAV0LmJsvrEgJ9hIX8S9B3t/1tygY=; b=MBTCYy+gtMDn9vj/ksXoYcnV2vTaVvU/HXVOp4ZgPPHXWbzcFbT5gbZwRDbBUkIGQ9 FutFcT3HxvM1S/4peRByj5VuDx/brfcV6QUN8G/v0YltNsT1z4W6IvbxB860E4tLrxlZ MrmYTDwrknmmzOBXenq4TBm5/l/mCUDktoJQAC+YRXP1D37BQ+kd7UuV6abkNiBW2Yew hdXzqrXZt7VE5ri5NZxXvGpd9+7si1ggLSn/jUQcOeRCb6z5f8ieo6qnTZ6BFRPbQ3Ja YtGbzEU2zLUk6kKTKFn0uAkw0Hcge/ev1lhpOGWhiBHJKRtj0Caz0tPMEa3UEtrFW7qJ F0/A== X-Forwarded-Encrypted: i=1; AJvYcCVvFM4pe3zB5FOnPW3qrEkzrCHsV9P14PQ/ZdNBUNFVUzBOnEM08FIgJKEYwbcoklPewONEc34uGAYzt1D4Maip0JA= X-Gm-Message-State: AOJu0YxFSTQ14j1i8YpLRA+q2RoghjinhKSzF83KRQcGKfMWt/9sm5K6 Gr7xFyb6dyvcxBQqB9Z5ytJx+YoyQihtQCydCYidJe94A4/zlxCZHbqH+EEnNEaOph8ioGlGBSa YwVfuM8dxWv1hjY0leZMNV85jP9jBVkeROqqBc8KwlxCbPvCPTOa16acr X-Received: by 2002:ac8:5807:0:b0:447:e2f0:64db with SMTP id d75a77b69052e-44f7ad20ab3mr30790091cf.57.1721136429128; Tue, 16 Jul 2024 06:27:09 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEMO31UWz9wXYpWc0jHKsJVqF1JBwe3sJ/EctRS74zy4xFfYayxK8H413UebJJTsxlYSbayyg== X-Received: by 2002:ac8:5807:0:b0:447:e2f0:64db with SMTP id d75a77b69052e-44f7ad20ab3mr30789841cf.57.1721136428744; Tue, 16 Jul 2024 06:27:08 -0700 (PDT) Received: from ?IPV6:2804:14d:8084:92c5::1001? ([2804:14d:8084:92c5::1001]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-44f5b7e00a7sm35100051cf.26.2024.07.16.06.27.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 16 Jul 2024 06:27:08 -0700 (PDT) Message-ID: <5462c674-7a07-4cbf-b43b-19cdd1058bb7@redhat.com> Date: Tue, 16 Jul 2024 10:27:06 -0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Wondering if record save should be deprecated To: Luis Machado , "gdb@sourceware.org" References: <3efbc686-a7ec-4699-85ba-b96ea4ec2bad@redhat.com> In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.3 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Guinevere Larsen via Gdb Reply-To: Guinevere Larsen Errors-To: gdb-bounces~public-inbox=simark.ca@sourceware.org Sender: "Gdb" On 7/16/24 9:24 AM, Luis Machado wrote: > On 7/10/24 20:58, Guinevere Larsen via Gdb wrote: >> Hi everyone! >> >> I decided to try a bit of a different workflow for reverse debugging and noticed that using "record save", then loading that file in a new gdb session, and I noticed this generated an assert. The assert itself is not too hard to solve (Hannes had a patch ready when I mentioned it in IRC), but it had me wondering: this bug is present since GDB 10, and there are no bugs in bugzilla about it. >> >> In fact, searching for "record save" only has a stack overflow question from 2.5 years ago that uses precsave, but is about a separate topic. Everything else, including the few reverse debugging tutorials I've seen, never mention this option. >> >> Does it make sense for us to continue supporting this feature that was nigh unusable for 5 releases without anyone noticing? Does anyone reading this makes use of this feature and managed to somehow avoid that crash? >> > If it is easy enough to fix, sounds like that is the way then. As for whether people are using this, > it is hard to tell. I've been hearing more and more about people using RR for their > reverse debugging needs. Does it also save state? > Yes. RR has 2 completely separate phases, one recording the execution of the inferior, and another opening a gdbserver that uses that recording for execution. So it's not like GDB is the only way to get a recording of a broken execution to be debugged later. The difference is that with RR you decide at the start that you want to record things, and with GDB you can decide mid-debugging session. And that RR only works for a few x86_64 CPUs, while GDB supports many more. I've been convinced, let's keep it :) -- Cheers, Guinevere Larsen She/Her/Hers