From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22286 invoked by alias); 7 Dec 2018 16:49:18 -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 21983 invoked by uid 89); 7 Dec 2018 16:48:59 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=BAYES_00,KAM_NUMSUBJECT,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.3.2 spammy=caller's X-HELO: EUR04-HE1-obe.outbound.protection.outlook.com Received: from mail-eopbgr70052.outbound.protection.outlook.com (HELO EUR04-HE1-obe.outbound.protection.outlook.com) (40.107.7.52) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 07 Dec 2018 16:48:57 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lS+YkRVfJMzfHVnMXhaU64x43znYjDjhNH8euV6v3LA=; b=f3TqgVeG9nUn340iV8JGcc6k50ek1sLJd+Koqi9J8S4Fi7L5aDdSIM8pwA48JKzInUHRJeJtH65Oj/jF9ry2f3o3OSOTdyKy5e5Vqt1MtNLEzCEfQSVMTsc+AKVlJz4BFkLG/aqVXr7mOID9Xfue7R/QFQUs/Rw5Wa9ygikznxU= Received: from DB5PR08MB1030.eurprd08.prod.outlook.com (10.166.14.15) by DB5PR08MB0887.eurprd08.prod.outlook.com (10.164.43.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1404.22; Fri, 7 Dec 2018 16:48:48 +0000 Received: from DB5PR08MB1030.eurprd08.prod.outlook.com ([fe80::8c16:7604:c66c:8942]) by DB5PR08MB1030.eurprd08.prod.outlook.com ([fe80::8c16:7604:c66c:8942%6]) with mapi id 15.20.1404.021; Fri, 7 Dec 2018 16:48:48 +0000 From: Wilco Dijkstra To: Jakub Jelinek CC: GCC Patches , nd Subject: Re: [PATCH v2] Fix PR64242 Date: Fri, 07 Dec 2018 16:49:00 -0000 Message-ID: References: <20181207155542.GL12380@tucnak> ,<20181207162327.GN12380@tucnak> In-Reply-To: <20181207162327.GN12380@tucnak> authentication-results: spf=none (sender IP is ) smtp.mailfrom=Wilco.Dijkstra@arm.com; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-SW-Source: 2018-12/txt/msg00487.txt.bz2 Hi, Jakub Jelinek wrote: On Fri, Dec 07, 2018 at 04:19:22PM +0000, Wilco Dijkstra wrote: >> The test case doesn't need an aligned object to fail, so why did you add= it? > > It needed it on i686, because otherwise it happened to see the value it > wanted in the caller's stack frame. Right, so I fixed that by increasing the size of the frame in broken_setjmp= to be larger than the frame in main, so it's now extremely unlikely to accidental= ly read from a random stack location and end up with a valid stack pointer. > >> +=A0 /* Compute expected next alloca offset - some targets don't align= properly > >> +=A0=A0=A0=A0 and allocate too much.=A0 */ > >> +=A0 p =3D q + (q - p); > > > > This is UB, pointer difference is only defined within the same object. > > So, you can only do such subtraction in some integral type rather than = as > > pointer subtraction.=20 >=20 > __builtin_setjmp is already undefined behaviour, and the stack corruption= is > even more undefined - trying to avoid harmless theoretical undefined beha= viour > wouldn't be helpful. > No, __builtin_setjmp is a GNU extension, not undefined behavior.=A0=20 Well the evidence is that it's undocumented, unspecified and causes undefin= ed behaviour... > And=20 > something that is UB and might be harmless today might be harmful tomorro= w, > gcc optimizes heavily on the assumption that UB doesn't happen in the > program, so might optimize that subtraction to 0 or 42 or whatever else. > >> > And I'm not sure you have a guarantee that every zero sized alloca is = at the >> > same offset from the previous one. >>=20 >> The above pointer adjustment handles the case where alloca overallocates. >> It passes on x86-64 which always adds 8 unnecessary bytes. > > What guarantee is there that it overallocates each time the same though? How could it not be? It could only vary if it was reading an uninitialized = register or adding a random extra amount as a form of ASLR. But there is no point in tr= ying to support future unknown features/bugs since it will give false negatives = today. Wilco =20=20=20=20