From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id EfvLMEyesl88YwAAWB0awg (envelope-from ) for ; Mon, 16 Nov 2020 10:44:12 -0500 Received: by simark.ca (Postfix, from userid 112) id BE5D51F08B; Mon, 16 Nov 2020 10:44:12 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RDNS_NONE,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.2 Received: from sourceware.org (unknown [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 6F5FC1E552 for ; Mon, 16 Nov 2020 10:44:12 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 1D906395CC02; Mon, 16 Nov 2020 15:44:12 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1D906395CC02 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1605541452; bh=3FX7JeXwfK8RqSpChBx4mGZODJvdSSQ5Bf5rcTBHLKU=; 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=gfvLk8dHRMTBcLHLVVZOmZKNEgAlc6uQCUM5YcwB5OWQF+QFwffjYad7J9/hVfF2m +jlkn5+9askif0r9qySssrQy3tODnZWtDhVv5RPBij0WJgQ8KZt0Fq23Q8vJWRfYie m6dX9w5+Gz9+hM//0ycw5/sbyLgrG0gyDdUHgnsk= Received: from mail-vk1-xa42.google.com (mail-vk1-xa42.google.com [IPv6:2607:f8b0:4864:20::a42]) by sourceware.org (Postfix) with ESMTPS id 0DFC5385783C for ; Mon, 16 Nov 2020 15:44:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 0DFC5385783C Received: by mail-vk1-xa42.google.com with SMTP id e8so3810525vkk.8 for ; Mon, 16 Nov 2020 07:44:09 -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=3FX7JeXwfK8RqSpChBx4mGZODJvdSSQ5Bf5rcTBHLKU=; b=HSRJ08a+TocbFtC3/vAR3KQ8Appx9eyHnrlCY6W0+YEXWiF2N/a95xEVe0qjlz4mlP WDv9MCxQVD8OJ8N6ONpwq89Krt44YQCgNRGdoWuke35VQukjFRapz/IX/kCXtXwCQb3t f4C4S+KykvSnxGpulCshPLdM2k4qiTg48OEHKgRbdcSJoHmtMmsrBoF8vRKvJaCaZ2UR wKoQ6v8oSQy7w0f0mUpNXeUGwFKsUYmSfnLqBotUBX6tAho61IT9OmmFj2IgPshYl9aK 0v2iRlNSlh1MdYS6Hx8+uhD64wwHcZbenBMzktJ+GEkt7kR6RHGjy8l7FDBiK8qC7qoG fkmw== X-Gm-Message-State: AOAM530mw+xDYV4me8GUAKz311Siw9e3u0aSr1pDOzvDN9QVmO1PziFQ X+CpLrJxHEtxJjNJ9c61oTJt5aMfQI6NufwZKgSnzw== X-Google-Smtp-Source: ABdhPJzGYb99ECJCXuQemaQpBvSq9+FU/aA+vzKYB7TDMy+F1hm88wv1I5k3k4XaX1SZoTs062ZafPe8MmVNdrO19s0= X-Received: by 2002:a05:6122:84f:: with SMTP id 15mr7653159vkk.25.1605541448557; Mon, 16 Nov 2020 07:44:08 -0800 (PST) MIME-Version: 1.0 References: <20201109170435.15766-1-luis.machado@linaro.org> <20201109170435.15766-17-luis.machado@linaro.org> In-Reply-To: <20201109170435.15766-17-luis.machado@linaro.org> Date: Mon, 16 Nov 2020 15:43:57 +0000 Message-ID: Subject: Re: [PATCH v3 16/24] AArch64: Report tag violation error information To: Luis Machado 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" > +aarch64_linux_report_signal_info (struct gdbarch *gdbarch, > + struct ui_out *uiout, > + enum gdb_signal siggnal) siggnal -> signal Also a nit about the formatting. Copying from 20/24 of v3: > +Memory tag violation while accessing address 0x0000fffff7ff8000 > +Allocation tag 0x0000000000000001. (I'm guessing the code to print the "Allocation tag" line lives here in some part) Would it make more sense to either not align the tag value to anything, or to align it to the size of the architecture's tag? Which would be 4 bits in this case so the same either way. On Mon, 9 Nov 2020 at 17:05, Luis Machado wrote: > > Whenever a memory tag violation occurs, we get a SIGSEGV. Additional > information can be obtained through the siginfo data structure. > > For AArch64 the Linux kernel may expose the fault address and tag > information, if we have a synchronous event. Otherwise there is > no fault address available. > > gdb/ChangeLog: > > YYYY-MM-DD Luis Machado > > * aarch64-linux-tdep.c > (aarch64_linux_report_signal_info): New function. > (aarch64_linux_init_abi): Register > aarch64_linux_report_signal_info as the report_signal_info hook. > * arch/aarch64-linux.h (SEGV_MTEAERR): Define. > (SEGV_MTESERR): Define. > --- > gdb/aarch64-linux-tdep.c | 64 ++++++++++++++++++++++++++++++++++++ > gdb/arch/aarch64-mte-linux.h | 6 ++++ > 2 files changed, 70 insertions(+) > > diff --git a/gdb/aarch64-linux-tdep.c b/gdb/aarch64-linux-tdep.c > index 39b1790263..70e180e1cb 100644 > --- a/gdb/aarch64-linux-tdep.c > +++ b/gdb/aarch64-linux-tdep.c > @@ -1626,6 +1626,67 @@ aarch64_linux_memtag_to_string (struct gdbarch *gdbarch, > return string_printf ("0x%s", phex_nz (tag, sizeof (tag))); > } > > +/* AArch64 Linux implementation of the report_signal_info gdbarch > + hook. Displays information about possible memory tag violations. */ > + > +static void > +aarch64_linux_report_signal_info (struct gdbarch *gdbarch, > + struct ui_out *uiout, > + enum gdb_signal siggnal) > +{ > + struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch); > + > + if (!tdep->has_mte () || siggnal != GDB_SIGNAL_SEGV) > + return; > + > + CORE_ADDR fault_addr = 0; > + long si_code = 0; > + > + try > + { > + /* Sigcode tells us if the segfault is actually a memory tag > + violation. */ > + si_code = parse_and_eval_long ("$_siginfo.si_code\n"); > + > + fault_addr > + = parse_and_eval_long ("$_siginfo._sifields._sigfault.si_addr"); > + } > + catch (const gdb_exception &exception) > + { > + return; > + } > + > + /* If this is not a memory tag violation, just return. */ > + if (si_code != SEGV_MTEAERR && si_code != SEGV_MTESERR) > + return; > + > + uiout->text ("\n"); > + > + uiout->field_string ("sigcode-meaning", _("Memory tag violation")); > + > + /* For synchronous faults, show additional information. */ > + if (si_code == SEGV_MTESERR) > + { > + uiout->text (_(" while accessing address ")); > + uiout->field_core_addr ("fault-addr", gdbarch, fault_addr); > + uiout->text ("\n"); > + > + CORE_ADDR atag; > + if (aarch64_linux_get_atag (fault_addr, &atag) != 0) > + uiout->text (_("Allocation tag unavailable")); > + else > + { > + uiout->text (_("Allocation tag ")); > + uiout->field_core_addr ("allocation-tag", gdbarch, atag); > + } > + } > + else > + { > + uiout->text ("\n"); > + uiout->text (_("Fault address unavailable")); > + } > +} > + > static void > aarch64_linux_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch) > { > @@ -1706,6 +1767,9 @@ aarch64_linux_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch) > > /* Register a hook for converting a memory tag to a string. */ > set_gdbarch_memtag_to_string (gdbarch, aarch64_linux_memtag_to_string); > + > + set_gdbarch_report_signal_info (gdbarch, > + aarch64_linux_report_signal_info); > } > > /* Initialize the aarch64_linux_record_tdep. */ > diff --git a/gdb/arch/aarch64-mte-linux.h b/gdb/arch/aarch64-mte-linux.h > index 5c5783f28b..a5a980ed49 100644 > --- a/gdb/arch/aarch64-mte-linux.h > +++ b/gdb/arch/aarch64-mte-linux.h > @@ -35,6 +35,12 @@ > #define MTE_LOGICAL_TAG_START_BIT 56 > #define MTE_LOGICAL_MAX_VALUE 0xf > > +/* Memory tagging definitions. */ > +#ifndef SEGV_MTEAERR > +# define SEGV_MTEAERR 8 > +# define SEGV_MTESERR 9 > +#endif > + > /* Return the number of tag granules in the memory range > [ADDR, ADDR + LEN) given GRANULE_SIZE. */ > extern size_t get_tag_granules (CORE_ADDR addr, size_t len, > -- > 2.17.1 >