From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id by7kHFb96V/bRgAAWB0awg (envelope-from ) for ; Mon, 28 Dec 2020 10:44:22 -0500 Received: by simark.ca (Postfix, from userid 112) id 693051F0AA; Mon, 28 Dec 2020 10:44:22 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from 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 RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 80B501E552 for ; Mon, 28 Dec 2020 10:44:21 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 9296A3870906; Mon, 28 Dec 2020 15:44:20 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9296A3870906 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1609170260; bh=MLEF3NnQYHqbGHJ5jZX19KG3NHzwnqzGGfScyp5te+0=; h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=FHXy3IJwxhXrzoCNfFpPgpX5+AuhUDu+mY+Y1o2Ypj6nrCnN9Hq0E1YPaVCKDpBr2 +yrIDD7y+drtaGLU7odO8E5gaqrSWlAlCn6vHcVtpJWDXcspv3/4w4XQNXFPuP1VEb WJzHutoRkB9AYVeKP6OUplpcTwAvi9uv61LSfA8s= Received: from mail-qv1-xf35.google.com (mail-qv1-xf35.google.com [IPv6:2607:f8b0:4864:20::f35]) by sourceware.org (Postfix) with ESMTPS id E15E9385800C for ; Mon, 28 Dec 2020 15:44:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org E15E9385800C Received: by mail-qv1-xf35.google.com with SMTP id l14so5098327qvh.2 for ; Mon, 28 Dec 2020 07:44:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=MLEF3NnQYHqbGHJ5jZX19KG3NHzwnqzGGfScyp5te+0=; b=TYSR6465nTIBgXlQ+vLvJs1yStlvPaPLWmzYauoTK67ZEo89PCA9k96n2G5EHGqAfH pMZjmfTwSowVU1a5UFHeJuKhpXOuTKH6snqIrY5RaIIg28SuVrE8niZ6IiA2I4vWXOw3 tgPlCZe5R0kMfabZLJwDI7a7ioMSyXI2WloOW/0wzFbDDlFAgme7nwHXkkmw3CPnB+2M GP+7CjzQAwWlQeS6fWRunbd5fJkqkhkD0uxU/qvOkgqUSC6/pEAu+KRtQWxKTwWxa4bW P9sLMVieUzFEcfikiDIhc8XMQpj7ImdzHFagpTu9ZRo5ANLNGpHsNMuU8A1O+qGRw9+q ev1w== X-Gm-Message-State: AOAM530QEhUoDN737k5GKkbkFysg9xORDz6gF6Th8cEgEwVoy0e8fgId +4K9JZMGEsXc0H/ac8/I+RkRaA== X-Google-Smtp-Source: ABdhPJyQvGC8dT4D+S38nu1HzNqX7N6mf4OF0nGK6fTyqsiH1Ingi72SJtItNdTM7w5OC/pJmACINA== X-Received: by 2002:a0c:da87:: with SMTP id z7mr47314387qvj.41.1609170257472; Mon, 28 Dec 2020 07:44:17 -0800 (PST) Received: from ?IPv6:2804:7f0:8284:370e:19e7:527f:e109:2734? ([2804:7f0:8284:370e:19e7:527f:e109:2734]) by smtp.gmail.com with ESMTPSA id h24sm24359158qkj.85.2020.12.28.07.44.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 28 Dec 2020 07:44:17 -0800 (PST) Subject: Re: [PATCH v3 02/24] New gdbarch memory tagging hooks To: Simon Marchi , gdb-patches@sourceware.org References: <20201109170435.15766-1-luis.machado@linaro.org> <20201109170435.15766-3-luis.machado@linaro.org> <689b47a9-e9bc-fd00-7575-ba70f40b4ae7@polymtl.ca> Message-ID: Date: Mon, 28 Dec 2020 12:44:14 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <689b47a9-e9bc-fd00-7575-ba70f40b4ae7@polymtl.ca> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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: Luis Machado via Gdb-patches Reply-To: Luis Machado Cc: david.spickett@linaro.org Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" On 12/25/20 1:40 AM, Simon Marchi wrote: > On 2020-11-09 12:04 p.m., Luis Machado via Gdb-patches wrote: >> We need some new gdbarch hooks to help us manipulate memory tags without having >> to have GDB calls the target methods directly. > > calls -> call? > Fixed. >> >> This patch adds the following hooks: >> >> gdbarch_memtag_to_string >> -- >> Returns a printable string corresponding to the tag. >> >> gdbarch_tagged_address_p >> -- >> Checks if a particular address is protected with memory tagging. >> >> gdbarch_memtag_mismatch_p >> -- >> Checks if there is a mismatch between the logical tag of a pointer and the >> allocation tag. > > It would seem more natural to me to have gdbarch_memtag_matches_p > instead,which would just be the opposite gdbarch_memtag_mismatch_p. > If I want to know if a tag matches, I have to do: > > if (!gdbarch_memtag_mismatch_p (...)) > > and that's like a double negative, "if the memtag does not not match". > Mismatches are what we're looking for, so I named it based on that. But I see your point. I've renamed it to gdbarch_memtag_matches_p >> gdbarch_set_memtags: >> -- >> Sets either the allocation tag or the logical tag for a particular value. >> >> gdbarch_get_memtag: >> -- >> Gets either the allocation tag or the logical tag for a particular value. >> >> gdbarch_granule_size >> -- >> Sets the memory tag granule size, which represents the number of bytes a >> particular allocation tag covers. For example, this is 16 bytes for >> AArch64's MTE. > > I'd suggest having "memtag" in the name of this function, to make it clear > it's memtag-related. Like "gdbarch_memtag_granule_size". I think I only messed up the text, because the code is already as suggested. > >> >> I've used struct value as opposed to straight CORE_ADDR so other architectures >> can use the infrastructure without having to rely on fixed types. > > What do you mean by "having to rely on fixed types"? > Instead of assuming the tagged address will fit in a CORE_ADDR, for example, we use a "struct value *" to cope with architectures that have addresses that are larger than a CORE_ADDR or that have completely different types. CHERI/Morello is one such example. The pointers will be capability types of 16 bytes, with a tag stored as metadata. So this patch makes it possible to support those architectures in the future. Using "struct value *" also prevents generic code from having to know what specific types/sizes we're dealing with. Does that make it clear? > Otherwise, this LGTM. > > Simon > Thanks for the review.