From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id /GLbFhDUml9rCQAAWB0awg (envelope-from ) for ; Thu, 29 Oct 2020 10:39:12 -0400 Received: by simark.ca (Postfix, from userid 112) id 48F661EFC1; Thu, 29 Oct 2020 10:39:12 -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=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 22AB41E58E for ; Thu, 29 Oct 2020 10:39:11 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 274D13850418; Thu, 29 Oct 2020 14:39:10 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 274D13850418 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1603982350; bh=ZbDjWdu+9pPyzbFX6R8M2qUi1DHDt0u5HnT6KgH2enE=; 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=ND10bVERDxuOkSmSDDhW92nGaHoDEUh26VoopPdx98DvG4lqU/SaK62i41up3kwFX LzwjL2AxmjYG4R8ca+1wMAHgjwyJM8gBQ5CMPRoOla/wdNct/nlHzCmnGI4GLYmlOS T98ESXYJPyxOxFiAPLrP7SImY6r1dK3hz7g3ohwU= Received: from mail-qv1-xf43.google.com (mail-qv1-xf43.google.com [IPv6:2607:f8b0:4864:20::f43]) by sourceware.org (Postfix) with ESMTPS id D13773861034 for ; Thu, 29 Oct 2020 14:39:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org D13773861034 Received: by mail-qv1-xf43.google.com with SMTP id s1so1387503qvm.13 for ; Thu, 29 Oct 2020 07:39:06 -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=ZbDjWdu+9pPyzbFX6R8M2qUi1DHDt0u5HnT6KgH2enE=; b=aBE27TVA2tFAqChxizOJ61aA1L0DZ8Y0EBQ1u0n8Z5/EuNflr+DOpEFNZFarlTHSHc rn7UMXn270mhNfk7UUVTBA7V+sXZ6vDE0CC+nNN9ap+UeWb5OyvWlJuWYdwy+OH+X6RN x61i2U+JL4Hof4l/lZITf6f3T9JVKRrPgT5qzWFZvttfGA04paS71gC2CA7lGHzIkc2f 8eFiAiynNqZk1i6HzHVH7n59iBmJxuXCUB3DT3uASHcazLgg4yoPK13DzUxrek/qxBZL v7YMdOa6iynIAjz2U0y7+jGBF0479ywVLkMHaldrPTlxsnR7k+fl9vObuom5nWck+NY9 cn2w== X-Gm-Message-State: AOAM531M66FF+uvLuCMpnhxKpVbmjFqj2w70KWQ5wy4lg0XCt8f2rD7N LsPcDA3lDdBshJV6R8j8mnH8/m+Yev7LAA== X-Google-Smtp-Source: ABdhPJwdcb2momMTZ5YmmxM/eCkIrDB3N/UXF2yC+Oqc51YDsRxB4YNKpo4x9AVwfHuSBitb6PXXRQ== X-Received: by 2002:ad4:54e9:: with SMTP id k9mr4597076qvx.18.1603982346187; Thu, 29 Oct 2020 07:39:06 -0700 (PDT) Received: from ?IPv6:2804:7f0:8284:1487:6a9e:2ef6:314b:f393? ([2804:7f0:8284:1487:6a9e:2ef6:314b:f393]) by smtp.gmail.com with ESMTPSA id 22sm1199903qkg.15.2020.10.29.07.39.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Oct 2020 07:39:05 -0700 (PDT) Subject: Re: [PATCH v2 12/24] AArch64: Implement memory tagging target methods for AArch64 To: Alan Hayward References: <20201022200014.5189-1-luis.machado@linaro.org> <20201022200014.5189-13-luis.machado@linaro.org> Message-ID: <56baf1d1-2bdd-f921-9f35-2ed209504cf4@linaro.org> Date: Thu, 29 Oct 2020 11:39:01 -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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit 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" , nd , "gdb-patches\\@sourceware.org" Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" On 10/29/20 11:21 AM, Alan Hayward wrote: > > >> On 22 Oct 2020, at 21:00, Luis Machado wrote: >> >> Updates on v2: >> >> - Added type parameter to the target method implementations. >> >> -- >> >> The patch implements the memory tagging target hooks for AArch64, so we >> can handle MTE. >> >> gdb/ChangeLog: >> >> YYYY-MM-DD Luis Machado >> >> * Makefile.in (ALL_64_TARGET_OBS): Add arch/aarch64-mte-linux.o. >> (HFILES_NO_SRCDIR): Add arch/aarch64-mte-linux.h and >> nat/aarch64-mte-linux-ptrace.h. >> * aarch64-linux-nat.c: Include nat/aarch64-mte-linux-ptrace.h. >> (aarch64_linux_nat_target) : New method >> override. >> : New method override. >> : New method override. >> (aarch64_linux_nat_target::supports_memory_tagging): New method. >> (aarch64_linux_nat_target::fetch_memtags): New method. >> (aarch64_linux_nat_target::store_memtags): New method. >> * arch/aarch64-mte-linux.c: New file. >> * arch/aarch64-mte-linux.h: Include gdbsupport/common-defs.h. >> (MTE_GRANULE_SIZE): Define. >> (get_tag_granules): New prototype. >> * configure.nat (NATDEPFILES): Add nat/aarch64-mte-linux-ptrace.o. >> * configure.tgt (aarch64*-*-linux*): Add arch/aarch64-mte-linux.o. >> * nat/aarch64-mte-linux-ptrace.c: New file. >> * nat/aarch64-mte-linux-ptrace.h: New file. >> --- >> gdb/Makefile.in | 1 + >> gdb/aarch64-linux-nat.c | 50 ++++++++ >> gdb/arch/aarch64-mte-linux.c | 34 +++++ >> gdb/arch/aarch64-mte-linux.h | 10 ++ >> gdb/configure.nat | 3 +- >> gdb/configure.tgt | 1 + >> gdb/nat/aarch64-mte-linux-ptrace.c | 200 +++++++++++++++++++++++++++++ >> gdb/nat/aarch64-mte-linux-ptrace.h | 17 +++ >> 8 files changed, 315 insertions(+), 1 deletion(-) >> create mode 100644 gdb/arch/aarch64-mte-linux.c >> create mode 100644 gdb/nat/aarch64-mte-linux-ptrace.c >> >> diff --git a/gdb/Makefile.in b/gdb/Makefile.in >> index 8c9e6c9f6c..33a08a2288 100644 >> --- a/gdb/Makefile.in >> +++ b/gdb/Makefile.in >> @@ -692,6 +692,7 @@ ALL_64_TARGET_OBS = \ >> amd64-windows-tdep.o \ >> arch/aarch64.o \ >> arch/aarch64-insn.o \ >> + arch/aarch64-mte-linux.o \ >> arch/amd64.o \ >> ia64-linux-tdep.o \ >> ia64-tdep.o \ >> diff --git a/gdb/aarch64-linux-nat.c b/gdb/aarch64-linux-nat.c >> index dea34da669..4edf5a0454 100644 >> --- a/gdb/aarch64-linux-nat.c >> +++ b/gdb/aarch64-linux-nat.c >> @@ -52,6 +52,8 @@ >> >> #include "arch/aarch64-mte-linux.h" >> >> +#include "nat/aarch64-mte-linux-ptrace.h" >> + >> #ifndef TRAP_HWBKPT >> #define TRAP_HWBKPT 0x0004 >> #endif >> @@ -102,6 +104,16 @@ class aarch64_linux_nat_target final : public linux_nat_target >> override; >> >> struct gdbarch *thread_architecture (ptid_t) override; >> + >> + bool supports_memory_tagging () override; >> + >> + /* Read memory allocation tags from memory via PTRACE. */ >> + int fetch_memtags (CORE_ADDR address, size_t len, >> + gdb::byte_vector &tags, int type) override; >> + >> + /* Write allocation tags to memory via PTRACE. */ >> + int store_memtags (CORE_ADDR address, size_t len, >> + const gdb::byte_vector &tags, int type) override; >> }; >> >> static aarch64_linux_nat_target the_aarch64_linux_nat_target; >> @@ -1050,6 +1062,44 @@ aarch64_linux_nat_target::thread_architecture (ptid_t ptid) >> return gdbarch_find_by_info (info); >> } >> >> +/* Implement the "supports_memory_tagging" target_ops method. */ >> + >> +bool >> +aarch64_linux_nat_target::supports_memory_tagging () >> +{ >> + return (linux_get_hwcap2 (this) & HWCAP2_MTE) != 0; >> +} >> + >> +/* Implement the "fetch_memtags" target_ops method. */ >> + >> +int >> +aarch64_linux_nat_target::fetch_memtags (CORE_ADDR address, size_t len, >> + gdb::byte_vector &tags, int type) > > I’m a little unsure as to where the type is coming from. Who in the call stack > is explicitly passing the value 1? Someone invoking the target methods directly or invoking the gdbarch hooks. For example, in gdb/printcmd.c: if (gdbarch_set_memtags (target_gdbarch (), val, 0, tags, tag_logical) != 0) Or: std::string tag = gdbarch_memtag_to_string (target_gdbarch (), val, tag_type); > It’s different from the LOGICAL and ALLOCATION enum values used elsewhere? No. Just a different type (int). The remote layer shouldn't try to interpret these tag types though. It should just forward them to the other side.