From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 120940 invoked by alias); 10 Jan 2019 13:06:47 -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 120727 invoked by uid 89); 10 Jan 2019 13:06:47 -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=accidentally, theoretical, integral, HX-HELO:sk:EUR01-H X-HELO: EUR01-HE1-obe.outbound.protection.outlook.com Received: from mail-eopbgr130071.outbound.protection.outlook.com (HELO EUR01-HE1-obe.outbound.protection.outlook.com) (40.107.13.71) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 10 Jan 2019 13:06:45 +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=CU90jxOmsIoGxxchQ02lvXlYM88M4qMcK7VGongkTyA=; b=Ckdo7/jOgA9+on6O/BDIB+PB0sIx90JbjGar3A6EagslONuMHdOH86HHK8kz6wq/CKMnlTAabyxUK2kbDxwi4kUPpghO5Dh/RkWBwS7j+YjYiOrgmxJbBkW9efFlUI5e8sA3GWcESq5aoLdZUcUYTNxQdD+EqDtBgVur/QD40ho= Received: from DB5PR08MB1030.eurprd08.prod.outlook.com (10.166.14.15) by DB5PR08MB0647.eurprd08.prod.outlook.com (10.169.32.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1495.6; Thu, 10 Jan 2019 13:06:41 +0000 Received: from DB5PR08MB1030.eurprd08.prod.outlook.com ([fe80::d59d:34fb:3c03:241d]) by DB5PR08MB1030.eurprd08.prod.outlook.com ([fe80::d59d:34fb:3c03:241d%3]) with mapi id 15.20.1495.011; Thu, 10 Jan 2019 13:06:41 +0000 From: Wilco Dijkstra To: Jakub Jelinek CC: GCC Patches , nd Subject: Re: [PATCH v2] Fix PR64242 Date: Thu, 10 Jan 2019 13:06:00 -0000 Message-ID: References: <20181207155542.GL12380@tucnak> ,<20181207162327.GN12380@tucnak>, In-Reply-To: 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: 2019-01/txt/msg00538.txt.bz2 Hi Jakub, Any other comments? I'd like to finish this rather than leaving it in its c= urrent half-done state. Wilco =A0=20 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 =A0=A0=A0=20=20=20=20=20