From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 57077 invoked by alias); 18 Jun 2019 00:58:26 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 57064 invoked by uid 89); 18 Jun 2019 00:58:25 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,KAM_NUMSUBJECT,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS autolearn=no version=3.3.1 spammy= X-HELO: EUR03-VE1-obe.outbound.protection.outlook.com Received: from mail-eopbgr50071.outbound.protection.outlook.com (HELO EUR03-VE1-obe.outbound.protection.outlook.com) (40.107.5.71) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 18 Jun 2019 00:58:24 +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=LJzPQ9HQUghm7CGbfFjAIJhzS42yubMPc6+0xaTv4PE=; b=uk08uYDHv2fCq0GqhaBro8S4DLEuifStFWjvUWayZH39y2yJ0lG9xgeW7qGAedydQYfXHIguw6+Y88GZ7eLgea3ievya+JEFJVMAvh3xCj30P016ow0D0ELd6CwOuZbdOiVZsLbB56jx9JGLUhPeAu6xFmUO+Hp8BIGG8gM9HmU= Received: from VI1PR0801MB2127.eurprd08.prod.outlook.com (10.168.62.22) by VI1PR0801MB1760.eurprd08.prod.outlook.com (10.168.62.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1987.11; Tue, 18 Jun 2019 00:58:20 +0000 Received: from VI1PR0801MB2127.eurprd08.prod.outlook.com ([fe80::54a8:e98d:2986:5cb5]) by VI1PR0801MB2127.eurprd08.prod.outlook.com ([fe80::54a8:e98d:2986:5cb5%4]) with mapi id 15.20.1987.014; Tue, 18 Jun 2019 00:58:20 +0000 From: Wilco Dijkstra To: Jeff Law , GCC Patches CC: nd Subject: Re: [PATCH] Fix PR84521 Date: Tue, 18 Jun 2019 00:58:00 -0000 Message-ID: References: , In-Reply-To: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Wilco.Dijkstra@arm.com; x-ms-oob-tlc-oobclassifiers: OLM:9508; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Wilco.Dijkstra@arm.com X-SW-Source: 2019-06/txt/msg00995.txt.bz2 Hi Jeff, > So I like the significant simplification here.=A0 My worry is whether or > not this is, in effect, an ABI change.=A0 ie, would we be able to mix and > match .o files from before/after this change which used the builtin > setjmp/longjmp bits? No it's not an ABI change. It does affect the value stored in the setjmp record, but that is entirely local to the function containing setjmp. Note that the function containing the longjmp is not affected by this change. > You mention that arm, mips and xtensa are still broken.=A0 Are they worse > after this patch?=A0 Presumably for arm/mips the problem is the frame > pointer varies based on the thumb/mips and mips/mips16 state?=A0 Is it > even valid to longjmp from one mode to the other? Yes the only remaining issue after this is the fact that these targets can = use different frame pointers in functions. The generic code doesn't consider th= is, but any function could be Arm or Thumb, mips or mips16. One solution would be to pass the frame pointer in an argument register (that would be an ABI change). > I think xtensa has two abis and the frame pointer is different across > them.=A0 Presumably a longjmp from one abi to the other isn't valid. =20 If it isn't possible to call functions with the other frame pointer then it won't be affected. Wilco