From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32222 invoked by alias); 17 Jul 2019 15:02:05 -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 32214 invoked by uid 89); 17 Jul 2019 15:02:05 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.1 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy=H*u:1.3.6, H*UA:1.3.6, UD:ca, simon X-HELO: smtp.polymtl.ca Received: from smtp.polymtl.ca (HELO smtp.polymtl.ca) (132.207.4.11) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 17 Jul 2019 15:02:04 +0000 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id x6HF1ttC031821 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 17 Jul 2019 11:02:01 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca x6HF1ttC031821 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=polymtl.ca; s=default; t=1563375721; bh=q7vdITE47iUzHBT4PujoAi9BVimyv/ef5EXvAzU4pd8=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=B+PBbQNpwUKsT4dcsyKKYzO7iCWKxK6ZMgHLIfTpwrpkf0E2NFaKByCE38rYtJbEt XTyqpSdIwUXf27BilBUPf0fLGLvV3yvHW9PjhksA7cBdo3BRHYDcAuOUDRpNSlYXe+ 611bt6dPHb0GNjZwuhwL06wbTZXPXvhVVmxG5zVY= Received: by simark.ca (Postfix, from userid 112) id 3B00C1EE70; Wed, 17 Jul 2019 11:01:55 -0400 (EDT) Received: from simark.ca (localhost [127.0.0.1]) by simark.ca (Postfix) with ESMTP id C13321E015; Wed, 17 Jul 2019 11:01:53 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Wed, 17 Jul 2019 15:02:00 -0000 From: Simon Marchi To: Alan Hayward Cc: Pedro Alves , gdb-patches@sourceware.org, nd Subject: Re: [PATCH] AArch64 pauth: Indicate unmasked addresses in backtrace In-Reply-To: <68E9D3EF-D6A5-44C9-A87C-916EC6970435@arm.com> References: <20190717081336.68835-1-alan.hayward@arm.com> <68E9D3EF-D6A5-44C9-A87C-916EC6970435@arm.com> Message-ID: X-Sender: simon.marchi@polymtl.ca User-Agent: Roundcube Webmail/1.3.6 X-IsSubscribed: yes X-SW-Source: 2019-07/txt/msg00390.txt.bz2 On 2019-07-17 09:35, Alan Hayward wrote: >> On 17 Jul 2019, at 12:15, Pedro Alves wrote: >> >> On 7/17/19 9:14 AM, Alan Hayward wrote: >>> Armv8.3-a Pointer Authentication causes the function return address >>> to be >>> obfuscated on entry to some functions. GDB must unmask the link >>> register in >>> order to produce a backtrace. >>> >>> The following patch adds markers of to the bracktrace, to >>> indicate >>> which addresses needed unmasking. >>> >>> For example, consider the following backtrace: >>> >>> (gdb) bt >>> 0 0x0000000000400490 in puts@plt () >>> 1 0x00000000004005dc in foo ("hello") at cbreak-lib.c:6 >>> 2 0x0000000000400604 in bar () at cbreak-lib.c:12 >>> 3 0x0000000000400620 in barbar () at cbreak.c:17 >>> 4 0x00000000004005b4 in main () at cbreak-3.c:10 >>> >>> The functions in the cbreak-lib use pointer auth, obfuscating the >>> return address >>> to the previous function. The caused the addresses of bar and barbar >>> to require >>> unmasking in order to unwind the backtrace. >>> >>> Alternatively, I considered replacing with a single >>> chracter, such >>> as * for brevity reasons, but felt this would be non obvious for the >>> user. >> >> I don't have a particular suggestion, though my first reaction was >> that >> it seemed a bit verbose. >> >> IMHO, the marker doesn't have to stand out and be expressive, since >> users can >> always look at the manual. > > Reading the manual is an assumption I’m not sure is anywhere near the > common case. > Saying that, I agree we shouldn’t be designing the output for the > non-readers. > > This comment has reminded me I need to add something to the manual as > part of this > patch. > > >> Once they learn something, often being concise >> helps -- or in other words, once you learn what "" or "U" or >> whatever >> is, and you're used to it, what would you rather see? What's the main >> information you're looking for when staring at the backtrace? >> Thoughts >> like that should guide the output too, IMO. > > PAC is the official abbreviation for the feature, so maybe :PAC works > best. > > (gdb) bt > 0 0x0000000000400490 in puts@plt () > 1 0x00000000004005dc in foo ("hello") at cbreak-lib.c:6 > 2 0x0000000000400604:PAC in bar () at cbreak-lib.c:12 > 3 0x0000000000400620:PAC in barbar () at cbreak.c:17 > 4 0x00000000004005b4 in main () at cbreak-3.c:10 > > > Some of my attempts at different representations: > 2 0x0000000000400604* in bar () at cbreak-lib.c:12 > 2 0x0000000000400604! in bar () at cbreak-lib.c:12 > 2 0x0000000000400604U in bar () at cbreak-lib.c:122 > 2 0x0000000000400604:U in bar () at cbreak-lib.c:122 > 2 0x0000000000400604 in bar () at cbreak-lib.c:12 > 2 0x0000000000400604[U] in bar () at cbreak-lib.c:12 > 2 0x0000000000400604 in bar () at cbreak-lib.c:12 > 2 0x0000000000400604

in bar () at cbreak-lib.c:12 > 2 0x0000000000400604 in bar () at cbreak-lib.c:12 > 2 0x0000000000400604PAC in bar () at cbreak-lib.c:12 > 2 0x0000000000400604:PAC in bar () at cbreak-lib.c:12 > 2 0x0000000000400604,PAC in bar () at cbreak-lib.c:12 > > I found a single character was too hidden. A single character or symbol > was also > a little confusing - my brain read U as unsigned, * as pointer, [] as > an array. > > I also like ,PAC as it might be easier to add future extensions. It might not be easily doable, but I think it would be nice if you could somehow make it so the function names stay aligned (regardless of which marker you end up choosing), like: 0 0x0000000000400490 in puts@plt () 1 0x00000000004005dc in foo ("hello") at cbreak-lib.c:6 2 0x0000000000400604 [U] in bar () at cbreak-lib.c:12 3 0x0000000000400620 [U] in barbar () at cbreak.c:17 4 0x00000000004005b4 in main () at cbreak-3.c:10 Simon