Message ID | F3D7A960-329A-4BDA-A251-87828CF3E459@arm.com |
---|---|
State | New, archived |
Headers |
Received: (qmail 93565 invoked by alias); 8 Aug 2019 08:55:50 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <gdb-patches.sourceware.org> List-Unsubscribe: <mailto:gdb-patches-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/gdb-patches/> List-Post: <mailto:gdb-patches@sourceware.org> List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 93554 invoked by uid 89); 8 Aug 2019 08:55:50 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-23.8 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.3.1 spammy= X-HELO: EUR02-HE1-obe.outbound.protection.outlook.com Received: from mail-eopbgr10074.outbound.protection.outlook.com (HELO EUR02-HE1-obe.outbound.protection.outlook.com) (40.107.1.74) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 08 Aug 2019 08:55:47 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/7N4gmSAyYVHKuh4htSNeskNjkM5ZxTR6lbubEtzyQo=; b=4S6UCxP0sHyQvx3nJnKTiA6wRN3tFbGm4k7F4MQDOcYxeDpywZSzJB5Ttbff6mKqjLGD0N5y45x/mPZX464qQpRLEC6+n2gl+UnA97kG2Euh/sqDADtXJFSLoDIuZ9h4+iY0AA/g2MUMXTHkEHxE5IYMO6CDXUG3vCciu1KVAfs= Received: from VI1PR0802CA0015.eurprd08.prod.outlook.com (2603:10a6:800:aa::25) by HE1PR0801MB1851.eurprd08.prod.outlook.com (2603:10a6:3:7b::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2157.18; Thu, 8 Aug 2019 08:55:42 +0000 Received: from VE1EUR03FT048.eop-EUR03.prod.protection.outlook.com (2a01:111:f400:7e09::206) by VI1PR0802CA0015.outlook.office365.com (2603:10a6:800:aa::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2157.15 via Frontend Transport; Thu, 8 Aug 2019 08:55:41 +0000 Authentication-Results: spf=temperror (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; sourceware.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com; sourceware.org; dmarc=temperror action=none header.from=arm.com; Received-SPF: TempError (protection.outlook.com: error in processing during lookup of arm.com: DNS Timeout) Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by VE1EUR03FT048.mail.protection.outlook.com (10.152.19.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2052.18 via Frontend Transport; Thu, 8 Aug 2019 08:55:40 +0000 Received: ("Tessian outbound 578a71fe5eaa:v26"); Thu, 08 Aug 2019 08:55:40 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: de0c1747553e9d31 X-CR-MTA-TID: 64aa7808 Received: from aac74f78f356.1 (cr-mta-lb-1.cr-mta-net [104.47.14.55]) by 64aa7808-outbound-1.mta.getcheckrecipient.com id FC5D62B4-7D80-4B0A-8441-DEB8B09A6AEA.1; Thu, 08 Aug 2019 08:55:35 +0000 Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-vi1eur04lp2055.outbound.protection.outlook.com [104.47.14.55]) by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id aac74f78f356.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384); Thu, 08 Aug 2019 08:55:35 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OISXCkBleEuFXrtmL2RPtKsNyhU92+X7LSb4EKrWK/t8Cm73Bm2KDxF9PaHoT3IrVGri5zjYXrKeMDub6CgGyEviftyM319QkS61EJZRCH5R2RqR91TYfyMN1A4kBDXHA1PBTj823aVPdWD9mgv/W58UGaIfl3z7zU63lkvbFIjQLLm87QWiJcggnP8Y7VNF5EUwKRfW7+W1f2GcRc+jPxyLDwXZu93KUrnPB97Crz6G4O1SyQzut7ApErQpdE0yLbgbdCmS/JzMdXJMPkucsSP+bREkI4Y1YZplxOFfO13nGI/HZXVu724bcP43XW2LBugBBR9C9P1Pj0ktQOWGkA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/7N4gmSAyYVHKuh4htSNeskNjkM5ZxTR6lbubEtzyQo=; b=eVujo3vnJJ5KMAe6tXuN7RuWMRpbIO4ofqKV4GsYNs5zZjtZy3WHdX8cc033GneQkCLuhZCjPmpYhryi73qH1321GNJ0LGIeM3k/4HD7CLd4j4PJkFPwmZ70Qy8+dGfKuNorb8Mqm5hVlGS1u2fZ/wtmSQKkD3KBAej/Hjv0/b1mm8HJsVY7w1gG/1t3b2yU990iPitEVwPNoiPaxCkkphFOK4ZW+GQWKXSD5sCmvcEHe1NaR7rYSHZlfYzQVazEn30KlFQrHQ7svxPQiaAKqG3sMuMpyEOHYIZ87Sk/N5wHnRjJ0h3vgvMoI/cov3C07i7DXVpAb5t+yeD5CSaTcA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/7N4gmSAyYVHKuh4htSNeskNjkM5ZxTR6lbubEtzyQo=; b=4S6UCxP0sHyQvx3nJnKTiA6wRN3tFbGm4k7F4MQDOcYxeDpywZSzJB5Ttbff6mKqjLGD0N5y45x/mPZX464qQpRLEC6+n2gl+UnA97kG2Euh/sqDADtXJFSLoDIuZ9h4+iY0AA/g2MUMXTHkEHxE5IYMO6CDXUG3vCciu1KVAfs= Received: from DB6PR0802MB2133.eurprd08.prod.outlook.com (10.172.227.22) by DB6PR0802MB2295.eurprd08.prod.outlook.com (10.172.227.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2157.15; Thu, 8 Aug 2019 08:55:33 +0000 Received: from DB6PR0802MB2133.eurprd08.prod.outlook.com ([fe80::5ce5:cf42:42dd:eda1]) by DB6PR0802MB2133.eurprd08.prod.outlook.com ([fe80::5ce5:cf42:42dd:eda1%6]) with mapi id 15.20.2136.022; Thu, 8 Aug 2019 08:55:33 +0000 From: Alan Hayward <Alan.Hayward@arm.com> To: Pedro Alves <palves@redhat.com> CC: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>, nd <nd@arm.com> Subject: Re: [PATCH V2] AArch64 pauth: Indicate unmasked addresses in backtrace Date: Thu, 8 Aug 2019 08:55:33 +0000 Message-ID: <F3D7A960-329A-4BDA-A251-87828CF3E459@arm.com> References: <20190730144123.11135-1-alan.hayward@arm.com> <728af5fa-8e3d-845c-d72f-60b1d2067643@redhat.com> In-Reply-To: <728af5fa-8e3d-845c-d72f-60b1d2067643@redhat.com> Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Alan.Hayward@arm.com; X-Microsoft-Antispam-Untrusted: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:DB6PR0802MB2295; x-checkrecipientrouted: true x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009020)(4636009)(376002)(136003)(346002)(39860400002)(366004)(396003)(54534003)(189003)(199004)(316002)(446003)(102836004)(54906003)(476003)(66946007)(76176011)(11346002)(6436002)(2616005)(6486002)(6506007)(66446008)(53546011)(486006)(5660300002)(64756008)(66476007)(2906002)(36756003)(99286004)(256004)(76116006)(26005)(6916009)(66556008)(25786009)(81156014)(91956017)(229853002)(6246003)(6512007)(186003)(8936002)(33656002)(81166006)(50226002)(53936002)(4326008)(71190400001)(7736002)(8676002)(71200400001)(478600001)(86362001)(305945005)(66066001)(57306001)(14454004)(3846002)(6116002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6PR0802MB2295; H:DB6PR0802MB2133.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info-Original: XAFAQn5iseQ92Wm8Q9lFIlYjvTTtsU0WlMtbM8jPPhNB7FEte6aWN1SHpzophwB9RCOErk52T38u3nLi+qxn/4ICBD9iw/pSoS/chZoHScGYDJfH158vEd6s3LfuDXpLdnpJcRXA6MFat8Gv+mf1GzaAXnW5rEMx1zWyUVu+zDhs9RhuwRovUiFptFCG85ys82XgcryjmX2ieva4jdyEzS2X4nKdZxtbBBxCack5JkdUdP0Wjmux5mqstTfMIXh7dBedEbTMjGnE2rDyqKkXTKtg4xSGHvVGKr9mw/Z+Rn3JRfnM24R5Ns+mqQl9yt3Q71L+xwgSx1MyxP+slvOuTtomhItFqmCaXX9yg83xyp0A/ESXmSEAzZ5s1QQ4dBsIsuGFDTF/HJtx4HlZhV6li/mVL39rHQxJcSU/JGYDDyM= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <4066F06DB491AF4C948568774DD7FE66@eurprd08.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Alan.Hayward@arm.com; Return-Path: Alan.Hayward@arm.com X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT048.eop-EUR03.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: 0e2850e1-8de2-4e47-5905-08d71bde2c48 X-IsSubscribed: yes |
Commit Message
Alan Hayward
Aug. 8, 2019, 8:55 a.m. UTC
> On 7 Aug 2019, at 20:24, Pedro Alves <palves@redhat.com> wrote: > > 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. I hadn’t realised the implications doing that would have, and had assumed you couldn’t add to a field that had already been used. I had (prematurely) pushed the patch. Is this additional fix ok? Alan. Move backtrace PAC marker into addr field PAC does not need its own field and should instead be part of the addr field. gdb/ChangeLog: 2019-08-08 Alan Hayward <alan.hayward@arm.com> * stack.c (print_frame): Move PAC into addr field. gdb/doc/ChangeLog: 2019-08-08 Alan Hayward <alan.hayward@arm.com> * gdb.texinfo (AArch64 Pointer Authentication): Fix typo.
Comments
On 8/8/19 9:55 AM, Alan Hayward wrote: > gdb/doc/ChangeLog: > > 2019-08-08 Alan Hayward <alan.hayward@arm.com> > > * gdb.texinfo (AArch64 Pointer Authentication): Fix typo. Please merge this part as obvious. > I hadn’t realised the implications doing that would have, and had assumed > you couldn’t add to a field that had already been used. > > I had (prematurely) pushed the patch. Is this additional fix ok? I don't think so, > diff --git a/gdb/stack.c b/gdb/stack.c > index 0859815baf..c599caf51c 100644 > --- a/gdb/stack.c > +++ b/gdb/stack.c > @@ -1301,7 +1301,7 @@ print_frame (const frame_print_options &fp_opts, > { > uiout->field_core_addr ("addr", gdbarch, pc); > if (get_frame_pc_masked (frame)) > - uiout->field_string ("pac", " [PAC]"); > + uiout->field_string ("addr", " [PAC]"); > } > else > uiout->field_string ("addr", "<unavailable>", > ... because I think that this results in MI printing two different "addr" attributes. Instead, you'll need to build a string, with e.g., string_printf, and use uiout->field_string with ui_out_style_kind::ADDRESS style, so that MI outputs one single "addr" attribute. Please try "gdb -i=mi". You can still type CLI commands, so just "(gdb) start" and running to main, so that GDB prints the frame in the *stop event should be sufficient to trigger this. BTW, there are two other places where we output the "addr" field in the file. Do you want to include "[PAC]" in those? If so, then factoring out the "addr" printing to a separate function would be appropriate. Thanks, Pedro Alves
> On 8 Aug 2019, at 11:33, Pedro Alves <palves@redhat.com> wrote: > > On 8/8/19 9:55 AM, Alan Hayward wrote: > >> diff --git a/gdb/stack.c b/gdb/stack.c >> index 0859815baf..c599caf51c 100644 >> --- a/gdb/stack.c >> +++ b/gdb/stack.c >> @@ -1301,7 +1301,7 @@ print_frame (const frame_print_options &fp_opts, >> { >> uiout->field_core_addr ("addr", gdbarch, pc); >> if (get_frame_pc_masked (frame)) >> - uiout->field_string ("pac", " [PAC]"); >> + uiout->field_string ("addr", " [PAC]"); >> } >> else >> uiout->field_string ("addr", "<unavailable>", >> > > ... because I think that this results in MI printing two different "addr" attributes. > > Instead, you'll need to build a string, with e.g., string_printf, > and use uiout->field_string with ui_out_style_kind::ADDRESS style, > so that MI outputs one single "addr" attribute. > > Please try "gdb -i=mi". You can still type CLI commands, so just "(gdb) start" > and running to main, so that GDB prints the frame in the *stop event should > be sufficient to trigger this. stop doesn’t trigger a PAC because it’s only once we reference a function via the link register that the PAC unmasking happens. However, selecting a previous frame does.... and the issues are obvious now: =thread-selected,id="1",frame={level="1",addr="0x00000000004005b0",pac=" [PAC]",func="main3",args=[],file="cbreak-3.c",fullname="/root/cbreak-3.c",line="9",arch="aarch64"} > > BTW, there are two other places where we output the "addr" field > in the file. Do you want to include "[PAC]" in those? If so, > then factoring out the "addr" printing to a separate function > would be appropriate. > Ok, I can do that. > On 8 Aug 2019, at 17:58, Tom Tromey <tom@tromey.com> wrote: > >>>>>> "Pedro" == Pedro Alves <palves@redhat.com> writes: > > Pedro> Hmm, I had suggested considering MI in the previous iteration, but > Pedro> I was just thinking of including the "[PAC]" text in the > Pedro> "addr" field. If we're adding a new field, then a few extra > Pedro> things need to be considered: > > Pedro> #1 - documentation, both manual and NEWS should mention this new MI field. > > Oops, I forgot about this. Sorry about that. I’ll add something. > > I don't think putting this information into the "addr" field is a good > idea. It's better, IMO, to let MI field names provide the structure, > rather than requiring clients to also parse the values of fields. > > I realize MI isn't 100% clean on this topic, but we can still not make > it worse. > > Pedro> #2 - calling the attribute "pac" makes it architecture specific. > > I don't think this is such a big deal but at the same time any > reasonable name is fine by me. > > Pedro> #3 - The MI attribute is called "pac", and its content is > Pedro> literally " [PAC]". I'd find that odd if I were a frontend author: > Pedro> the content is right aligned with a space, making doing anything with > Pedro> it other than appending it to the address text probably look odd, > Pedro> unless you bake in awareness of the attribute's text... If I saw > Pedro> an attribute named "pac", I'd expect it to be a boolean? At the > Pedro> least, the left space should not be part of the field, I think? > > I think part of the pain here is an internal constraint, namely that the > CLI ui-out wouldn't know to rewrite the boolean value to something else > here. But perhaps that's something that could just be addressed > directly. It looks like fixing the space just requires an additional call to uiout->text (" “). How about I create a new field addr_flags? It would be a generic field into which targets can add whichever fields they want to. I then could add a call to a new function gdbarch_print_addr_flags() which prints the PAC on AArch64 and nothing on all other targets? Alan.
On 8/9/19 2:22 PM, Alan Hayward wrote: > It looks like fixing the space just requires an additional call to uiout->text (" “). > > > How about I create a new field addr_flags? It would be a generic field into which > targets can add whichever fields they want to. > > I then could add a call to a new function gdbarch_print_addr_flags() which prints the > PAC on AArch64 and nothing on all other targets? That sounds like two different things. You could have the gdbarch method without the uiout field. Not sure what the uiout field buys you. If CLI and MI are going to print the same way, then it doesn't appear useful over field_string. The gdbarch method sounds fine. Thanks, Pedro Alves
> On 9 Aug 2019, at 15:17, Pedro Alves <palves@redhat.com> wrote: > > On 8/9/19 2:22 PM, Alan Hayward wrote: >> It looks like fixing the space just requires an additional call to uiout->text (" “). >> >> >> How about I create a new field addr_flags? It would be a generic field into which >> targets can add whichever fields they want to. >> >> I then could add a call to a new function gdbarch_print_addr_flags() which prints the >> PAC on AArch64 and nothing on all other targets? > > That sounds like two different things. You could have the gdbarch method without > the uiout field. Not sure what the uiout field buys you. If CLI and MI are going to > print the same way, then it doesn't appear useful over field_string. The gdbarch > method sounds fine. > I was thinking of the following: char *flags = gdbarch_print_pc_addr_flags(frame, pc); /* Returns null or “PAC” or “FOO,BAR” etc */ if (flags) { uiout->text (“ [“); uiout->field_string (“addr_flags", flags); uiout->text (“]“); } addr_flags can be printed by any target that wishes. And PAC only needs to be in AArch64 specifics. Alan.
On 8/9/19 3:46 PM, Alan Hayward wrote: > I was thinking of the following: Ah, I thought you meant create a "uiout->field_addr_flags(...);" method. > > char *flags = gdbarch_print_pc_addr_flags(frame, pc); /* Returns null or “PAC” or “FOO,BAR” etc */ > if (flags) > { > uiout->text (“ [“); > uiout->field_string (“addr_flags", flags); > uiout->text (“]“); > } > > addr_flags can be printed by any target that wishes. And PAC only needs to be in > AArch64 specifics. Sounds fine to me. Maybe return a std::string instead of a pointer to a static buffer. Thanks, Pedro Alves
diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo index 7f8c0aff1c..c8ca757989 100644 --- a/gdb/doc/gdb.texinfo +++ b/gdb/doc/gdb.texinfo @@ -24395,7 +24395,7 @@ target process. 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. +register @code{$lr} is pointing to an PAC function its value will be masked. When GDB prints a backtrace, any addresses that required unmasking will be postfixed with the marker [PAC]. diff --git a/gdb/stack.c b/gdb/stack.c index 0859815baf..c599caf51c 100644 --- a/gdb/stack.c +++ b/gdb/stack.c @@ -1301,7 +1301,7 @@ print_frame (const frame_print_options &fp_opts, { uiout->field_core_addr ("addr", gdbarch, pc); if (get_frame_pc_masked (frame)) - uiout->field_string ("pac", " [PAC]"); + uiout->field_string ("addr", " [PAC]"); } else uiout->field_string ("addr", "<unavailable>",