From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.10]) by sourceware.org (Postfix) with ESMTPS id 6BEE9385840E for ; Thu, 11 Apr 2024 11:13:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6BEE9385840E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=intel.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 6BEE9385840E Authentication-Results: server2.sourceware.org; arc=pass smtp.remote-ip=192.198.163.10 ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1712834025; cv=pass; b=cnA8AcD2tyfxznVPcWSHAISnNDiN5FYJjEPKJLFHFK4HGXk43X6xiynYZKI0bHOBoukCfLzXEGFyX/rdjrj687zREM0lS1kokVeleT7ph+RhtOAPDtiaSCay8ejLTHY9dnY0ZyZWfgFRTezqOh6FEeUNlnO/sguQw9NWDZaqCeA= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1712834025; c=relaxed/simple; bh=xphyV0TOdCVUAis6KUOGqdMa/HLp4/aHaDuo4bXoT1o=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=JNjp9ZQbSZAGnQ98NBRCKCyKY6IaTm7QGCSzBKOst+D7EhWjnvVJrRtm7vAk4mKOAc5Wqgf0TYqZJ+3OFKWWpOzslIbrRiemspWIsHg6MKhHRVqSRXMz2n2Tx6jfn5bUjLngYprAAY8iN1TP5SA5HRFdqKX0o2b5UUiVyd3DqAk= ARC-Authentication-Results: i=2; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1712834022; x=1744370022; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=xphyV0TOdCVUAis6KUOGqdMa/HLp4/aHaDuo4bXoT1o=; b=cb98+5756EkLfgPk6ZXwxXVqSU9AWU+Z/Zug330YDUpCCh8RlX5l4Hxy kZTq4WlUurjyiOlmGEgQBuw15r6J4HoyLzyvkMUNdDgVT460gy3j2170G 0ZWksgWJ6F2gCKCDw6N8RLv7KEHQqJisO/nhkEporTddeYA5ALzidKCms D+abmM1Zb2A0TBIIycoZu4dF5Br+JBjl23MsxMaUg23O3Hvr9qw148lMc QC+zkhA99LcWRnBmBZc+viGJRtVDJkAP2VEPBmGVsRjzHA/WnP2c922m8 aKDC2R9xO+uWdBYjVjnR+ME5dZFsEvdyu7iUSZCo8RGqcc0BffcnnJLGy A==; X-CSE-ConnectionGUID: yHpXVJgJRCKtouQFe0TiIA== X-CSE-MsgGUID: R+6zllNtRsK31FxnZ1zrtg== X-IronPort-AV: E=McAfee;i="6600,9927,11039"; a="19627926" X-IronPort-AV: E=Sophos;i="6.07,193,1708416000"; d="scan'208";a="19627926" Received: from orviesa001.jf.intel.com ([10.64.159.141]) by fmvoesa104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Apr 2024 04:13:41 -0700 X-CSE-ConnectionGUID: hGNzJ+3sQKWE3BSr7jSMXg== X-CSE-MsgGUID: BMZf5fPAS+e/KxEDK9/vBg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.07,193,1708416000"; d="scan'208";a="58289484" Received: from orsmsx603.amr.corp.intel.com ([10.22.229.16]) by orviesa001.jf.intel.com with ESMTP/TLS/AES256-GCM-SHA384; 11 Apr 2024 04:13:40 -0700 Received: from orsmsx610.amr.corp.intel.com (10.22.229.23) by ORSMSX603.amr.corp.intel.com (10.22.229.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Thu, 11 Apr 2024 04:13:40 -0700 Received: from orsedg603.ED.cps.intel.com (10.7.248.4) by orsmsx610.amr.corp.intel.com (10.22.229.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35 via Frontend Transport; Thu, 11 Apr 2024 04:13:40 -0700 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (104.47.58.101) by edgegateway.intel.com (134.134.137.100) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.35; Thu, 11 Apr 2024 04:13:40 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Z20Q/9AVlm6vjBUd8AaLX/FLgo6Sw5hJqRz8RXjiYT5b3o/YlQ+MVsF0z0ulzcG8D374pMO8f9Z5kUxBFv7qi+hrZGOUWk/7Y2MRcbyc+aXN+SrVEWVFznD2pgdWrW3p5kJHfJl6EkJAs2jMyNrq2yG5mZoNERhq0AtyZ2yXbc2GyRuLCTCKbVLe/UA/tejmWYPHiIbRZAAKkXFZGVIe+OYtbdsCT6LOSAH1IF5UEF17L8lVvDoOl2E0KyMFJ0E3dMD9Dh133gsrS9XeYbG5kfOqzhAKrMFWqVDmBhg5bJPLLIf+P/BmeQMtyercSrjiIs389ZIjMoE2yeVXn0vORQ== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=KMjAlD6oI4tVqdo3r+JxqaUMFeyiH8BnsIlrNDKpcbU=; b=gcKI0Faq5Ru6jV32rx67X2IsrAKzVyaXjjXBv+qhKeX529MBsI58IDJBEwll3h1Tca87Jmpco6D2Yv6ejAWngTynzf2kqBKOQdYfk7aav15iIsVzlELuw3pDOYSwmzbOC9SOW0cpXYm94TfUl6/NG0tl5jmohwhRI5tnP8nao7MKpFsbkHe5tFEQxaZ1J+g57+DR094Q3P8hBcw3kZYXbvIjj5rrK4ycnjqyaeG5hT21oRRp59aFYFzp2nn53JiCTBNYFm5t7ocn0NklO31nWAPp2zSehZeQxxS3mGRX3Ym6XVu0mEm1XDUFjfWbqjQxW+4XpMnafJOIttARkmO4bw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none Received: from MW4SPRMB0054.namprd11.prod.outlook.com (2603:10b6:303:1e1::12) by SA3PR11MB7525.namprd11.prod.outlook.com (2603:10b6:806:31a::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7452.26; Thu, 11 Apr 2024 11:13:38 +0000 Received: from MW4SPRMB0054.namprd11.prod.outlook.com ([fe80::9b4f:75b7:90ef:c7cc]) by MW4SPRMB0054.namprd11.prod.outlook.com ([fe80::9b4f:75b7:90ef:c7cc%4]) with mapi id 15.20.7409.049; Thu, 11 Apr 2024 11:13:38 +0000 From: "Liu, Hongtao" To: Jakub Jelinek , Richard Biener , Jeff Law CC: "gcc-patches@gcc.gnu.org" Subject: RE: [PATCH] asan, v3: Fix up handling of > 32 byte aligned variables with -fsanitize=address -fstack-protector* [PR110027] Thread-Topic: [PATCH] asan, v3: Fix up handling of > 32 byte aligned variables with -fsanitize=address -fstack-protector* [PR110027] Thread-Index: AQHai+u444yHgou2P0Ogj+PklTA2orFi6mWw Date: Thu, 11 Apr 2024 11:13:37 +0000 Message-ID: References: <20240326060802.3443261-1-hongtao.liu@intel.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: MW4SPRMB0054:EE_|SA3PR11MB7525:EE_ x-ms-office365-filtering-correlation-id: 84a6c4ec-2e0b-4cef-a78e-08dc5a186fb6 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: PLc9rzi4ECwmXgwBmFQaVrLW3xDtt7dZ+uOOgPIVrpUiyq2EmyOpyQbcwRQttKfz0Bu1tid5N053HwdwOncPO1gZfC1qv62uxtthStNoHjLOPVhYVIXa+Vf5bzG1jfa6LFCqJSdGGwZWYENwvgQX3+jeUJu4o+Hq7hJc1uIu7U6GydeKxBbE4T67Rl8zRKtvmTypMTSglTv0BB3zKdzZxNxS+n3HGiwVQgKatpmUUtNdIFRaL+mGNl/I+2cPxLQm6j++YcWGtieNwHRlmccn6HU5Cwf5yfRc+1TwPvOqO1fJEOw6XppNFfMu6hlXlQsDuEYG2HUKxlKTxsyZW030oPsR7xqxy1Veop9T/igboOZwrEiTGukoDavPA33n47ih5EB1jS7gOsJoSv3EFc/UGR0+OnULySnSHYZnLGAdDfmOW1CBm824VOTq3DBHNPj4azu4EvI9CZZwAH6qQzrAtHiI3fGChBIxqm0fJ8wcjgURFBE3NOqQpFibFQ78waYiVIQVmclw0IS98ZmdAVTb8gyplopE0/tqIZkmnWUudWqM9HZ0IdukufAd1FTtjRMN4jRAd8CV0jtyp0o0vv3XQj7So98+KFLzA390/th/cX044ZbesXnatAtqjDkFZFlp1R/7TbZYY1oEdbNQZ1sYgdLqm4x3apvtSnBvD2e52eY= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:MW4SPRMB0054.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(366007)(1800799015)(376005)(38070700009);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?1vYxo/M+a5uRdN9JuyHNmMp/biCwcCWAn76p0OB1SeD5kpIaJx7+iiEABEIg?= =?us-ascii?Q?zRNS9pEC+ElQlce69TP4zeDPC8B6GcrueAo54/vaqjIbTY1xgBRPlq80+xun?= =?us-ascii?Q?dPcEIrBeyN/0pN1cYdkdL2oOKGFhWl4Xjgl8C0zrmRDKsrTlD+/RVSfPXJ1i?= =?us-ascii?Q?K9LBRMGRARGU2O/KsOfUSxRQN+VFugL6kzi87WcM0gEUGWMVfU+zwRvlHVYc?= =?us-ascii?Q?evj73nQGIsxDB6ZLHSj4fknzs0SIkDbJZ9U+MUJhfDkTiFk+L5xpGmzu8GBZ?= =?us-ascii?Q?NSfV8cjzldOxz6JXMpJ/m7bU+ZJIYmC3rDqe8oSKmQi7w1jhC0QJafV71X37?= =?us-ascii?Q?56BIdgT0TIahcE7LGYU+DZWgbOb2gOsnzgTQrSXAOa7Ofafw2Zd/wiL5I0V+?= =?us-ascii?Q?+jfBfR/zbrPQMQOTBrMSaHVHO2RCUUX0o9JRfd4QGeKoPKS0AW9xcdv3NCHy?= =?us-ascii?Q?cv97b4GTBGp+t1bkywDRjC4AocHubGcWfC1K7JHIcK7f/UVXSMTc36ANhQkt?= =?us-ascii?Q?RWP3hveGwELakEm5jtYSl/1xlDaBuszR0rYXnNKB8xPD3W8QMU3vdFhFVjsZ?= =?us-ascii?Q?ZRgcjEoTl8pXcUrGJL2voxFoFIAXWM6hrrRyufuretFYWrmZ+UdKE8CbR0Bv?= =?us-ascii?Q?orfCmWvQIIu/p/E4Vj27a4gN45PygDJ6KIGnY8D3pszv1b2yGz1TBEIMOVux?= =?us-ascii?Q?G8cVNoJAt32Hyg24JbcoypkpV7rJnsDQds6cT/52LXYxtqA9chxaZ6o1s5my?= =?us-ascii?Q?ABmNJFQi1F8CYNI/uyQVaECc4UZZ6dkISy3bzRl0vHcUYg6I6r4Lg6qQVYQ8?= =?us-ascii?Q?NUJcKgimUlbUbtyOB0UTcHbtwgH+Ty1WIpbJTqXus45PfQ82A/jCS99A+eKy?= =?us-ascii?Q?Obrp9jA55mqqcZOkWEzE3qCFp/rVmayWU4UofxO+O6aUoCU3o/4+WpU//u9c?= =?us-ascii?Q?rxaD6T/dC5kOpKpVcR1Cmz/km5jvbQOH2QgsiVTsxd+Bxa4rVw8A5SE1n7Ds?= =?us-ascii?Q?3HbguStOHcmvDwicC+SdVaaot8hI8/mn5lM5xoDGUcuvHtZhdYpTKEQ7Ipxm?= =?us-ascii?Q?lDFiRsOjKuHY314LGi01zmpSbSJtace1m9RpXMRhJY5S0pk/t47pzofo9/Zn?= =?us-ascii?Q?PPF/R9kzfuSbDG2bMti2Dk6bcKW3EXjhB1EWNov6UDNeq8HgU7Wn0eHjQ77X?= =?us-ascii?Q?A7aXDds4LSKjgvN181Em/BNmQa/xgbOHToYUhHcLahFPHk0jWgGMYeIkzwTs?= =?us-ascii?Q?shomOeRzBB1Hx5yyWNZ9WN+WQOHXnDgVFHUY8wifprQZwXMDr6DDUhtwXKwq?= =?us-ascii?Q?uW0SdwpxkkfI+GKY012nThOnwc9pNK2T1RQs6Mk0v3vX9OGOiI2ZTDILgvgo?= =?us-ascii?Q?x7QUidkhAy/DTGrlpsApPxzcUKQTFpiavLCOMLR5SZ2BCE2ZWsfuz4nfffSh?= =?us-ascii?Q?DImWhedm89HYnHpryXf/Hn9O3h6d9Qcz4x5k5kbgI1/qMr+e8rXoHZCK76dK?= =?us-ascii?Q?2SXTIBMyQXuOdUe7qAbFlJMS6gfn5rVmEW57R4TkcRdDlwy1rvNgbcI4Ip33?= =?us-ascii?Q?YF/McjSXeeCGqzEiH6GRHYNA2naIYRIdQfT8ebkt?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MW4SPRMB0054.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 84a6c4ec-2e0b-4cef-a78e-08dc5a186fb6 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Apr 2024 11:13:37.9312 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: yAZ2H/+xBaUkJWWCGYvWnJalG1YDfzb31jWoxtc4Z2HSG3o2tXMpWRmUHSEBIkCV+3YC2ldNPi8nQUS/Y8RcYw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA3PR11MB7525 X-OriginatorOrg: intel.com X-Spam-Status: No, score=-8.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: > -----Original Message----- > From: Jakub Jelinek > Sent: Thursday, April 11, 2024 4:39 PM > To: Richard Biener ; Jeff Law ; > Liu, Hongtao > Cc: gcc-patches@gcc.gnu.org > Subject: [PATCH] asan, v3: Fix up handling of > 32 byte aligned variables= with - > fsanitize=3Daddress -fstack-protector* [PR110027] >=20 > On Tue, Mar 26, 2024 at 02:08:02PM +0800, liuhongt wrote: > > > > So, try to add some other variable with larger size and smaller > > > > alignment to the frame (and make sure it isn't optimized away). > > > > > > > > alignb above is the alignment of the first partition's var, if > > > > align_frame_offset really needs to depend on the var alignment, it > > > > probably should be the maximum alignment of all the vars with > > > > alignment alignb * BITS_PER_UNIT <=3D3D > > > > MAX_SUPPORTED_STACK_ALIGNMENT > > > > > > > > In asan_emit_stack_protection, when it allocated fake stack, it assume > > bottom of stack is also aligned to alignb. And the place violated this > > is the first var partition. which is 32 bytes offsets, it should be > > BIGGEST_ALIGNMENT / BITS_PER_UNIT. > > So I think we need to use MAX (BIGGEST_ALIGNMENT / BITS_PER_UNIT, > > ASAN_RED_ZONE_SIZE) for the first var partition. >=20 > Your first patch aligned offsets[0] to maximum of alignb and > ASAN_RED_ZONE_SIZE. But as I wrote in the reply to that mail, alignb the= re is > the alignment of just a single variable which is the first one to appear = in the > sorted list and is placed in the highest spot in the stack frame. > That is not necessarily the largest alignment, the sorting ensures that i= t is a > variable with the largest size in the frame (and only if several of them = have > equal size, largest alignment from the same sized ones). Your second pat= ch > used maximum of BIGGEST_ALIGNMENT / BITS_PER_UNIT and > ASAN_RED_ZONE_SIZE. That doesn't change anything at all when using -mno- > avx512f - offsets[0] is still just 32-byte aligned in that case relative = to top of > frame, just changes the -mavx512f case to be 64-byte aligned offsets[0] (= aka > offsets[0] is then either 0 or -64 instead of either > 0 or -32). That will not help if any variable in the frame needs 128-byt= e, 256- > byte, 512-byte ... 4096-byte alignment. If you want to fix the bug in t= he spot > you've touched, you'd need to walk all the stack_vars[stack_vars_sorted[s= i2]] > for si2 [si + 1, n - 1] and for those where the loop would do anything (i= .e. > stack_vars[i2].representative =3D=3D i2 > && TREE_CODE (decl2) =3D=3D SSA_NAME > ? SA.partition_to_pseudo[var_to_partition (SA.map, decl2)] =3D=3D NULL= _RTX > : DECL_RTL (decl2) =3D=3D pc_rtx > and the pred applies (but that means also walking the earlier ones! > because with -fstack-protector* the vars can be processed in several call= s) and > alignb2 * BITS_PER_UNIT <=3D MAX_SUPPORTED_STACK_ALIGNMENT and > compute maximum of those alignments. > That maximum is already computed, > data->asan_alignb =3D MAX (data->asan_alignb, alignb); > computes that, but you get the final result only after you do all the > expand_stack_vars calls. You'd need to compute it before. >=20 > Though, that change would be still in the wrong place. > The thing is, it would be a waste of the precious stack space when it isn= 't > needed at all (e.g. when asan will not at compile time do the use after = return > checking, or if it won't do it at runtime, or even if it will do at runti= me it will > waste the space on the stack). >=20 > The following patch fixes it solely for the __asan_stack_malloc_N allocat= ions, > doesn't enlarge unnecessarily further the actual stack frame. > Because asan is only supported on FRAME_GROWS_DOWNWARD > architectures (mips, rs6000 and xtensa are conditional > FRAME_GROWS_DOWNWARD arches, which for -fsanitize=3Daddress or -fstack- > protector* use FRAME_GROWS_DOWNWARD 1, otherwise 0, others > supporting asan always just use 1), the assumption for the dynamic stack > realignment is that the top of the stack frame (aka offset > 0) is aligned to alignb passed to the function (which is the maximum of a= lignb > of all the vars in the frame). As checked by the assertion in the patch, > offsets[0] is 0 most of the time and so that assumption is correct, the o= nly > case when it is not 0 is if -fstack-protector* is on together with - > fsanitize=3Daddress and cfgexpand.cc (create_stack_guard) created a stack > guard. That is the only variable which is allocated in the stack frame r= ight > away, for all others with -fsanitize=3Daddress defer_stack_allocation (or= -fstack- > protector*) returns true and so they aren't allocated immediately but han= dled > during the frame layout phases. So, the original frame_offset of 0 is ch= anged > because of the stack guard to -pointer_size_in_bytes and later at the > if (data->asan_vec.is_empty ()) > { > align_frame_offset (ASAN_RED_ZONE_SIZE); > prev_offset =3D frame_offset.to_constant (); > } > to -ASAN_RED_ZONE_SIZE. The asan_emit_stack_protection code wasn't > taking this into account though, so essentially assumed in the > __asan_stack_malloc_N allocated memory it needs to align it such that poi= nter > corresponding to offsets[0] is alignb aligned. But that isn't correct if= alignb > > ASAN_RED_ZONE_SIZE, in that case it needs to ensure that pointer > corresponding to frame offset 0 is alignb aligned. Thanks for the detailed explanation, I understand now. >=20 > The following patch fixes that. Unlike the previous case where we knew t= hat > asan_frame_size + base_align_bias falls into the same bucket as > asan_frame_size, this isn't in some cases true anymore, so the patch > recomputes which bucket to use and if going to bucket 11 (because there i= s no > __asan_stack_malloc_11 function in the library) disables the after return > sanitization. >=20 > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? >=20 > 2024-04-11 Jakub Jelinek >=20 > PR middle-end/110027 > * asan.cc (asan_emit_stack_protection): Assert offsets[0] is > zero if there is no stack protect guard, otherwise > -ASAN_RED_ZONE_SIZE. If alignb > ASAN_RED_ZONE_SIZE and there > is > stack pointer guard, take the ASAN_RED_ZONE_SIZE bytes allocated at > the top of the stack into account when computing base_align_bias. > Recompute use_after_return_class from asan_frame_size + > base_align_bias > and set to -1 if that would overflow to 11. >=20 > * gcc.dg/asan/pr110027.c: New test. >=20 > --- gcc/asan.cc.jj 2024-04-10 09:54:39.661231059 +0200 > +++ gcc/asan.cc 2024-04-10 12:12:11.337978004 +0200 > @@ -1911,19 +1911,39 @@ asan_emit_stack_protection (rtx base, rt > } > str_cst =3D asan_pp_string (&asan_pp); >=20 > + gcc_checking_assert (offsets[0] =3D=3D (crtl->stack_protect_guard > + ? -ASAN_RED_ZONE_SIZE : 0)); > /* Emit the prologue sequence. */ > if (asan_frame_size > 32 && asan_frame_size <=3D 65536 && pbase > && param_asan_use_after_return) > { > + HOST_WIDE_INT adjusted_frame_size =3D asan_frame_size; > + /* The stack protector guard is allocated at the top of the frame > + and cfgexpand.cc then uses align_frame_offset > (ASAN_RED_ZONE_SIZE); > + while in that case we can still use asan_frame_size, we need to take > + that into account when computing base_align_bias. */ > + if (alignb > ASAN_RED_ZONE_SIZE && crtl->stack_protect_guard) > + adjusted_frame_size +=3D ASAN_RED_ZONE_SIZE; > use_after_return_class =3D floor_log2 (asan_frame_size - 1) - 5; > /* __asan_stack_malloc_N guarantees alignment > N < 6 ? (64 << N) : 4096 bytes. */ > if (alignb > (use_after_return_class < 6 > ? (64U << use_after_return_class) : 4096U)) > use_after_return_class =3D -1; > - else if (alignb > ASAN_RED_ZONE_SIZE && (asan_frame_size & (alignb= - > 1))) > - base_align_bias =3D ((asan_frame_size + alignb - 1) > - & ~(alignb - HOST_WIDE_INT_1)) - asan_frame_size; > + else if (alignb > ASAN_RED_ZONE_SIZE > + && (adjusted_frame_size & (alignb - 1))) > + { > + base_align_bias > + =3D ((adjusted_frame_size + alignb - 1) > + & ~(alignb - HOST_WIDE_INT_1)) - adjusted_frame_size; > + use_after_return_class > + =3D floor_log2 (asan_frame_size + base_align_bias - 1) - 5; > + if (use_after_return_class > 10) > + { > + base_align_bias =3D 0; > + use_after_return_class =3D -1; > + } > + } > } >=20 > /* Align base if target is STRICT_ALIGNMENT. */ > --- gcc/testsuite/gcc.dg/asan/pr110027.c.jj 2024-04-10 > 12:01:19.939768472 +0200 > +++ gcc/testsuite/gcc.dg/asan/pr110027.c 2024-04-10 > 12:11:52.728229147 +0200 > @@ -0,0 +1,50 @@ > +/* PR middle-end/110027 */ > +/* { dg-do run } */ > +/* { dg-additional-options "-fstack-protector-strong" { target > +fstack_protector } } */ > +/* { dg-set-target-env-var ASAN_OPTIONS > +"detect_stack_use_after_return=3D1" } */ > + > +struct __attribute__((aligned (128))) S { char s[128]; }; struct > +__attribute__((aligned (64))) T { char s[192]; }; struct > +__attribute__((aligned (32))) U { char s[256]; }; struct > +__attribute__((aligned (64))) V { char s[320]; }; struct > +__attribute__((aligned (128))) W { char s[512]; }; > + > +__attribute__((noipa)) void > +foo (void *p, void *q, void *r, void *s) { > + if (((__UINTPTR_TYPE__) p & 31) !=3D 0 > + || ((__UINTPTR_TYPE__) q & 127) !=3D 0 > + || ((__UINTPTR_TYPE__) r & 63) !=3D 0) > + __builtin_abort (); > + (void *) s; > +} > + > +__attribute__((noipa)) int > +bar (void) > +{ > + struct U u; > + struct S s; > + struct T t; > + char p[4]; > + foo (&u, &s, &t, &p); > + return 42; > +} > + > +__attribute__((noipa)) int > +baz (void) > +{ > + struct W w; > + struct U u; > + struct V v; > + char p[4]; > + foo (&u, &w, &v, &p); > + return 42; > +} > + > +int > +main () > +{ > + bar (); > + baz (); > + return 0; > +} >=20 >=20 > Jakub