From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id nfEZFbnqHWpsTC4AWB0awg (envelope-from ) for ; Mon, 01 Jun 2026 16:25:29 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=DrSY+O7j; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 32F2B1E0A3; Mon, 01 Jun 2026 16:25:29 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HTML_MESSAGE, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED, RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [38.145.34.32]) (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 04CC01E024 for ; Mon, 01 Jun 2026 16:25:28 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 41C584BA2E23 for ; Mon, 1 Jun 2026 20:25:27 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 41C584BA2E23 Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=DrSY+O7j Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTP id EDAD94BA2E0D for ; Mon, 1 Jun 2026 20:24:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org EDAD94BA2E0D Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org EDAD94BA2E0D Authentication-Results: sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1780345500; cv=none; b=G+BU+Rg+kBe0XByLWZYAJZR+kuxSPV0qMCRZuIQwEOKWkSD1eFTS2T8KyNeh7L+HtaOc+w4hgE7iGIooXmxJn5EpTqQl+chJPhtgA3MWGhxYZKLf6nrHTBwGvMeIporA21AIYGJXD9rzfJO12QlAKzQNztP9ybOfW6cEyCClrNU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1780345500; c=relaxed/simple; bh=2TnO7FTv7DCrjzDYpizc1oo05FhdlRXXYIPeu9ZQP+E=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=pBHXE0E1EPcknw0Yq6YEJ8JiVLskVCGRSG028pXAUj939/oZvtdRqQRkEtDM7RvXhPRK1Os9oD1eiKkzowxDdf4Z3yjK5+nm20QpAQ1RD3C16rPEwuiq6IGBuRsmw2Tg5rZftR+9rMSVKRuXPd6Ld8OWlaCbH8Kt+CDgLz3g2NU= ARC-Authentication-Results: i=1; sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=DrSY+O7j DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org EDAD94BA2E0D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1780345499; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=PDTuobRdrKwuiujCrCqyA/fIHcQ6dmuRokGMXbLuz9M=; b=DrSY+O7j91UBE4eEj129RimOJvhkcLMgt4GrTz0PdeliP0OtQXUPxGPwPtvstJCMZhmfvA pol7jFxw4x6R/kk1gcZC8WXLeZscXGLO8WLCAR9H8p3viMA2E8vnr3bdgSVD71+sLeEjoa uC3qEUejD6iIqHoL7Z9zJP94Agsz0uA= Received: from mail-dy1-f199.google.com (mail-dy1-f199.google.com [74.125.82.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-628-8TSIAxupMQiTu0NEbWbuXQ-1; Mon, 01 Jun 2026 16:24:57 -0400 X-MC-Unique: 8TSIAxupMQiTu0NEbWbuXQ-1 X-Mimecast-MFC-AGG-ID: 8TSIAxupMQiTu0NEbWbuXQ_1780345496 Received: by mail-dy1-f199.google.com with SMTP id 5a478bee46e88-3041ab826ddso18084675eec.0 for ; Mon, 01 Jun 2026 13:24:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780345496; x=1780950296; h=in-reply-to:from:content-language:references:to:subject:user-agent :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=PDTuobRdrKwuiujCrCqyA/fIHcQ6dmuRokGMXbLuz9M=; b=MZ/mmSSdm3n1CQSQSKh/EO3RZcwBdhSmyLiCGG+ljfOmtKCEDE8Xig5aafloe/MrcA HVkfvgntKeOmUoA51AOF5EaBpvlXjYSmlgsjac+dGECV0uYM1l3rQ8qRXq0OKltS7X4R tyaN4wbsEk+LJJ6DFAu3h0Wq9OhcqI1sTblte9k/mZviU2HUWunOUhbwF4WAWL02NMqf K8SHrkZlTPEWwKlGrGCPJON24PKLvHR/8nZKIhwoC+BKBPzOPsPlj5klMvnYRTR5CGbV B5CCPKxzQg+oX3luv7ztBYkv5xwoJai4HvPIOtc6cvcA6FJsM2fIR5EAQaqULgkNcKiW CswQ== X-Forwarded-Encrypted: i=1; AFNElJ8laej4IZoGBxWssoIoNC6MjuTaju8GpsPc9rNJN7ClaAWoUhNWgYZ8MzOGc+6jGC148Fz4/nsZTdIKtw==@sourceware.org X-Gm-Message-State: AOJu0YyGPVhF0WHcrgNOisT1SJqfq9IR23SHsa2rD30vxL/H1fgoOcou 8vGifUTDahXE1B6woUbKwYXEU+lnVhtkH4L/W+02Ox5S70x5V8iq+rBw4Yz+Wt2yvAJ6jnk8x06 IJEhTnR6QW+YSxAguGFgj8TrNH66DiGSAEc7tV3kTzoLLmoLwH2xT0NuhpYpQPXd1luAH9f4= X-Gm-Gg: Acq92OGBd6zNTZRZLAb1xKgySb0+Od3aCSi+lBST/awbA3haekvRkjvIY0pMRVvoIOw nbtaIBQI3p1CYfoGJiOqFjpZHK/FcXxSxKCMVrGj1nW49VNklW1Tfr8sDY7QDBa8OKYaoUyx4Oi DDLBpdPjMAwIOQpFicnC+JrvmaAyhwtqJH7Vpuc12tkZ9LOn8mtOpRbOUdCZmjYC3QWX9BhwLWK utqHqTXcb8E+rMscB7Bsx0XHFcARhmh+cUsa57/zbBs7KIHCb854xNskFmWRZoW6mEwCXNY2E6C kuBWlLVGv3HQFqnBZUvLDTYsyWM8Vi01TbHeOkbJM5cVhwkOy3YWGgMdz6NUYZKN93poKsy+QRB K0RQyi0oySDNC8AW055gww+waNzCNhf+v7W9oPWxy/mRG8jeoakCSLfI99/Twh6UqCqAPL+i9iU Rf3zA= X-Received: by 2002:a05:7300:3b05:b0:2f2:6dde:df50 with SMTP id 5a478bee46e88-304fa5eeb23mr6205950eec.17.1780345496144; Mon, 01 Jun 2026 13:24:56 -0700 (PDT) X-Received: by 2002:a05:7300:3b05:b0:2f2:6dde:df50 with SMTP id 5a478bee46e88-304fa5eeb23mr6205930eec.17.1780345495522; Mon, 01 Jun 2026 13:24:55 -0700 (PDT) Received: from ?IPV6:2804:14d:8084:993e:2d5d:7adb:2b6:a50e? ([2804:14d:8084:993e:2d5d:7adb:2b6:a50e]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-304ed2c120csm9932108eec.4.2026.06.01.13.24.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Jun 2026 13:24:55 -0700 (PDT) Message-ID: Date: Mon, 1 Jun 2026 17:24:51 -0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 5/7] gdb/record: extract the PC to record_full_instruction To: "Schimpe, Christina" , "gdb-patches@sourceware.org" References: <20260515163706.3355686-1-guinevere@redhat.com> <20260515163706.3355686-7-guinevere@redhat.com> From: Guinevere Larsen In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: J2ogXrBfQ5sS2PIBohe85IqwqxN42JjhCmvIWCzWRms_1780345496 X-Mimecast-Originator: redhat.com Content-Type: multipart/alternative; boundary="------------a5ilF9hTiGc0yZmIGDR61Nna" Content-Language: en-US X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org This is a multi-part message in MIME format. --------------a5ilF9hTiGc0yZmIGDR61Nna Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 5/29/26 9:40 AM, Schimpe, Christina wrote: >> -----Original Message----- >> From: Guinevere Larsen >> Sent: Freitag, 15. Mai 2026 18:37 >> To:gdb-patches@sourceware.org >> Cc: Guinevere Larsen >> Subject: [PATCH v3 5/7] gdb/record: extract the PC to record_full_instruction >> >> This commit makes it so the PC is not saved as part of the >> record_full_instruction effects, but rather gets a special location. >> That is because a couple of commands would really benefit from it being easy >> to find the PC (especially ones from record-btrace that's haven't been >> implemented to record-full yet, such as the ones in PR record/18059), while >> also possibly allowing for one fewer resizing of the effect vector (and saving >> an entire byte in the process). >> >> This commit also refactored record_full_read_entry_from_bfd and >> record_full_write_entry_to_bfd, to make them methods of >> record_full_reg_entry and record_full_mem_entry, and also creates similar >> methods for record_full_entry and record_full_instruction. >> These could be turned into constructors in a future step of >> c++ification, but it felt like too much change for a single commit. >> --- >> gdb/record-full.c | 386 ++++++++++++++++++++++++++++------------------ >> 1 file changed, 239 insertions(+), 147 deletions(-) >> >> diff --git a/gdb/record-full.c b/gdb/record-full.c index >> 8cabd6e9438..17696e07c0d 100644 >> --- a/gdb/record-full.c >> +++ b/gdb/record-full.c >> @@ -143,6 +143,14 @@ struct record_full_mem_entry >> >> DISABLE_COPY_AND_ASSIGN (record_full_mem_entry); >> >> + /* Create a mem_entry from a bfd file, when restoring a recording. >> +*/ >> + static record_full_mem_entry from_bfd (bfd*cbfd, asection* osec, >> + int *bfd_offset); >> + >> + /* Save this mem entry to a bfd file. */ >> + void to_bfd (gdb_bfd_ref_ptr obfd, asection *osec, int *bfd_offset, >> + gdbarch *gdbarch); >> + > I believe only in one of those to_bfd functions the gdbarch parameter is used. > Did you intentionally keep it the function which don't have use the parameter in to_bfd ? Fixed. I didn't keep it intentionally. > > And it might be a good idea to describe the parameters a bit, too. 😊 I would love to describe the parameters, but to be fair, I only know what the self-explanatory ones do lol. No idea what the section is used for, and the bfd_ref_ptr is the ref-counted pointer to the BFD file... -- Cheers, Guinevere Larsen It/she --------------a5ilF9hTiGc0yZmIGDR61Nna Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 5/29/26 9:40 AM, Schimpe, Christina wrote:
-----Original Message-----
From: Guinevere Larsen <guinevere@redhat.com>
Sent: Freitag, 15. Mai 2026 18:37
To: gdb-patches@sourceware.org
Cc: Guinevere Larsen <guinevere@redhat.com>
Subject: [PATCH v3 5/7] gdb/record: extract the PC to record_full_instruction

This commit makes it so the PC is not saved as part of the
record_full_instruction effects, but rather gets a special location.
That is because a couple of commands would really benefit from it being easy
to find the PC (especially ones from record-btrace that's haven't been
implemented to record-full yet, such as the ones in PR record/18059), while
also possibly allowing for one fewer resizing of the effect vector (and saving
an entire byte in the process).

This commit also refactored record_full_read_entry_from_bfd and
record_full_write_entry_to_bfd, to make them methods of
record_full_reg_entry and record_full_mem_entry, and also creates similar
methods for record_full_entry and record_full_instruction.
These could be turned into constructors in a future step of
c++ification, but it felt like too much change for a single commit.
---
 gdb/record-full.c | 386 ++++++++++++++++++++++++++++------------------
 1 file changed, 239 insertions(+), 147 deletions(-)

diff --git a/gdb/record-full.c b/gdb/record-full.c index
8cabd6e9438..17696e07c0d 100644
--- a/gdb/record-full.c
+++ b/gdb/record-full.c
@@ -143,6 +143,14 @@ struct record_full_mem_entry

   DISABLE_COPY_AND_ASSIGN (record_full_mem_entry);

+  /* Create a mem_entry from a bfd file, when restoring a recording.
+*/
+  static record_full_mem_entry from_bfd (bfd *cbfd, asection* osec,
+					 int *bfd_offset);
+
+  /* Save this mem entry to a bfd file.  */
+  void to_bfd (gdb_bfd_ref_ptr obfd, asection *osec, int *bfd_offset,
+	       gdbarch *gdbarch);
+

I believe only in one of those to_bfd functions the gdbarch parameter is used.
Did you intentionally keep it the function which don't have use the parameter in to_bfd ?
Fixed. I didn't keep it intentionally. 

And it might be a good idea to describe the parameters a bit, too. 😊

I would love to describe the parameters, but to be fair, I only know what the self-explanatory ones do lol. No idea what the section is used for, and the bfd_ref_ptr is the ref-counted pointer to the BFD file...

-- 
Cheers,
Guinevere Larsen
It/she
--------------a5ilF9hTiGc0yZmIGDR61Nna--