From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id +RZKEI+SPWqNTBgAWB0awg (envelope-from ) for ; Thu, 25 Jun 2026 16:41:51 -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=VoGHrpNO; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 3D8F41E070; Thu, 25 Jun 2026 16:41:51 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-6.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 autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [IPv6:2620:52:6:3111::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 2CDEF1E070 for ; Thu, 25 Jun 2026 16:41:50 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 404A54BA23D2 for ; Thu, 25 Jun 2026 20:41:49 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 404A54BA23D2 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=VoGHrpNO 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 227754BA2E25 for ; Thu, 25 Jun 2026 20:41:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 227754BA2E25 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 227754BA2E25 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=1782420079; cv=none; b=j2rI7urNA1WI73V0KSdpg/B6QkF2aHkE2nSSQHb5d0+DXrB5QCiGNBSn0f1qMHzTIT04gnXi4iukElb7G4CSaPEfFChPLMWI73gcnk7UoYac+9GTxfUSGeFSVrgOHZbVBd23siUiEE3m7tSenvp0NiV05NyOP+e8Bx8iPURfU3E= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1782420079; c=relaxed/simple; bh=w4cemuiop2UE7od6LSf1VqXFHfAv38NIiiWnSpjnZVE=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=K/yhm9Oxd2kw4uVpjSBJ6u5RWijT90sqcZMSerOn+VoSOZI0V8e60gy0u5v+lV5wiUzacgai4HO5vQQuo7zXF08kNXy+BgdNGh/dBOzm32D5vMKHA9bLUWvpXD/HuXZxK9jhUuaoDkQulNZGH55jiIWBVgSaj4dg2IGsDRDZSoo= 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=VoGHrpNO DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 227754BA2E25 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1782420078; 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=p4+A2Wt+QXDrj3m8gFaZH7we1LAlsBf8yyHXs/0MrWI=; b=VoGHrpNODieBQdfPLkjdC2vYQTu+QJrZ/Nr5O5Vyr6qKW9HyVP6xcMNExy/oLb3jw0kHGw uBZ1c/dkHdJGlgs+rm6zHMc/mVfGoG/gIVZ2WcOcuU6ozHjpt+UyNUKyw4Cl26Er2+Vh0w kz46gCorjtl+k6eO+ZegZYI6N5Sqxlo= Received: from mail-vk1-f198.google.com (mail-vk1-f198.google.com [209.85.221.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-628-PP5Ty0IOPHeKQBgDrRnm2w-1; Thu, 25 Jun 2026 16:41:17 -0400 X-MC-Unique: PP5Ty0IOPHeKQBgDrRnm2w-1 X-Mimecast-MFC-AGG-ID: PP5Ty0IOPHeKQBgDrRnm2w_1782420076 Received: by mail-vk1-f198.google.com with SMTP id 71dfb90a1353d-59ebf602dbcso156825e0c.2 for ; Thu, 25 Jun 2026 13:41:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782420076; x=1783024876; 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=4YUOsHqdCmQ78OB/Vc54FBLqWIE0E1tfIYxxFWtlvBw=; b=apiwqT9IkUWEk6c2VkXrfiSnhh1T9ztwH0+sAsebChm1UpEhBOqnfz3Tsfsa89lvyv sl3gZ2N0P2kgH/bZH4ssOR2QeDB+ZIL9IHiKKLjH3Jt2FgoiqnEcWCkSB1zzUUIQvkeW aocUVlYIxwAqUpcswR444rdcqkWPPJFDfa8VuTfLwCZ24jNpqVRSnfhoEx30jcr7jVa9 6sAvvPOQ5QRdbRoc9+07Ll5KAh6HpeZ3qQ8zYCpQyow/7cSXo/sQu7vo5EPDIbBEwr6Q f8bxRnL5Wm/2s+2/QXhZDtXUqGdlMgc9o68DQVvZrPJZxya1tavj6CVvJfiJzT0tTxd7 4iQQ== X-Forwarded-Encrypted: i=1; AHgh+RoSY9bsFj0chxjJG+KPZaw1AWszVObDgFmu/jHFE4ywdr3yFF25jstlCkKN1jaFsgsXuHgo/9K3nXuyzg==@sourceware.org X-Gm-Message-State: AOJu0Yyeql4HeIyJZMKpeopzaPV5zUzhAyN4q8qUP4uIf9i5BEZ/cjXT +4BZzY/zUXXVnzeANth1Gx/uUaMwwQqJEY6k2fAk4Ot7EkvCzo3vyIcCQQ/fgFu6Omb5JMuZAOs Y1LYDEaIY/PJVnnktv8/mVL/UPS05EbIMo0syKYY4kzEh5jNt8neknaxtguSQgl0zqlwVOTk= X-Gm-Gg: AfdE7clhIquzy93YSqRHSLUJt5FtuToHXJ1dTYkvGcshsW1J5s/sre/0ZcDZxk/ufsf 11dHcZG05gWbuIhxHnfPtAh+extIK481TetJSBoydalx2REwPtf2pBVA+ezTmaL2d9rdPXtKfNr HYVyRf61h/VNWT5IMbZND+kM45Tty5S1OKrLyTMmnelpC1NG+MJY8uAqKM/wgFkYfbYFTqMqnd2 qx7OFShBFY7HXirUkQFczLextb9lOAfxGDt8NEgR5ys8hYF35HDXbZICAuz9YXaHoU2U9r5FcW2 GiADk8gBV65WECt8kbUIMRnmOhr7vnDyipn1KslXtGqNb/WIWlZvjJLGfcJczV8x+zji40XekOZ XlgZq5rPAUuDNls3nPjAd X-Received: by 2002:a05:6122:4683:b0:5a0:5805:c8ba with SMTP id 71dfb90a1353d-5bd69d85542mr1914099e0c.11.1782420076320; Thu, 25 Jun 2026 13:41:16 -0700 (PDT) X-Received: by 2002:a05:6122:4683:b0:5a0:5805:c8ba with SMTP id 71dfb90a1353d-5bd69d85542mr1914083e0c.11.1782420075605; Thu, 25 Jun 2026 13:41:15 -0700 (PDT) Received: from ?IPV6:2804:14d:8084:993e::75d? ([2804:14d:8084:993e::75d]) by smtp.gmail.com with ESMTPSA id 71dfb90a1353d-5bd78e999aasm70229e0c.5.2026.06.25.13.41.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 25 Jun 2026 13:41:14 -0700 (PDT) Message-ID: <2786dcd4-19e5-413c-b24e-40a688640be1@redhat.com> Date: Thu, 25 Jun 2026 17:41:10 -0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 4/8] gdb/record: c++ify internal structures of record-full.c To: "Schimpe, Christina" , "gdb-patches@sourceware.org" References: <20260602143342.12245-1-guinevere@redhat.com> <20260602143342.12245-5-guinevere@redhat.com> <8ec6ee8f-b4e2-4cb1-a238-5f200dd512a4@redhat.com> From: Guinevere Larsen In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: OLF3ZjxL2-ZNcRFkDmPqd_nQaP5JrYRYHaLog7QvwX8_1782420076 X-Mimecast-Originator: redhat.com Content-Type: multipart/alternative; boundary="------------QaIMqUQz10kz20VzLSq97x3Y" 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. --------------QaIMqUQz10kz20VzLSq97x3Y Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 6/15/26 4:49 AM, Schimpe, Christina wrote: > > *From:*Guinevere Larsen > *Sent:* Donnerstag, 11. Juni 2026 19:17 > *To:* Schimpe, Christina ; > gdb-patches@sourceware.org > *Cc:* Thiago Jung Bauermann > *Subject:* Re: [PATCH v4 4/8] gdb/record: c++ify internal structures > of record-full.c > > On 6/11/26 4:21 AM, Schimpe, Christina wrote: > > It seems that you did not change the code as discussed here: > > https://sourceware.org/pipermail/gdb-patches/2026-May/227699.html > > Would you mind sharing the reason for that? > > In my opinion this is necessary. > > I blame the weekend. Leave on friday thinking "I'll do it on > monday", arrive > > on monday thinking "I did it last friday". > > I made sure to make the change now. Added the asserts that the > length is > > 0 in the move operator, which means we won't need to worry > about freeing > > the memory. > > But isn't it possible that "len > sizeof (u.buf)" or at least "len > 0" at this point ? > > Not really. Since we can't have copying of entries, if an actual entry > was stored in the variable that is receiving a move, we lose > information on an entry or we forgot to clear the incomplete > instruction (which means we never added it to the history). The code > is built for this to be the case, so I am asserting that the length is > 0 to catch these mistakes and not let execution information be lost. > Huh, ok. Turns out I was mistaken here in one specific situation. In aarch64 (and possibly other architectures, I would need test it more thoroughly), call instructions end up recording the PC multiple times, which was causing GDB to assert. So I will implement your suggestion for now, and (hopefully) fix the double-recording issues in the near future. Thanks for raising this, turns out my code may have been leaking memory all along, or at least had that chance! -- Cheers, Guinevere Larsen it/its she/her (deprecated) > In any case, I believe a good comment explaining this might be > helpful, since > > freeing the original memory is something one would expect at this > specific code > > location. The same applies for the other assert you already added: > > “gdb_assert (this != &other);”. > > Besides that, I only found one further nit: > the line “ record_full_reg_entry &operator=(record_full_reg_entry > &&other)” misses > > a space before the bracket “(“. > > I believe I am now done with the review of this patch, but like patch > #1, please > > take my review with a grain of salt, too. ;) > > Reviewed-By: Christina Schimpe > > Christina > > -- > Cheers, > Guinevere Larsen > it/its > she/her (deprecated) > > So before this code: > > +    addr = other.addr; > > +    len = other.len; > > +    memcpy (u.buf, other.u.buf, sizeof (u.buf)); > > Christina > > Intel Deutschland GmbH > > Registered Address: Dornacher Strasse 1, 85622 Feldkirchen, Germany > > Tel: +49 89 991 430,www.intel.de > > Managing Directors: Harry Demas, Jeffrey Schneiderman, Yin Chong Sorrell > > Chairperson of the Supervisory Board: Nicole Lau > > Registered Seat: Munich > > Commercial Register: Amtsgericht Muenchen HRB 186928 > > HTML Version: > > > Intel Deutschland GmbH > > Registered Address: Dornacher Straße 1, 85622 Feldkirchen, Germany > Tel: +49 89 991 430, www.intel.de > Managing Directors: Harry Demas, Jeffrey Schneiderman, Yin Chong Sorrell > Chairperson of the Supervisory Board: Nicole Lau > Registered Seat: Munich > Commercial Register: Amtsgericht München HRB 186928 > --------------QaIMqUQz10kz20VzLSq97x3Y Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 6/15/26 4:49 AM, Schimpe, Christina wrote:

From: Guinevere Larsen <guinevere@redhat.com>
Sent: Donnerstag, 11. Juni 2026 19:17
To: Schimpe, Christina <christina.schimpe@intel.com>; gdb-patches@sourceware.org
Cc: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Subject: Re: [PATCH v4 4/8] gdb/record: c++ify internal structures of record-full.c

 

On 6/11/26 4:21 AM, Schimpe, Christina wrote:

It seems that you did not change the code as discussed here:
https://sourceware.org/pipermail/gdb-patches/2026-May/227699.html
 
Would you mind sharing the reason for that?
In my opinion this is necessary.
I blame the weekend. Leave on friday thinking "I'll do it on monday", arrive
on monday thinking "I did it last friday".
 
I made sure to make the change now. Added the asserts that the length is
0 in the move operator, which means we won't need to worry about freeing
the memory.
But isn't it possible that "len > sizeof (u.buf)" or at least "len > 0" at this point ?

Not really. Since we can't have copying of entries, if an actual entry was stored in the variable that is receiving a move, we lose information on an entry or we forgot to clear the incomplete instruction (which means we never added it to the history). The code is built for this to be the case, so I am asserting that the length is 0 to catch these mistakes and not let execution information be lost. 

Huh, ok. Turns out I was mistaken here in one specific situation. In aarch64 (and possibly other architectures, I would need test it more thoroughly), call instructions end up recording the PC multiple times, which was causing GDB to assert.

So I will implement your suggestion for now, and (hopefully) fix the double-recording issues in the near future.

Thanks for raising this, turns out my code may have been leaking memory all along, or at least had that chance!

-- 
Cheers,
Guinevere Larsen
it/its
she/her (deprecated)

 

In any case, I believe a good comment explaining this might be helpful, since

freeing the original memory is something one would expect at this specific code

location. The same applies for the other assert you already added:

“gdb_assert (this != &other);”.

 

Besides that, I only found one further nit:
the line “ record_full_reg_entry &operator=(record_full_reg_entry &&other)” misses

a space before the bracket “(“.

I believe I am now done with the review of this patch, but like patch #1, please

take my review with a grain of salt, too. ;)

 

Reviewed-By: Christina Schimpe <christina.schimpe@intel.com>

 

Christina

-- 
Cheers,
Guinevere Larsen
it/its
she/her (deprecated)
 
 
So before this code:
 
+    addr = other.addr;
+    len = other.len;
+    memcpy (u.buf, other.u.buf, sizeof (u.buf));
Christina
Intel Deutschland GmbH
 
Registered Address: Dornacher Strasse 1, 85622 Feldkirchen, Germany
Tel: +49 89 991 430, www.intel.de
Managing Directors: Harry Demas, Jeffrey Schneiderman, Yin Chong Sorrell
Chairperson of the Supervisory Board: Nicole Lau
Registered Seat: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928
HTML Version:


Intel Deutschland GmbH

Registered Address: Dornacher Straße 1, 85622 Feldkirchen, Germany
Tel: +49 89 991 430, www.intel.de
Managing Directors: Harry Demas, Jeffrey Schneiderman, Yin Chong Sorrell
Chairperson of the Supervisory Board: Nicole Lau
Registered Seat: Munich
Commercial Register: Amtsgericht München HRB 186928
--------------QaIMqUQz10kz20VzLSq97x3Y--