From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id E1hHH5ydEmf6XhIAWB0awg (envelope-from ) for ; Fri, 18 Oct 2024 13:40:44 -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=AtdhiEdE; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 6B5C21E35F; Fri, 18 Oct 2024 13:40:44 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-7.8 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIMWL_WL_HIGH,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 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 D75A01E35D for ; Fri, 18 Oct 2024 13:40:43 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 6C0143858282 for ; Fri, 18 Oct 2024 17:40:43 +0000 (GMT) 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 AC43D3858C42 for ; Fri, 18 Oct 2024 17:40:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org AC43D3858C42 Authentication-Results: sourceware.org; dmarc=pass (p=none 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 AC43D3858C42 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1729273220; cv=none; b=AEmrUBiXaagXTw7Q8Qz7rMwv5qT4KPH2iuqI3XfU/7bCcUqCoho0aPxun2u+ib2HGw+T15+Q3za8qGetgYsQFqt6G0dOmwkKwz2qMv9ZBaUFFFSM0STLI6q2sHj+psf/LS37IWuscZb07Ofax6Yy259KDZWY9USB2EGiGUMYYEg= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1729273220; c=relaxed/simple; bh=ucx3307cxhqp9mF4qPs0outFGhPg/tAZ4zWNo9U6k9Q=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=YdOynGAFJxeWrRk99AuQnikuxyAUp/OU2QrQPllex5SEXtkVKKrAB0fpwKVtP8qEmZJgzP+CrazDlEJiKrcivHMEcd+6fo7tLUZocUeI49UwdUQR0WFmLqmFsTkfFnpA7AnuC/MOcO8TO81P/ahc+yP6Uf9xd3ZUukZ1knW4/b4= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1729273216; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=J5t1BAVnYkr4zdlQNw9uKKHDFex1GZb03lr6CZUS048=; b=AtdhiEdE30KxHcpNK1HvAyZ+HV8yb7jgjNc49XXjXw5IevGDfCY4P8QXaXHAI01VCnEUVc WsRmuHRZu5ykOPzd8viFDxpSQ2HvLArJSMvE8E6xfMqf+e1mvGPUsukXAYu34rF6eknAZB NZcDuodIEPgEpQVt4Y3AEkpLASCV48w= Received: from mail-qv1-f71.google.com (mail-qv1-f71.google.com [209.85.219.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-472-4t2f49poM2GDGOPof30mPw-1; Fri, 18 Oct 2024 13:40:15 -0400 X-MC-Unique: 4t2f49poM2GDGOPof30mPw-1 Received: by mail-qv1-f71.google.com with SMTP id 6a1803df08f44-6cbe4fc0aa7so45331416d6.0 for ; Fri, 18 Oct 2024 10:40:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729273215; x=1729878015; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=J5t1BAVnYkr4zdlQNw9uKKHDFex1GZb03lr6CZUS048=; b=STYUt3M5JW+E/E2gf/1BQ0NdbxKM26gfBu0shA3+vLY9zCGidv1Jj4+HVy15ovwHwd aEu4nHVDmOUGXc41bMPGm6Nipr5x9JwnfTyhdfXZpPBHUK/5E22iDHYpeB6zDfMbEL0I TNIrtFg8LlUdZER6vM/dhEDDMaD2M9634HBMFJJ+B+Y6YLNJE5V2TDfzXH12ER/jW4xJ o8RIaLj0cLf3JNkgOCskfxCIRi9iVOdU7pShmdlBnmQX5vErHw/bGlhnNjUNmnLwS42X uwhRcDyhOEhk2LBmAgFxNWPbQrYNG6Afso2DzfjpPPuRWug6Cdrkv+feKdWIyOiNKFHA RI+A== X-Forwarded-Encrypted: i=1; AJvYcCVW4Mz6JtT4fB7AZqYNoinKABxXV9vU9bp1QZP86t/qMhC06WBfTF8eClXfNmNGLyrbQX/4s5zN9kvGVA==@sourceware.org X-Gm-Message-State: AOJu0Yz9q2eSu51LLWcrKgEbQ7gHjyUEFcmphsIMFjlHlAX8MEzwh83Z GpbdPMWBl29I1LzXal9iF+xT9ZHEdahasvuTyh3jHni/htWBnm9xgBvmkG7H/NIXiX4ZDWuAmX1 jzTJFsq0dXMxdMqzIAUKXNlW5XVQkRrEfOyOc8mt/+gnja2nF/kHU1nfEi6M+sZrxUPg= X-Received: by 2002:a05:6214:4b0d:b0:6cb:fff6:8f28 with SMTP id 6a1803df08f44-6cde15eb790mr50706896d6.40.1729273214741; Fri, 18 Oct 2024 10:40:14 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGLcqhF6N+4rqpOAx/LSrtUGOl1myYGrDkAGoQmAbodW+bV0/jjVng/lv/K/krso96U/FOylQ== X-Received: by 2002:a05:6214:4b0d:b0:6cb:fff6:8f28 with SMTP id 6a1803df08f44-6cde15eb790mr50706616d6.40.1729273214392; Fri, 18 Oct 2024 10:40:14 -0700 (PDT) Received: from ?IPV6:2804:14d:8084:92c5::1000? ([2804:14d:8084:92c5::1000]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-6cde114e9fesm8920136d6.54.2024.10.18.10.40.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 18 Oct 2024 10:40:13 -0700 (PDT) Message-ID: Date: Fri, 18 Oct 2024 14:40:10 -0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 1/5] gdb: make gdbarch store a vector of frame unwinders To: Tom Tromey Cc: Thiago Jung Bauermann , gdb-patches@sourceware.org References: <20241001184235.3710608-1-guinevere@redhat.com> <20241001184235.3710608-2-guinevere@redhat.com> <87iku7hfz5.fsf@tromey.com> <87v7xydrz5.fsf@linaro.org> <87zfn21gu6.fsf@tromey.com> From: Guinevere Larsen In-Reply-To: <87zfn21gu6.fsf@tromey.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 10/17/24 7:53 PM, Tom Tromey wrote: > Guinevere> I am not a big fan of the registry subsystem, so I would prefer to > Guinevere> keep it as a simple vector. However, if you are concerned about the > Guinevere> opaqueness change, Tromey, I can try to make it more opaque. I just > Guinevere> personally find that registry tends to make the code too opaque for > Guinevere> programmers as well as the program itself :-) > > I think gdbarch is exposed to a lot of tdep code, and this code in > particular to do questionable things. So, preserving some opacity makes > sense to me. Understandable. It didn't sound like you were that worried about it previously, apologies for seemingly ignoring this feedback > > Guinevere> So if you want more separation, I would personally prefer to look into > Guinevere> only receiving a copy of the unwinder list, and gdbarch is responsible > Guinevere> for adding and removing things. Just let me know and I can give it a > Guinevere> shot > > I think it would be more worthwhile to understand your objections to the > registry. It seems to me that switching back to using it is just a > couple of lines of code, so it makes me think there must be some pretty > strong reason. My main objection is in the form of "this feels like the type of magic you don't want on the project". It feels like some very complicated arcane code that causes things to seem much more complicated for new contributors. I understand it is important in some cases, but in here it seemed to me like making a registry that stores a standard library class was just obfuscating the code for little gain. I would propose that instead, the getter for the vector returns a const reference (asserts if it is called before initialization). gdbarch would then provide a "initialize_unwinders" method and a "add_unwinder" method, but those should only be called by frame-unwind.c (and that would be explicitly called out in the comments of those functions). This follows a bit more the traditional object orientation route for handling opaqueness, I believe, which would make it slightly easier to have new contributors up to speed. I know this isn't the strongets, so I understand if you want me to keep the registry stuff. -- Cheers, Guinevere Larsen She/Her/Hers > Tom >