From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 39512 invoked by alias); 21 Apr 2017 20:45:52 -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 39449 invoked by uid 89); 21 Apr 2017 20:45:49 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=critical, signing X-HELO: aserp1050.oracle.com Received: from aserp1050.oracle.com (HELO aserp1050.oracle.com) (141.146.126.70) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 21 Apr 2017 20:45:46 +0000 Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by aserp1050.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v3LEhhdm002913 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Fri, 21 Apr 2017 14:43:43 GMT Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v3LEhb3R003736 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 21 Apr 2017 14:43:38 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v3LEhbbO006085 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 21 Apr 2017 14:43:37 GMT Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id v3LEhabF021255; Fri, 21 Apr 2017 14:43:37 GMT Received: from [10.175.225.171] (/10.175.225.171) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 21 Apr 2017 07:43:36 -0700 Subject: Re: [Patch] New gdbarch method "dwarf_cfa_op" and migrate SPARC to it To: GDB References: From: Ivo Raisr Cc: Jiong Wang Message-ID: Date: Fri, 21 Apr 2017 20:45:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2017-04/txt/msg00620.txt.bz2 On 19.4.2017 12:17, Jiong Wang wrote: > Hi, > > Recently a feature called "return address signing" has been added to GCC to > prevent stack smash stack on AArch64. For details please refer: > > https://gcc.gnu.org/ml/gcc-patches/2017-01/msg00376.html > > GDB needs to be aware of this feature so it can restore the original return > address which is critical for unwinding. > > On compiler side, whenever return address, i.e. LR register, is mangled or > restored by hardware instruction, compiler is expected to generate a > DW_CFA_GNU_window_save CFA instruction to toggle the LR signing status. > DW_CFA_GNU_window_save was introduced by SPARC for their register window > feature, here AArch64 want to multiplex this DWARF CFA instruction as > it's in vendor space. So, a new gdbarch method, dwarf_cfa_op, is introduced. Are you sure to reuse DW_CFA_GNU_window_save for AArch64 purposes? Because semantics of DW_CFA_GNU_window_save (implied from "window save") mean much more than just fiddling with return address. For example as you learned from dwarf2-frame.c, whole register window needs to be copied. > SPARC-linux cross gdb build OK. I have built gdb on sparc64-linux with your changes and no new regressions are introduced in the test suite. So the patch is ok w.r.t. this. I.