From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id ktC0EnQA72hcQTMAWB0awg (envelope-from ) for ; Tue, 14 Oct 2025 22:01:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1760493684; bh=aswi/GIIz3RwKLLBnffi8U5x/Lj4KVbKEmX9COJgqT8=; h=Date:Subject:To:Cc:References:From:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=ahjbBL9ReUdW7xehRlw0g7Whh2UfwdFP97OLfJ7exhPWX4fsfvSZZDFN+YeNmnT8m 7tN4TEIdrogPkSw+ngdEHC9nZQZctJgtlPibdMyt0/GOPfivPj1KjY7A3rLWTymLXN ra6yrWQKhJWSagTO4Kpc8DwQQDK1KDQK6cINDSC0= Received: by simark.ca (Postfix, from userid 112) id 3D1BD1E0BA; Tue, 14 Oct 2025 22:01:24 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,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 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=vycumo/a; dkim-atps=neutral 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 72E801E04C for ; Tue, 14 Oct 2025 22:01:23 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 01B723858430 for ; Wed, 15 Oct 2025 02:01:23 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 01B723858430 Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=vycumo/a Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id CD1F23858D32 for ; Wed, 15 Oct 2025 02:00:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org CD1F23858D32 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca ARC-Filter: OpenARC Filter v1.0.0 sourceware.org CD1F23858D32 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=158.69.221.121 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1760493631; cv=none; b=uIVZAq/5r6tG0ZzFDHuj4UemZeQOsW5gDKL0rBL/zRb0UTCmZXvQlGUbQOl9CORmowimupX6eihdsux/0FCBzkRcURWytN6ZvLRQ4RD7ZE73PN+MGURSFN6QE1Ll1rcGGYnr5ah2sE86fkiwYUYGLZ2Q/SRip8AlG9zpQ2fY3Oc= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1760493631; c=relaxed/simple; bh=aswi/GIIz3RwKLLBnffi8U5x/Lj4KVbKEmX9COJgqT8=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=vH9JmXz50PkJrOtxiamrUhRcvt8G+vpnvqk2XkSmPqFBGYUNW3J/zD7gwDfbfQ3/HH+nflPOyVavbdRUGb7CpizZoTOjZ+v0+tcFnNbxQxt8K3QLdC7Gf3E1HfCjzM1X20hmZA1pMN3YxZIouyzZUhGqgV32TYWQO68Yz3nGnxo= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org CD1F23858D32 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1760493631; bh=aswi/GIIz3RwKLLBnffi8U5x/Lj4KVbKEmX9COJgqT8=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=vycumo/aH6ugkWHJeFVt6+zdysME/+hww7O+Fm/q2o7fjR+iUP1LnERCh8sJt3i8X ADSZokicZUMkQfyzfM0kasClUMfe2ObW/M4qPbta54srW9wfNqfaIpSwzDQ1XmvaZO dspjtflt/MLyS/Ku3zksl5l2DT8LuX70EN0x/Zac= Received: by simark.ca (Postfix) id 271321E04C; Tue, 14 Oct 2025 22:00:31 -0400 (EDT) Message-ID: <0420c102-7ef0-40c7-a4e8-76004a6a2214@simark.ca> Date: Tue, 14 Oct 2025 22:00:30 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/2] gdb: use std::vector<> to hold on blocks in struct blockvector To: =?UTF-8?Q?Jan_Vran=C3=BD?= , "tom@tromey.com" Cc: "gdb-patches@sourceware.org" References: <20251013182318.1045138-1-jan.vrany@labware.com> <20251013182318.1045138-3-jan.vrany@labware.com> <706dd0b5-a1f0-4cdb-bd41-b3b1a2bbac3a@simark.ca> <87qzv5tfkd.fsf@tromey.com> <86e1dd07aea13acd5e7ded0217f053a0db64c63d.camel@labware.com> Content-Language: en-US From: Simon Marchi In-Reply-To: <86e1dd07aea13acd5e7ded0217f053a0db64c63d.camel@labware.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 On 2025-10-14 16:40, Jan Vraný wrote: > On Tue, 2025-10-14 at 16:19 -0400, Simon Marchi wrote: >> On 10/14/25 4:05 PM, Tom Tromey wrote: >>>>>>>> "Simon" == Simon Marchi writes: >>> >>> Simon> I also wish we could avoid having a "set_block" method, because it >>> Simon> requires having the blockvector in an invalid state (some blocks slots >>> Simon> set to nullptr) while we build it, which could be error prone. The >>> Simon> users of the set_block method are buildsym and jit. From what i saw, >>> Simon> they could both very well prepare an std::vector with their blocks and >>> Simon> std::move that vector into a blockvector constructor. That constructor >>> Simon> could assert that the blocks are correctly ordered, or to the sort >>> Simon> itself (something that both buildsym and jit do already). buildsym >>> Simon> starts with a singly-linked list (m_pending_blocks), moves the blocks to a >>> Simon> temporary vector (in end_compunit_symtab_get_static_block), sorts that >>> Simon> vector, builds a singly-linked list again, and then traverses that list >>> Simon> to insert the blocks into the blockvector. I think that could all be >>> Simon> simplified by making m_pending_blocks an std::vector from the >>> Simon> start. >>> >>> Are you proposing that Jan do this in this patch? Or is this just a >>> future-looking comment? It wasn't clear to me. >>> >>> Tom >> >> Sorry about that. I would not ask Jan to refactor or clean up >> everything in buildsym and jit. But perhaps we can agree on what a good >> (easy to use, hard to mis-use) API for blockvector is, and then Jan can >> do the bare minimum to wire up buildsym and jit to that API. We can >> then do some cleanups later to remove some unnecessary steps in buildsym >> and jit. > > At the moment it seems to me that the first step is to drop add_block(), > add append_block() and common ordering predicate and take it from there. > I'll try to have a look tomorrow. Sounds fine to me. And I think it's fine to have set_block for now. Code today pokes the block list directly, so set_block isn't introducing anything new. Simon