From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx08-00271601.pphosted.com (mx08-00271601.pphosted.com [62.209.51.218]) by sourceware.org (Postfix) with ESMTPS id 1A772398601C for ; Thu, 10 Sep 2020 21:00:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 1A772398601C Received: from pps.filterd (m0107398.ppops.net [127.0.0.1]) by mx08-00271601.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 08AKnfIX002819; Thu, 10 Sep 2020 23:00:22 +0200 Received: from eur05-db8-obe.outbound.protection.outlook.com (mail-db8eur05lp2112.outbound.protection.outlook.com [104.47.17.112]) by mx08-00271601.pphosted.com with ESMTP id 33c0ne2sba-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 10 Sep 2020 23:00:22 +0200 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=oHZeC4rchP1g0lr/xElUOEYZd/stmzY6HBwonOPs1JfrkSEGUgotcsctipUHr4pvBb8Js08BzVr310G2cSPJ0CgTYDvyzmIzVQ6MY6KPFR+onSWxMDaC/i4c9sbkJW9SMovDtPXyBrltQwiwG7xgNhyEn3nquM9kNjKhNSh7z4yN7XC78fmHHN2inLsk/t0+UEoAeBSErtvScOFGVNBk8pRLg8ipPcHH8PA10OGVbNam/LLAR5gyZ34/3DvqqjQF19DoEALK35e7VckxvIIFYQZrDUlrqV4fqeor+UqlKplPuWCh8/uAGCB9HG7JsYp1+vJBQZiZTaspr6H41YUaWA== 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=Y3cwTpEEbAXaJw0Wr5M5JFDZSysT0426GFhpJ+q6WRA=; b=H46wDaPyDIZDadPjpseEqlSKY1ys+3IhqjW5hxB4Y0ytQGwytyegBhz3UNfmzLx//X39H7B7qtXkcoqBOXzwpfuspzE7FWffRFnJkX4FM7y8Gs1dLPPM/v+oP1UHedcMs6/lM+qXycVty12Ym5K7qJMa1XlanIJGEZKLksjpN1Wlt51mWQYcj0iA0rbk1Yco1ZuU/OhI2M/UMDrTp9cJzaEgNzIOrHLjv83Dr4iYJHHYLkdGHsnOiNQpELeq7PLWhr60F7bsaQJNWgJkMLOIVVl4mzinzgHAQAFU0Lj34h/2MSfTNP9dYfXkgF++diepMNLip2/eS74Bh/eeD9T0Ow== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=verisure.com; dmarc=pass action=none header.from=verisure.com; dkim=pass header.d=verisure.com; arc=none Received: from AM6PR10MB2150.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:20b:4a::16) by AM7PR10MB3333.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:20b:10c::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3370.16; Thu, 10 Sep 2020 21:00:20 +0000 Received: from AM6PR10MB2150.EURPRD10.PROD.OUTLOOK.COM ([fe80::bcba:f0c0:8bd3:e7c]) by AM6PR10MB2150.EURPRD10.PROD.OUTLOOK.COM ([fe80::bcba:f0c0:8bd3:e7c%7]) with mapi id 15.20.3370.016; Thu, 10 Sep 2020 21:00:20 +0000 From: Fredrik Hederstierna To: Alan Hayward CC: "gdb-patches\\@sourceware.org" , nd , James-Adam Renquinha Henri Subject: Re: [PATCH] Fix exception stack unwinding for ARM Cortex-M Thread-Topic: [PATCH] Fix exception stack unwinding for ARM Cortex-M Thread-Index: AQHWfd9KZNChspL/gEKRcBh3+cqQUKlVXOWAgAYD57yABKVAAIACaDTb Date: Thu, 10 Sep 2020 21:00:20 +0000 Message-ID: References: <790E863F-88F4-47D7-A70A-FA22779ACC2A@arm.com> <04F0F9D3-6A7D-4F6E-8AE7-93F360CEEA91@arm.com> , <6AB27C15-60DF-43A2-863A-C250AD034492@arm.com> In-Reply-To: <6AB27C15-60DF-43A2-863A-C250AD034492@arm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [81.236.17.7] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b1cbe300-ca94-4c9b-ea79-08d855cc874c x-ms-traffictypediagnostic: AM7PR10MB3333: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:1201; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: UPFow0/Uy6UTks2PkpERXVW1Kdr7T8JyAAJ6BBUOQ7bDdXvKutXTs/qyEqeAn4qQxGZoGEXXehhJDo8PHnEVq9Tt4OoHOCfQibkUZggQv1wu2qeF4NGMHsQH48dJZ1uIOo5EtF3xJpyz5JpK6KzhZRJWzYJ8v+C4IFbboE6t5lcOJKHLWFLaAsYSA8F5WknxFfULtkaF3aQ22TawmmMB+POeurv3uba/PbuusgQiUhBqJ5D9KREHAga0kMK2To/T7bCZpKyD8xG75zazaOfq1GEO6tfXSqzrNwi/hxLGUcsJprbSJGi1Si7qYrIwAgHLOfJ4C0z2SEKNvYOem2VkRQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR10MB2150.EURPRD10.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(396003)(366004)(376002)(346002)(136003)(39860400002)(83380400001)(6506007)(44832011)(55016002)(19627405001)(5660300002)(4326008)(26005)(53546011)(478600001)(2906002)(9686003)(33656002)(6916009)(52536014)(7696005)(54906003)(8936002)(8676002)(76116006)(71200400001)(64756008)(316002)(86362001)(66946007)(66476007)(66556008)(66446008)(186003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: GPhgW1P/+1+oYz+aRueuVerB36cVNdpx3gmBhZv++ERrLNTvjFrwvrlHUo62rSPawB8JslbHryRQRxiQPZptCxZ43nOn75kUr/s6xlmWQjNPp6rf8klRUO80pl6drt7uo8njY151R6JadPUvZs3tSmNScH3n+r4WUmozipjHRGiBHo/OH3jm7xVhxEU73pmu/NKzIBJC+BHykxP5LrVttAcWMI8ipW7qpdAhfIByTJBRfwtOgEHYU0VVaLAT7U59uR20fIOl+ih9Imwt3m32hq1ErNq14xTTrko4B5BO1RNamhEi4mblIuYcHBmEHm99oufP8GSEmF/BTM8LF93kebOq0YN0FkNlnDrz4PbTAio8JiD1lu2DCelubkNULt5TXCEOzwa8lM7KOQBXNq9NcapAxrCpj/K4vXk17EkLdl39zzXp06Y40tErLTGSyWBrZA0olu3mnHluEKI8Ad9lR9+G32iQGv5ws+l3HGV1Fe0Is0nJ162Ijbe69sPlZdne5eQfAFRV9GVCZSaSNLDQLyiEnqvdOXuQlTxmu74q/c1OebKYrQ02S9EFZ+sUDrKytR33znNyuey4/MbFVUavWnpj0elYItDbkkbVy2u8za4RwVOifJ7dRntQ2gdqaEIiDTA3HKwPnz7fqtfSL4CeJA== x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: verisure.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM6PR10MB2150.EURPRD10.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: b1cbe300-ca94-4c9b-ea79-08d855cc874c X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Sep 2020 21:00:20.3390 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 3055fa7f-a944-4927-801e-a62b63119e43 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 4uyjDUJIxmAFD4urs4mTP83aPEdwHTsa4tV99aZZvDHw+rTYCxquRP7c0XtjpE2lA0gfNTnLqCWYuX8+ljKTYrHI+5hFUBGuXnDaeJSgek0okB4yl7yAizTvgOsUOe1S X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR10MB3333 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-09-10_09:2020-09-10, 2020-09-10 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 suspectscore=0 mlxlogscore=856 clxscore=1015 spamscore=0 adultscore=0 priorityscore=1501 malwarescore=0 mlxscore=0 lowpriorityscore=0 phishscore=0 impostorscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2009100185 X-Spam-Status: No, score=-11.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, HTML_MESSAGE, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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: , X-List-Received-Date: Thu, 10 Sep 2020 21:00:27 -0000 Hi Alan, sounds great! thank for committing the patch, I do not have any GDB Bugzilla account, so please submit bugs for the addit= ional features. It would be great if patch goes in before the GDB 10 branching, thanks! Best Regards, Fredrik ________________________________ From: Alan Hayward Sent: Wednesday, September 9, 2020 10:12 AM To: Fredrik Hederstierna Cc: gdb-patches\@sourceware.org ; nd ; James-Adam Renquinha Henri Subject: Re: [PATCH] Fix exception stack unwinding for ARM Cortex-M Ok, everything looks good to me now. It=92s fairly clear in the code where there is still work to be done. Do you have a bugzilla account? If so, could you please raise two bugs for = the two features. If not, I can add them. Doesn=92t look like you have write access, so I=92ll leave this to early ne= xt week and if there have been no other comments then I=92ll commit it. Thanks for the patch! Alan. > On 6 Sep 2020, at 10:27, Fredrik Hederstierna wrote: > > Hi, > I updated that patch to address your comments, see below and attached pat= ch take2 > >> From: Alan Hayward >> Sent: Wednesday, September 2, 2020 3:24 PM >> To: Fredrik Hederstierna > >> How easy is it to compile a binary that exhibits this behaviour? If so t= hen a >> test in testsuite/gdb.arch/ would be nice. For reference, aarch64-sighan= dler-regs.exp >> is a similar test but for AArch64. > > I have not had time to further look into this, its probably possible to a= dd such a test case, but I have no possibility to do this currently unfortu= nately. > >> Have you signed the copyright assignment? > > Yes, to my understanding everything is clear. > >>> diff --git a/gdb/ChangeLog b/gdb/ChangeLog >>> index 1ff47c3355..1d80e8cfc8 100644 >>> --- a/gdb/ChangeLog >>> +++ b/gdb/ChangeLog >>> @@ -1,3 +1,9 @@ >>> +2020-08-29 Fredrik Hederstierna >>> + Adam Renquinha >>> + >>> + * arm-tdep.c (arm_m_exception_cache): Try use correct stack >>> + pointer and stack frame offset when unwinding. >>> + >> >> Ideally this part should be left separate from the patch as to prevent >> merge issues. > > Ok, removed from patch. > >>> + /* Check if main stack was used. */ >>> + main_stack_used =3D ((lr & 0xf) !=3D 0xd); >> >> This took me a while to confirm. Could you mention that you are checking= for >> SPSEL in the comment. Also, I wonder if it=92s worth checking the other = bits in lr. >> Yes they should be all ones in either case. But I=92d rather be a little= cautious. >> Only go into the else case if all the bits are correct. > > Ok, added more clear comments and more strict bit checking. > >>> + /* Thread (process) stack could not be fetched, >>> + give warning and exit. */ >>> + >>> + warning (_("no PSP thread stack unwinding supported, exiting= .")); >> >> I don=92t think you mean exit. Maybe just remove =93exiting=94 from the = string. > > Ok, removed 'exiting' > >>> + /* This code does not take into account the lazy stacking, see "= Lazy >>> + context save of FP state", in B1.5.7, also ARM AN298, support= ed >>> + by Cortex-M4F architecture. Give a warning and try do best ef= fort. >>> + To fully handle this the FPCCR register (Floating-point Conte= xt >>> + Control Register) needs to be read out and the bits ASPEN and= LSPEN >>> + could be checked to setup correct lazy stacked FP registers. = */ >>> + >>> + warning (_("no FPU lazy stack unwinding supported, check FPCCR."= )); >> >> This means that we will always get a warning if the extended frame is us= ed. >> I=92d rather that didn=92t happen. >> How easy would be be to check the FPCCR register and then give a warning= only if >> lazy stacking is being used? > > Maybe its possible, but have to time to solve this currently, added memor= y address of FPCCR, > its not a register, but probably possible to do memory reading to dig dee= per into this. > Removed warning. > >>> + /* Basic frame type used. */ >>> + cache->prev_sp =3D unwound_sp + 32; >> >> The mix of hex and decimal in the function is a little glaring. >> Could you switch this one to 0x20. > > Ok, fixed. > > > Here is ChangeLog, separated, new patch variant attached. > > 2020-09-06 Fredrik Hederstierna > Adam Renquinha > > * arm-tdep.c (arm_m_exception_cache): Try use correct stack > pointer and stack frame offset when unwinding. > > > BR Fredrik >