From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 2MIsFREkmF/fRAAAWB0awg (envelope-from ) for ; Tue, 27 Oct 2020 09:43:45 -0400 Received: by simark.ca (Postfix, from userid 112) id 50D6D1EFBB; Tue, 27 Oct 2020 09:43:45 -0400 (EDT) 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=unavailable 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 F17FC1E590 for ; Tue, 27 Oct 2020 09:43:44 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 6F4413870906; Tue, 27 Oct 2020 13:43:44 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6F4413870906 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1603806224; bh=RSX72YWRTqF6MwYdwmpjEsi3ZjCxMrJU1y5Dsxk7I4Q=; 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=oGrhJmoNoRQTB3c2YI4/KDg8GZPnmvXnRyGNdcihKUUiZnsyDebqDmQP1Q6f2cNoI ex26LitkDFe56bJbD/KFYsFklZcAFthUMC2BIT0sXciW1+IEw4H1jSEntwlNDxkMZ+ 0+rU9MAC66f9TcjvK/e02ZEptYpDju8T5oPbK3oo= Received: from mail-qt1-x842.google.com (mail-qt1-x842.google.com [IPv6:2607:f8b0:4864:20::842]) by sourceware.org (Postfix) with ESMTPS id 4FF1A3857801 for ; Tue, 27 Oct 2020 13:43:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 4FF1A3857801 Received: by mail-qt1-x842.google.com with SMTP id r8so941695qtp.13 for ; Tue, 27 Oct 2020 06:43:40 -0700 (PDT) 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=RSX72YWRTqF6MwYdwmpjEsi3ZjCxMrJU1y5Dsxk7I4Q=; b=DkaARVNEB9z0UDEclBixZS6sklSBLr7dNhuhl2cv6CVNBNHLV+EpPiJ03AlSga6hQf kYjb3+NXvG7dn1tWJDzgKf+cDN2ta/dg46tRsBvAgP9SWcasvrDTn9zZ9nA7QYQqys1T mDhufpQx1kSAo/zOL2XOo5q/kfHC2zLuLLCEWUDwLpc4A6BZNrxBwiu9zZ6d/Y3/spAk yRVmC5kaQRHV5jwMaoKpAElJOQxbVs71KLgcdYcaLUZO/yJKUqRmNVBwkZqfXnXDtQU7 13Y1w6HPpHN1N6ucgmAwH+2Q7sIErEs4mK1OqEWexVQUb3j4OZHGPnVLjG455bWDqpqI 0TQA== X-Gm-Message-State: AOAM533OWN1Es/qhOQb10gf/Rt/grw/BPRuWB5e32q4GElYHxQaTghoa V3yym+yCPvydlPDJbWp2215gaQ== X-Google-Smtp-Source: ABdhPJyPYn5YNqqKTzZm1g9jir7DS/BJ+BH+3gRgIjHbgByXrOnX6sZ3JvglDjkGT92rgAASMoPCrQ== X-Received: by 2002:ac8:429a:: with SMTP id o26mr1989003qtl.334.1603806219883; Tue, 27 Oct 2020 06:43:39 -0700 (PDT) Received: from ?IPv6:2804:7f0:8284:1487:d002:4d8c:62e2:d4a? ([2804:7f0:8284:1487:d002:4d8c:62e2:d4a]) by smtp.gmail.com with ESMTPSA id z190sm675642qka.103.2020.10.27.06.43.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Oct 2020 06:43:39 -0700 (PDT) Subject: Re: [PATCH v2 01/24] New target methods for memory tagging support To: Simon Marchi , gdb-patches@sourceware.org References: <20201022200014.5189-1-luis.machado@linaro.org> <20201022200014.5189-2-luis.machado@linaro.org> <89a1dc1c-75c0-5098-acf0-5f647df5a766@simark.ca> Message-ID: Date: Tue, 27 Oct 2020 10:43:35 -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: <89a1dc1c-75c0-5098-acf0-5f647df5a766@simark.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 10/27/20 10:22 AM, Simon Marchi wrote: > On 2020-10-22 3:59 p.m., Luis Machado via Gdb-patches wrote: >> diff --git a/gdb/target.h b/gdb/target.h >> index 039194c239..80f9b1ee92 100644 >> --- a/gdb/target.h >> +++ b/gdb/target.h >> @@ -1260,6 +1260,22 @@ struct target_ops >> /* Cleanup after generating a core file. */ >> virtual void done_generating_core () >> TARGET_DEFAULT_IGNORE (); >> + >> + /* Returns true if the target supports memory tagging. */ >> + virtual bool supports_memory_tagging () >> + TARGET_DEFAULT_RETURN (false); >> + >> + /* Return the allocated memory tags of type TYPE associated with >> + [ADDRESS, ADDRESS + LEN) in TAGS. */ >> + virtual int fetch_memtags (CORE_ADDR address, size_t len, >> + gdb::byte_vector &tags, int type) >> + TARGET_DEFAULT_IGNORE (); >> + >> + /* Write the allocation tags of type TYPE contained in TAGS to the memory >> + range [ADDRESS, ADDRESS + LEN). */ >> + virtual int store_memtags (CORE_ADDR address, size_t len, >> + const gdb::byte_vector &tags, int type) >> + TARGET_DEFAULT_IGNORE (); > > Could you precise the comment for fetch_memtags and store_memtags? It's > not clear to me what the tags vector contains. Will it be of length > LEN, with each element containing the tag of the matching memory > location in [ADDRESS, ADDRESS + LEN)? The TAGS vector contains bytes. The interpretation of those bytes is target/arch-specific. AArch64 interprets those as 1 tag per byte. Some other target or arch may interpret those differently. Length is the number of bytes in the memory range, which doesn't necessarily match the length of the TAGS vector. AArch64 has 1 tag for every 16 bytes, for example. So in a 32 bytes memory range, we'd have 2 bytes in the TAGS vector. Should I enhance the documentation of those methods to make it a bit more clear? I realize some of this is tied to details and terminology of the technology. > > Also, what does the return values mean? My idea was to provide meaningful error codes, as opposed to a bool that tells us the it succeeded/failed. Maybe I should make those a bool for now given I don't have a standardized list of possible error codes? > > Simon >