From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id na2hL0gYQmONMQgAWB0awg (envelope-from ) for ; Sat, 08 Oct 2022 20:39:36 -0400 Received: by simark.ca (Postfix, from userid 112) id B5FBA1E112; Sat, 8 Oct 2022 20:39:36 -0400 (EDT) Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=yj+K35Qj; dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A,RDNS_DYNAMIC, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 676711E0CB for ; Sat, 8 Oct 2022 20:39:36 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 4C3833853570 for ; Sun, 9 Oct 2022 00:39:35 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4C3833853570 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1665275975; bh=IWsRJm1OyiBdALWXmBcmbrJNsli4DeF/A2TW5EiPhNE=; h=Date:Subject:To:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=yj+K35Qj5bwYdTpJaDjefwFoEhZBnXmxnBJeBgDoi+zpyo8dWT9aYGzskRyNTb/v3 dEft1yT7ki94SQblNvJWT0d7KJkfHrPRLjgdXtFszQbQDZZPtXCT+6WoqbEt4pv+WJ zwlEarmt93/uIhhq/8nYrB4Yjk0FPc+3aQNdkgr0= Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id 9ED883858CDB for ; Sun, 9 Oct 2022 00:39:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9ED883858CDB Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 2990d22L024911 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 8 Oct 2022 20:39:07 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 2990d22L024911 Received: from [10.0.0.11] (unknown [217.28.27.60]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 686541E0CB; Sat, 8 Oct 2022 20:39:02 -0400 (EDT) Message-ID: Date: Sat, 8 Oct 2022 20:39:01 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.1 Subject: Re: [PATCH] gdb: fix auxv caching Content-Language: en-US To: John Baldwin , gdb-patches@sourceware.org References: <20220920122828.188190-1-luis.machado@arm.com> <20221007204440.3041413-1-simon.marchi@polymtl.ca> <6e3e1ac0-0afc-d053-b48e-a7d20549d1d7@FreeBSD.org> In-Reply-To: <6e3e1ac0-0afc-d053-b48e-a7d20549d1d7@FreeBSD.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Sun, 9 Oct 2022 00:39:02 +0000 X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Simon Marchi via Gdb-patches Reply-To: Simon Marchi Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" > I think this approach is fine.  Having two variants of target_read_auxv is > a bit verbose, and I'm not sure it's abundantly clear to a new person when > to use one vs the other.  That said, these are used rarely, so probably > will intuit the right thing by looking at existing uses.  I agree with the > idea that the auxv reads during gdbarch_core_read_description should > effectively all be "raw" and uncached. The second one is perhaps not essential, call sites could call target_read_alloc (ops, TARGET_OBJECT_AUXV, NULL) themselves. But I find it convenient to have this little wrapper. As to how to know which overload to call, perhaps that can be improved with better documentation and comments. I'm not sure what to add though, the problem is so fresh in my mind that it's obvious to me. So I'm open to suggestions. Simon