From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14759 invoked by alias); 7 Aug 2019 19:24:50 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 14672 invoked by uid 89); 7 Aug 2019 19:24:44 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-26.9 required=5.0 tests=BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=awareness X-HELO: mail-wm1-f66.google.com Received: from mail-wm1-f66.google.com (HELO mail-wm1-f66.google.com) (209.85.128.66) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 07 Aug 2019 19:24:43 +0000 Received: by mail-wm1-f66.google.com with SMTP id s3so14099wms.2 for ; Wed, 07 Aug 2019 12:24:42 -0700 (PDT) Return-Path: Received: from ?IPv6:2001:8a0:f913:f700:56ee:75ff:fe8d:232b? ([2001:8a0:f913:f700:56ee:75ff:fe8d:232b]) by smtp.gmail.com with ESMTPSA id o20sm233092634wrh.8.2019.08.07.12.24.39 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Wed, 07 Aug 2019 12:24:40 -0700 (PDT) Subject: Re: [PATCH V2] AArch64 pauth: Indicate unmasked addresses in backtrace To: Alan Hayward , "gdb-patches@sourceware.org" References: <20190730144123.11135-1-alan.hayward@arm.com> Cc: nd From: Pedro Alves Message-ID: <728af5fa-8e3d-845c-d72f-60b1d2067643@redhat.com> Date: Wed, 07 Aug 2019 19:24:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <20190730144123.11135-1-alan.hayward@arm.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2019-08/txt/msg00181.txt.bz2 On 7/30/19 3:41 PM, Alan Hayward wrote: > diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo > index 0fcd131f71..b7dba2f918 100644 > --- a/gdb/doc/gdb.texinfo > +++ b/gdb/doc/gdb.texinfo > @@ -24380,6 +24380,14 @@ but the lengths of the @code{z} and @code{p} registers will not change. This > is a known limitation of @value{GDBN} and does not affect the execution of the > target process. > > +@subsubsection AArch64 Pointer Authentication. > +@cindex AArch64 Pointer Authentication. > + > +When @value{GDBN} is debugging the AArch64 architecture, and the program is > +using the v8.3-A feature Pointer Authentication (PAC), then whenever the link > +register @code{$lr} is pointing to an PAC function it's value will be masked. s/it's value/its value/ > +When GDB prints a backtrace, any addresses that required unmasking will be > +postfixed with the marker [PAC]. > > diff --git a/gdb/python/py-framefilter.c b/gdb/python/py-framefilter.c > index a2a96ac0d3..d805ec68f2 100644 > --- a/gdb/python/py-framefilter.c > +++ b/gdb/python/py-framefilter.c > @@ -901,6 +901,8 @@ py_print_frame (PyObject *filter, frame_filter_flags flags, > { > annotate_frame_address (); > out->field_core_addr ("addr", gdbarch, address); > + if (get_frame_pc_masked (frame)) > + out->field_string ("pac", " [PAC]"); > annotate_frame_address_end (); > out->text (" in "); > } > diff --git a/gdb/stack.c b/gdb/stack.c > index 7833ca4aeb..9d49809895 100644 > --- a/gdb/stack.c > +++ b/gdb/stack.c > @@ -1298,7 +1298,11 @@ print_frame (const frame_print_options &fp_opts, > { > annotate_frame_address (); > if (pc_p) > - uiout->field_core_addr ("addr", gdbarch, pc); > + { > + uiout->field_core_addr ("addr", gdbarch, pc); > + if (get_frame_pc_masked (frame)) > + uiout->field_string ("pac", " [PAC]"); Hmm, I had suggested considering MI in the previous iteration, but I was just thinking of including the "[PAC]" text in the "addr" field. If we're adding a new field, then a few extra things need to be considered: #1 - documentation, both manual and NEWS should mention this new MI field. #2 - calling the attribute "pac" makes it architecture specific. I.e., to make use of it, a frontend will have to have Aarch64 awareness? Not sure that is a good thing. #3 - The MI attribute is called "pac", and its content is literally " [PAC]". I'd find that odd if I were a frontend author: the content is right aligned with a space, making doing anything with it other than appending it to the address text probably look odd, unless you bake in awareness of the attribute's text... If I saw an attribute named "pac", I'd expect it to be a boolean? At the least, the left space should not be part of the field, I think? Maybe we should rename the field to something else, like "addr_attr" for "address attributes" or something. Thanks, Pedro Alves