From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id M2AoNiCjsl+qYwAAWB0awg (envelope-from ) for ; Mon, 16 Nov 2020 11:04:48 -0500 Received: by simark.ca (Postfix, from userid 112) id D1BAF1F08B; Mon, 16 Nov 2020 11:04:48 -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 1D7C21E58F for ; Mon, 16 Nov 2020 11:04:48 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 9063D3850438; Mon, 16 Nov 2020 16:04:47 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9063D3850438 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1605542687; bh=56+fq/BVPkI8c/XWlhzgCF+IQFeXzKetpoS7sXw1RHI=; h=References:In-Reply-To:Date:Subject:To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=YE1x4ZRZTau3zZ8X+k1jEpZJNjC7HE0Pwb2xiXB0B582DQ5MJyS3rJZGWvdDTexp5 aW3MaFTR32bWwPhInR3oiyACfE2Kvnqn7htk373S/462vcDf0AOTpKRl4u1C0eEzeW fdoi6jAABzO3pF0OY+bIAlfGkBrOXXX1ldh8blx0= Received: from mail-vs1-xe44.google.com (mail-vs1-xe44.google.com [IPv6:2607:f8b0:4864:20::e44]) by sourceware.org (Postfix) with ESMTPS id 124A1385DC17 for ; Mon, 16 Nov 2020 16:04:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 124A1385DC17 Received: by mail-vs1-xe44.google.com with SMTP id u24so9406520vsl.9 for ; Mon, 16 Nov 2020 08:04:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=56+fq/BVPkI8c/XWlhzgCF+IQFeXzKetpoS7sXw1RHI=; b=CJTYX+Zjjg3OMmPoHQiee3NLamel0qBfFUdVA5HXats5XuWB9MzH8l8C+oQ6Xyss3t qRxxmTtWeRf6TNIw1ByE2bedvwWcnyEHhY9CXm+zFBDIQPZ5Jwpd8J0FnlWWeH+NXYnV RTFJa/NjSI34+4ZxSJ93Pea70KrHnW68q2XDP2CsjyO6oaYsN0o7x21lOiYJ6E8p6aC8 88qm5coneTGGvATsfNLNbIf0Xrh5jsaMvUl9H5dA0MAjeT6HmnlFekGsX803916RclKJ vLeRf4oHKpT5f4Suve4m5NubuOIzGaqXm83IytucpkQ/2BfBWaLZg8dcSKmNwAQ7RHzT wQZQ== X-Gm-Message-State: AOAM5338udjDw/hwMXgwFaD7FPk8t46YNEnv0ucVBR+16Sj0qy0llGtU K/dGUsfaBDMkTiHql1l0XVgmlW9PNzYUxGhBMvutYA== X-Google-Smtp-Source: ABdhPJxFHIzgsoFvXc8aF3va295++uWPiUMrAFspLVxxGUGZmQFK2D+cfapwO86zGm7CxJYmnK1tero4wEQeJnccE3s= X-Received: by 2002:a67:b404:: with SMTP id x4mr3458649vsl.34.1605542684709; Mon, 16 Nov 2020 08:04:44 -0800 (PST) MIME-Version: 1.0 References: <20201109170435.15766-1-luis.machado@linaro.org> <20201109170435.15766-8-luis.machado@linaro.org> <83ft5i4fwl.fsf@gnu.org> In-Reply-To: Date: Mon, 16 Nov 2020 16:04:33 +0000 Message-ID: Subject: Re: [PATCH v3 07/24] Documentation for memory tagging remote packets To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" 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: David Spickett via Gdb-patches Reply-To: David Spickett Cc: gdb-patches@sourceware.org Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" Also with regard to the "type" field. > +@var{type} is the type of tag the request wants to fetch. The typeis a signed > +integer. (typo aside) Is this field architecture specific and will there be a list of these type numbers documented anywhere? (or already is) For example would 1 on AArch64 be MTE, and on be . Or would that be 2. My assumption has been that it is the latter and that a value means a kind of tagging extension. So for example 1=MTE rather than 1= mte logical and 2 = mte allocation. Correct me if I am wrong there. A page like: https://sourceware.org/gdb/current/onlinedocs/gdb/ARM-Breakpoint-Kinds.html#ARM-Breakpoint-Kinds Or just a short note, given that there's only one type right now. Also, I may have suggested the type be a string at some point. However based on examples like the link above I don't see much advantage to it apart from making packet dumps easier to read. Just wanted to close the loop on that if I didn't before. On Mon, 16 Nov 2020 at 15:44, David Spickett wrote: > > Minor thing, there is a missing space here in "typeis". > > > +@var{type} is the type of tag the request wants to fetch. The typeis a signed > > +integer. > > On Mon, 9 Nov 2020 at 17:08, Eli Zaretskii wrote: > > > > > Date: Mon, 9 Nov 2020 14:04:18 -0300 > > > From: Luis Machado via Gdb-patches > > > Cc: david.spickett@linaro.org > > > > > > gdb/doc/ChangeLog: > > > > > > YYYY-MM-DD Luis Machado > > > > > > * gdb.texinfo (General Query Packets): Document qMemTags and > > > QMemTags. Document the "memory-tagging" feature. > > > --- > > > gdb/doc/gdb.texinfo | 96 +++++++++++++++++++++++++++++++++++++++++++++ > > > 1 file changed, 96 insertions(+) > > > > OK for this part, thanks.