From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id zhC5NkzSCWdqbgoAWB0awg (envelope-from ) for ; Fri, 11 Oct 2024 21:35:08 -0400 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=linaro.org header.i=@linaro.org header.a=rsa-sha256 header.s=google header.b=yMl+LYLL; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id A18B71E358; Fri, 11 Oct 2024 21:35:08 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-6.8 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_BLOCKED,RCVD_IN_VALIDITY_CERTIFIED,RCVD_IN_VALIDITY_RPBL, RCVD_IN_VALIDITY_SAFE,URIBL_BLOCKED,URIBL_DBL_BLOCKED_OPENDNS autolearn=ham autolearn_force=no version=4.0.0 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 5132D1E05C for ; Fri, 11 Oct 2024 21:35:07 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id E116F3857C78 for ; Sat, 12 Oct 2024 01:35:06 +0000 (GMT) Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) by sourceware.org (Postfix) with ESMTPS id 5A1633858C2B for ; Sat, 12 Oct 2024 01:34:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5A1633858C2B Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 5A1633858C2B Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::631 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1728696869; cv=none; b=hesXvNOjSxAJ4vBDR5WZ7ZgU2B+k3ZcDQDoNK+O4YtPuA3vk9uVRNoT3tSgCvKkzMsfg5EzkKd1rJk/KMO1kZzeFJ1DFefjgy+LY0UjA4jWRlpLJQPLuerjCSgcliIgn7a4SZ/NF6uYvt7YoywPxMmOLj2TYE4lNHCX3zu+Z0pA= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1728696869; c=relaxed/simple; bh=DAX2Af0POOADusjCrMXBYR8Oj/Yj2jk5r9KPf+Pz4Tk=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=hRlAtHaZ1vW+VMDcZm1oPSg5zA1r6rDJ4XsDGik58whnnTri+YGhI3GEkht3LaOL9wVy6EnLtRn+XNO/NrKVZh0MUxl+hqgTZtniTejstfk2MrGwZ2/z4NEaITZbVcBsxF+my53MRcvpzL2z2zMVIg+9AzIdE4pteTAAyfct58A= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-pl1-x631.google.com with SMTP id d9443c01a7336-20c693b68f5so27109315ad.1 for ; Fri, 11 Oct 2024 18:34:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1728696866; x=1729301666; darn=sourceware.org; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:from:to:cc:subject:date:message-id:reply-to; bh=PfJWOoOPbcyoZpJgEouJAYzcunZ7FBVEjiuBykhffbM=; b=yMl+LYLLXJUY4EJCkuVQXdyFkos9pE8pinOz7EVpRGqlG7yWhvvR8RILxz+/j7uTcK dFY8J5l9tlwCCxM+4QUddkDcTZp2cGy+59u4nAyR8hurK6JTpPGVRWqFZVheurUUQW5T zdvyMTZCEwm+LE/6W9ho/K+zPPvp1SgdhrlP24yImdIiETKJxnYpcmJhCpB7RUitGycT Tu0OjS56u554bpaVyiRqUTaaa7otdHW9XQhFC5uY0HEf6TlitXw3i+MI/PmnQFLxtCkF qOJf021q4CEX26zBvZQfeCKXlC5yjR2K1rVq3lJPmSf83iIv5yBOPYldni5Oq1FbZJz4 73vw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728696866; x=1729301666; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=PfJWOoOPbcyoZpJgEouJAYzcunZ7FBVEjiuBykhffbM=; b=K6gtjt86+MxzA1raQibXkaT8nAV5DMe0QHEfyW7tHpeeWTV54WRRivhNK4gq1DGQoN tF860ZyQhb1flwrOOqS/j8dzS6UH8SHgqH+CwDTkGP1LaADpeS3/BA25x/ycqUM7v3Oi 0FdBF7l4CsDZyeH30NqUQxFo0eQUzsgkUvz39e0zkgowghbCkOwfHOnDQYbYGKQ2aAiu EK8fB1JgX/HAEGhGGbxRwhaBdJMmShN6+VcxFGSuVP95+ThDKH43JUlY+RhuVFJ4X44K bFnblIhqousJ2trjP5DElUCxxyuszmM5rGoRNA6zDeZVYMABWxNRsoQ1cQ/nrsm2mFt3 4qlg== X-Forwarded-Encrypted: i=1; AJvYcCWBz92vo8AhmhcKVFZQsP5oZak9/2/AKCYuwU0QSZrz/2O3rB2wVmEZq31jmoTbQ68aFkG+XkklQnt/vw==@sourceware.org X-Gm-Message-State: AOJu0YwqUG56zL5K4LFpNWCNyjxVHxjfF9A+79DnzBqE9nGUJFUHIroa 9+LPZZ7OOSp7NK3n199lKVDLjp7IjtuPbdnPM8pE3iuvh5ybwQ7GT0xfWFzTGOE= X-Google-Smtp-Source: AGHT+IGkCRrEFxo2KyyIPK+NdTI8pPYbE+oUaFew7nxK3i2jdbs/Mde6BcFtMHuORYIHJ39nhOaNUw== X-Received: by 2002:a17:903:2441:b0:20b:b5d5:8072 with SMTP id d9443c01a7336-20ca13f72fdmr52759315ad.2.1728696866212; Fri, 11 Oct 2024 18:34:26 -0700 (PDT) Received: from localhost ([2804:14d:7e39:8470:fb47:6b77:c455:1e57]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-20c8c0e75fesm29459575ad.158.2024.10.11.18.34.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 11 Oct 2024 18:34:25 -0700 (PDT) From: Thiago Jung Bauermann To: Tom Tromey Cc: Guinevere Larsen , gdb-patches@sourceware.org, Guinevere Larsen Subject: Re: [PATCH v5 1/5] gdb: make gdbarch store a vector of frame unwinders In-Reply-To: <87iku7hfz5.fsf@tromey.com> (Tom Tromey's message of "Fri, 04 Oct 2024 12:37:18 -0600") References: <20241001184235.3710608-1-guinevere@redhat.com> <20241001184235.3710608-2-guinevere@redhat.com> <87iku7hfz5.fsf@tromey.com> Date: Fri, 11 Oct 2024 22:34:22 -0300 Message-ID: <87v7xydrz5.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain 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 Hello, Tom Tromey writes: >>>>>> "Guinevere" == Guinevere Larsen writes: > > Guinevere> Seeing as a future patch of this series wants to refactor the > Guinevere> frame_unwind struct to use inheritance, and we'd like to not restrict > Guinevere> the future derived classes on what destructors are allowed. In > Guinevere> preparation for that change, this commit adds an std::vector to gdbarch > Guinevere> to store the unwinders in. > > Using a vector is fine, but I still think that this approach > makes gdbarch mildly less opaque. That is, now code anywhere can modify > the unwinder list in any way; whereas currently this is constrained to > the interface provided by frame-unwind.c. Do you think it would be better if the vector was kept in a registry, like the current frame_unwind_table is? I.e, changing: static const registry::key frame_unwind_data; to: static const registry::key> frame_unwind_data; ? -- Thiago