From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id /6GBIaztKmre2AEAWB0awg (envelope-from ) for ; Thu, 11 Jun 2026 13:17:32 -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=M7/K/BpR; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 6F2FA1E098; Thu, 11 Jun 2026 13:17:32 -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 A5C811E070 for ; Thu, 11 Jun 2026 13:17:31 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id A94F64BA23EC for ; Thu, 11 Jun 2026 17:17:29 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A94F64BA23EC 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=M7/K/BpR 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 F173B4BA543C for ; Thu, 11 Jun 2026 17:17:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org F173B4BA543C 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 F173B4BA543C 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=1781198222; cv=none; b=CvTxXgodpntuOI+hcNDbYaTTUJL1IQKlq/Mhvp/Mtx4CDtZ5gGhDD2WPU6yk97Q/9a5CMEOriYF/FNoJtGWL1XwwsyxcTdqLQGxXr5gRuHano7Jn3dTTzK6KwK4PZ/wOYCIQY2CFP1+1indhFkB0HjJE78NflPPZyYYH9tSOUTo= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1781198222; c=relaxed/simple; bh=ztaPXehj3E36277LMWB/CNCOFWcvULX46rp+vKqblsY=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=oSYljs9F3mF5UG6Q16KWRQZrJA6jx6GFsg/PpdeYA3aICiyOXjimLPv1js7zWW9nVj1oK4WPEOTuivnh5aaf0pkqtP4n50hwyBbgEk/OB8Q+RI7Pdy0vXBrDqxLvCpMlD5gMzuKAat01FiWuIuwMXPAoobHbLeBgUqAA+GoE4JY= 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=M7/K/BpR DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org F173B4BA543C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1781198221; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=dpKsoIziNfUVgv7c5Dbbm8d74ejFiVZAhoUlIUuIBdo=; b=M7/K/BpRXyyEBGez802XJZcC/+4FffT4HEVPMcTwb7LBkWGaXC+SJ7k3t6kdY7UoXR2oHR c6fqqVT+3y9dkeJqo8dTc9coOw8FZ+/8LSH/pMa8zQI43r7uMG6HWnSr0Jpb3b8hhQCepI 1YHjEgpATY8SZD9JKrK/OeAf9b4BncI= 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-644-UGQk2SKIMcSyoe38dBrKmQ-1; Thu, 11 Jun 2026 13:17:00 -0400 X-MC-Unique: UGQk2SKIMcSyoe38dBrKmQ-1 X-Mimecast-MFC-AGG-ID: UGQk2SKIMcSyoe38dBrKmQ_1781198219 Received: by mail-dy1-f199.google.com with SMTP id 5a478bee46e88-304f23c55b2so188774eec.0 for ; Thu, 11 Jun 2026 10:16:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781198219; x=1781803019; h=in-reply-to:from:content-language:references:cc: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=wWkCXD0MfF76UxGUAMMOEGjUCPjEepqL91w3XqLw5to=; b=V4ecp45xk48PbgRFOKq5xydhe6NX4gqqkFvu81IaXdgbdmrBsKdfqy+M2R7N1qMcQY wy5ZXCls962LtVWV3AY5SO3B5aMD//KDTfl5Nw/ImaeU1P0vpVx/0Rzis2Vm2u3n1uMl c4EN4uAW6O3ILz9Gj3Wb3w6WtdIIHZor7RBIIP8l9QC0QF2KYYBCew0FgWP3KhKkw7hi 6W/7k9YmOEWUSUHIz9qTwRtgSmQDd0GizbwWp1L+uo7qIrPTVpON8OuCQutgJCA4psVc ww3WEYuZFHbAR/4VyhTuhDfarhhwie4+PpCPE7UZfD1HAnAKIFOQVhDCYT2/OCOBu44M jarA== X-Forwarded-Encrypted: i=1; AFNElJ9bhIvWzW2UMypQPtHzd1bhWGD/5HiguhH47auJ/gGWquKgwo+k6jquleOWhXWxvzUinv63Ff+5zk0wOw==@sourceware.org X-Gm-Message-State: AOJu0YzfWVTT4904QeE7l5R7AZOj5pLf2DVILArggTMW54SNzJ7i9ADJ NGFoxTuTV0lHRHXV8xg8Mxlf7EW+wpD0OJ5U+po4J1Y7uGTLSQlqMH6m512s95vxjx1VwZ/azVq ozGye145ddQrqCvwOXud3FPxDTmmkmYCvoSAm/RgRpS81vnKWdr9Wq+hh6a1tQX0= X-Gm-Gg: Acq92OFCxRT/Hym0nR1rzmD8I886bjLlDZuJAIQQIJInhW1XPhNOtKQ13C/jK6n+1ts WZm4ax6fAw/HmifRHHP9JL3NxgysFk3SvVg4jE9K6a+6zzE5eyZ9GXVjTJNr3nQvPYFCDRoBdTo F0WnSV+GawtaLickfPySYZoRzS3ivOJmUkQLBgJs7mVBtTFAGOiMdUZTiE2Cu+ULxyzE9gRYAwb A8B50bhuIaAuc4RLrDiytEsX/JwcPsWhOWN1kLBI0c7orn4NvQPwWept56ztNvgTqRt9g+dsDfn xT9cCSVcxtM8rKjFY7Z6Om9fXA2/6Q0Oyi/YvvIDvnMu7Ypa0pgX2fatMIOMnNdCV54ewUqGtK0 awbz2HnU46sGcNKC7l4CLptzLTWUwDICMUgTkSG4v65DaeuKo6ozi2MxT5YhTAAUIx0Qa X-Received: by 2002:a05:7300:7fac:b0:304:bce9:25fa with SMTP id 5a478bee46e88-30804607632mr3071724eec.4.1781198218384; Thu, 11 Jun 2026 10:16:58 -0700 (PDT) X-Received: by 2002:a05:7300:7fac:b0:304:bce9:25fa with SMTP id 5a478bee46e88-30804607632mr3071679eec.4.1781198217655; Thu, 11 Jun 2026 10:16:57 -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-30806c45dcasm2791805eec.7.2026.06.11.10.16.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 11 Jun 2026 10:16:57 -0700 (PDT) Message-ID: Date: Thu, 11 Jun 2026 14:16:53 -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" Cc: Thiago Jung Bauermann 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: -sQxm2kyJJ3BJFXCGRdQu8G_NfOKgYg5M-bF-yv2Vvo_1781198219 X-Mimecast-Originator: redhat.com Content-Type: multipart/alternative; boundary="------------wMGT0qT6UawnWTwIR0GhVfd0" 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. --------------wMGT0qT6UawnWTwIR0GhVfd0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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. -- 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 --------------wMGT0qT6UawnWTwIR0GhVfd0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
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. 
-- 
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
--------------wMGT0qT6UawnWTwIR0GhVfd0--