From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0b-00069f02.pphosted.com (mx0b-00069f02.pphosted.com [205.220.177.32]) by sourceware.org (Postfix) with ESMTPS id DA24D387545A for ; Thu, 11 Jul 2024 19:07:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org DA24D387545A Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=oracle.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=oracle.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org DA24D387545A Authentication-Results: server2.sourceware.org; arc=pass smtp.remote-ip=205.220.177.32 ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1720724875; cv=pass; b=UN/qJGehz4NX3U8x6L00Wp+/9kC6PmvDsH0WaK6kar6V7lU6vNLFp1AwAaGSn5WlR8BPR5FRbe9jGltyFr+7l47fYGHSef0ysNAhyy6eUiIgdvwEy0GoD1Rf2/u8G5dE72F2G4sD2Kn7mZcIEWLV4YKkpUsiozlCcXeiSvKhvcg= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1720724875; c=relaxed/simple; bh=sZliwYShIVZnR6cSm+Q6EnbaFBk4Vy+q5KpQeKlR118=; h=DKIM-Signature:DKIM-Signature:Message-ID:Date:Subject:To:From: MIME-Version; b=QbhLzHFeuErMduWOWtnSQ/CKeLovFJEXgcTXWAJSoyn35iGtrW6nqK+MLGm58Zmpuk9TXGmJcq27QjJCfxtg2tl8Ybtio5LucyCvbVlfSI7LJoA9LkfHR8QG8hOk9eV5dNko5R09ErmqcCfaQbf9uyGZCAiSnI1/CPjLFgbekKg= ARC-Authentication-Results: i=2; server2.sourceware.org Received: from pps.filterd (m0333520.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 46BFBVxC010482; Thu, 11 Jul 2024 19:07:49 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h= message-id:date:subject:to:references:from:in-reply-to :content-type:content-transfer-encoding:mime-version; s= corp-2023-11-20; bh=kTQ3tcXuNTXgNDjknc0obTQYAgidzzerGkdWm4Vwsgc=; b= fWjiy/In78bKRqdHVeEi7UpZhNnluAcwDGC8FS6Xb9YlHWgx1gNs+VDmtjXsRrEJ OnV+8UIA0FL/sA169KUy6oKjJExtUvzZ7fVeUPawQsqU1kzLKVqvaQrGHVqk/OEL 8/O3TVi3/CTyDoxdSUcpzFgM8Vb7sOBlnIe3OiYihW+3vQ8yyK6H+siPxSnYPV48 9sxIsoCFCaGoRc+vi5oGxZuwJEExOYujT/1dqsqHhgbV4eWq1ifAbzRpR1aLhy9T uMVVt7sMtQfLg25jluFal22GiB9vW5sg9BOmqcZVtrAUPRbT/FEl0wFUsynZkJjo 5Hpi+u+bj2QMyWDcDIEimg== Received: from phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com (phxpaimrmta02.appoci.oracle.com [147.154.114.232]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 406wybteaq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 11 Jul 2024 19:07:49 +0000 (GMT) Received: from pps.filterd (phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com [127.0.0.1]) by phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com (8.17.1.19/8.17.1.19) with ESMTP id 46BHjFo2033753; Thu, 11 Jul 2024 19:07:48 GMT Received: from nam10-bn7-obe.outbound.protection.outlook.com (mail-bn7nam10lp2049.outbound.protection.outlook.com [104.47.70.49]) by phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com (PPS) with ESMTPS id 409vv2nvsj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 11 Jul 2024 19:07:48 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=m9D/5WVOfZSEquoRrJ1+UM7/U/vnMwApW5AF63EYIWoziOQZyjBHcGCrCPN2LwOnmTJjDF4hdc2u2Rw3O9rKuOooFBy1+SK98e3wMvVzuqR1iZTgbnKY4y1n9tbBOQEYyzQxllA9M2Iv4FHvtNxee//f2N0J87Vmh7ibkHOHQbvSMXgD4pBw0djNXPuzA62Wl2p092fdufKJa/iLrN5UzFCqy9QvWr5A4NHmNv2JStCvEjQKrsxJHoYBEqswxHo/t0sZEFNyxkOU1aVPrwIQ/23iFl/8yKYTDQpVTCO+VQhyklHzXp6q8kPzwdF53K9z5Zg+zHxSNj+4+DLgLAKa8A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; 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=kTQ3tcXuNTXgNDjknc0obTQYAgidzzerGkdWm4Vwsgc=; b=ku57Yv3Ud0BRy3XV6/0FYFcbQARvhoTbnAdc4xlK390ojnSZFf0O1RqDp00KeaeDR2+ZncqKb8QNQQrlt9GxrXSqekHETn2mnHS+I735CVHnZ+Q4vJIf2WXc4vdT3WZ75e3BypwibrmhyEG+nrZ60B27cO5EvK/pK/T+iy5TVZDeqK5pXYIGEoS2TjoU6/rMYPLlmc+bz+GFzuf1ZqyZm780iRZFLoQck0kxrUK3ommfRqNkWi1ssFz281pE6zQONfhS00jGDJoGNR7k3m2a14TTAaAsFFZG2dzVwZqCbf24BIixTQ6ns4JM+a+2cqGlcet32Uu2dqovQM36dKyO+g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kTQ3tcXuNTXgNDjknc0obTQYAgidzzerGkdWm4Vwsgc=; b=LM1NxyfbtY2P0VnSWELOQBf3w+apzjfufdec1SAzGWrilfiT2mmW9WIxPtCCqv7CubChYfr/uOmUdvSuDdpBR36ZfSMFiNtKN2JHWsMj8/6HH4a6iyMfFnUlW+DqVvRih1swWiQ1mK6EFNdCDRLHXSG2F0Lau35wcn93s5RvuAE= Received: from MWHPR1001MB2191.namprd10.prod.outlook.com (2603:10b6:301:2c::32) by LV3PR10MB7982.namprd10.prod.outlook.com (2603:10b6:408:21a::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7741.35; Thu, 11 Jul 2024 19:07:44 +0000 Received: from MWHPR1001MB2191.namprd10.prod.outlook.com ([fe80::d57a:d847:21f3:6449]) by MWHPR1001MB2191.namprd10.prod.outlook.com ([fe80::d57a:d847:21f3:6449%4]) with mapi id 15.20.7762.016; Thu, 11 Jul 2024 19:07:43 +0000 Message-ID: <8bc9fd54-bceb-4440-84d4-46afa8de8119@oracle.com> Date: Thu, 11 Jul 2024 12:07:40 -0700 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH,V4 7/8] gas: aarch64: add experimental support for SCFI To: binutils@sourceware.org, Richard.Earnshaw@arm.com, richard.sandiford@arm.com References: <20240701025404.3361349-1-indu.bhagat@oracle.com> <20240701025404.3361349-8-indu.bhagat@oracle.com> Content-Language: en-US From: Indu Bhagat In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: MW4PR03CA0045.namprd03.prod.outlook.com (2603:10b6:303:8e::20) To MWHPR1001MB2191.namprd10.prod.outlook.com (2603:10b6:301:2c::32) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MWHPR1001MB2191:EE_|LV3PR10MB7982:EE_ X-MS-Office365-Filtering-Correlation-Id: c396b384-e1ef-495d-b94f-08dca1dcbe5e X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|366016|1800799024; X-Microsoft-Antispam-Message-Info: =?utf-8?B?MDRjdUhwc0Yzc3hBeTRkYjkvM1hKQWQ4NnRTTEwweEFNWmJ4WndtZ3FBWUpq?= =?utf-8?B?M2xRZ3hkajVsbzlPRjJYdHRVUFFMVWVBMjF2cFRMWlBnVjk1bS8zL0tXdW0v?= =?utf-8?B?dXg2ZWxDVUxKTzZwWk9SOW0zUUFVWEJBMXNrZytzb0VmbktWNnRwVXdnaHQv?= =?utf-8?B?ejF4NUZCaCtMcWxnOHd6ZUowWStYaUJhMFpMd0hrQXF3amxJRjVMV1dKbGxF?= =?utf-8?B?bm13MjkybXJIRTdldzJpT1N2YkQwS1habFliczkvQ25jU1pCU1EzYTFacXRx?= =?utf-8?B?Z2ZsYzg1R1U5YllCZ2dpTEdLenhuNHhuSGtka0hyN0h2ZEVha01RM0kydE82?= =?utf-8?B?SEdoYks0OTdwbXRYbzlUT2trUEMxSi9kWUpYYWp0R3FkRXFoM1owaUljMHE0?= =?utf-8?B?VTlTOVViSjh2VjVhakR5Mk81MGhzWUh2VkN1L3BoUm51Ulg3S1RJbmRUaUpo?= =?utf-8?B?TzBXS3RnYlorVjdHTUpSVmV4NnVWNVI1T1l0UXRZd0ttN1cvNXVpcm5yRWFs?= =?utf-8?B?T2psOTFUNFRsYmREUkVud2ZCY0xSOGE2RzVheUYxaHpFTnJVYzJSRVFtbUMv?= =?utf-8?B?Zlk2c292b0lFT0UydW4wNUlkL3dUcjgwK2xMa3E5Qk1GeSs1N1BvaVZka25D?= =?utf-8?B?M0VLRVY0SlBtUWtGZjFUbld3M1VUdzlwb2hnNEtsbnU5NzF3a25tY0NidWVu?= =?utf-8?B?ZmJJbGxPRm5OcTlxSmZuUjRzbUJyaHUyVzB4bXlBTmdXOUZSaE1OdEI5U2hR?= =?utf-8?B?RXBtSnYyVlgvWmJEQmlUZTkyaXk1akhxT1RvSEFGNGF3b1RtbnRyRTlXRTVr?= =?utf-8?B?djgzSGZQalpPZ1JwUFpCUEdLM3p1T3VvMU9Oalk4R1JXd2VWaDF4alNPMXNW?= =?utf-8?B?djdEelpIQ0JoMmc5VjNOVENKKzRTbGxEOFFvWm1WdG43eUVuR21ZeTJHeGVQ?= =?utf-8?B?aHI0U296NWFDcXZONU5XK0FoMFJpeThqUVNWNlhOdUgweWxxMHUwOFpiZE1m?= =?utf-8?B?aFRlbThvNmtTQklra2E4Qmkxc2RGRDVKcUtvdEJucmdTdEJDQUpRWkRSUlJ3?= =?utf-8?B?d01tZUVuT0dHZWhuZ2hsTVEvQXgxbGNBUmg4MWRTOWVQMUxFU3grOVZRWmFI?= =?utf-8?B?VzBrTE4ya09jaGdBaWorMVQrOGl6L3RNbGxxN1Z6UzIwWGZjZWtMSVZEY2pQ?= =?utf-8?B?T2lSRUc2VlFoWWdOY2YzTWoxV1FpOFgwWUYvTWVlVzZUMjlUZnhuTWtqS1A3?= =?utf-8?B?eDE3QnF5b2s2STh0UVJ4OVJTSVN5c2ZZQjZGc1ozaFh4OVBqUEZhVDZnSHUr?= =?utf-8?B?MDJ0cC9oS1Nyc3NjeVZvVk10blVuOXZCallwUkZ1eGlBYUpCb2pnemdTVmpp?= =?utf-8?B?WndDb1Z3TjlkR3FWUjhhaEprNGlKODNqblRCdE40c2tFQnpCN2VnOHBmMmVM?= =?utf-8?B?dEh4Zi9PUi8vd0VTSHNnVjJoVkU3bjZkWllnSkZzVWdxT0ZsWFVqQWMwZDhR?= =?utf-8?B?MzMyaEprQTFrUXpmMFhvNTJWVVA4d3Z0dG9NYko2YU5BUzliMTEyRDhVNVJP?= =?utf-8?B?UmZZMWdTTElPWksyRlNvK3Y1UVpjSUhwb0V6U0NnbVRUZnlDTFBEbDExOTNJ?= =?utf-8?B?ZjBBcjhIOXhkQXNPTHYyR21DM3BqNWFtMlFHME5Xck9PODMrbGk0NkN3c0t4?= =?utf-8?B?L284c1Y4ckZsU2FteExhaUR5b1JMMjNJWVp0MnQ4NktBaW81dXZCYzN2dzZM?= =?utf-8?B?YWtybktzUnM4Q0xqQXhTT0NjQU9manlzK3k3MjB4MHR6aFlMTzBJZFVlVWw5?= =?utf-8?B?Q1UyNHpPOXg1ZE5zeGZZdz09?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:MWHPR1001MB2191.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?RDNJS3JER2xGSnBpK0g4aUQyODJLak96RHJ2bWxaRWF1QXNIWmZacngzTFlz?= =?utf-8?B?R3h6TWUxLzdqQThFdzRJditndnpwdk5vTTQ4ZUhZWUZIck5WSUkwUFl3T29O?= =?utf-8?B?YlZkN0tna3ZEaUxoNTVhdVZ0ZTlLTXV1Y1BRTkdFcHFMN1NSNUR1UExab1dV?= =?utf-8?B?cExrTjRvVk9oUm5SUXlXOTlhM2lVKzlLdzZzc0psMDd0bGVmbkdXSlJndEsz?= =?utf-8?B?SHhoa0F2Y2ZvcmwrVEttZWtGY3ZVNDROYTZ1OFhOQU8xUW54d3VjSmMyZGgv?= =?utf-8?B?QTY5ZmttTDFOWHBPekNISGE4M3RGVTIwS0NWdm42T2g3V050Z2F3N1YyUDcw?= =?utf-8?B?eU1aMEhBK0YvMUprUFRxenZucW9yTmZMTXRxWGJDbi9TUHc0Rjkwdk52cXRL?= =?utf-8?B?NVRJaDBqYnhuRTlnRWJka3gxSTBrNS9RbGlKdThIamdNcDVDU0JsQ0VEYmpX?= =?utf-8?B?cmFsNjRlOUNCb1lpTjJZUldzejNybFdXNEpvTVo5STNlQzJnVUMyN0wwdXQ0?= =?utf-8?B?MHJyTFBiTDZXZGQ2UEo0Z25pTEZrS2krL1M3K3c1YlhzREhGWEFMOGp6eGhn?= =?utf-8?B?REtaTFdGZmM5QmxoQUJTWU1URDREd2UrdjBCaG42M2RQdFRDMUJUd1RncU9j?= =?utf-8?B?SHphS1ozTDNWS1dqOUxLTnl1cHBmM3lSL2xPdWhBREdOL242LzVNdGRuaU9S?= =?utf-8?B?bWg2alQ3ODBDeWY1SVNmQTNWUkRXRDJsM25aRko2NnRjQWhOM3NTUUlLakEx?= =?utf-8?B?ODdEbEZwUFVJRkFWQUVrVmVkM1MxVlJlY2NMM3ZYa3F4YUhJTWR4YWRYMFhK?= =?utf-8?B?bW9IUStFQU9DOTJ0SFYzOUU1SHV0Q0toS1c1VmkyVk56c1R2TzNzU0tOY0k4?= =?utf-8?B?N3hYZEt4T2Q5WTIvSDl1R2gwVGV0TFlwQ3dCT3ZvWW50UTJmTEhRajNrT25I?= =?utf-8?B?SzBGZHRPWVlRSG5zUmE4b0tXUDZRRlpPV0xSMGNmeXNxbDRPaGMrUEV3d2Vx?= =?utf-8?B?ZmY0eEpwRStOWENnK25jNUNsdjhTSUpDRDJROUdwaUdheWRtVENHY1REd25h?= =?utf-8?B?L0pKUFlybFIrOUVCUll0ZmlsbnIvVlcxbjBHRWlZNmxCNWltTy9CKzV6ZVk5?= =?utf-8?B?YlpicVIya0psaDZnMkJvUVhsWmFlQTFLTGdqUXlqVm1HWlVlcWlwT2RFQS9N?= =?utf-8?B?Q1N6bHRFUWp5cjlBd3h3a0tYeU1CTmNvdDRKUDBlWGFEalRUNXVkT2tRUkxK?= =?utf-8?B?V0VDQmdLMHdXT0tRa3JmaWFhMmN4ZENUb25LRURzV3Zlbzg3UFRGd21PR1FM?= =?utf-8?B?WGRlbDEyaWRFRWx5amp0dk1wNVgyek5tN2hFNU81Tlk2NHNERUxwRW5VQVVH?= =?utf-8?B?RWNkY2tsSS9BZEg4SFVXNEh6dW8rdGk5T0puaEtNRE5wUFdWRm9BQzdtVFQ3?= =?utf-8?B?WWlTcmg0bHB4MlFLb1JvajUrUDVocUFJNmlhVHFPYnpxTmFTRG14anFoNmFr?= =?utf-8?B?R1E4TzREQjNQekQ1dUNINXJFdDhraERObnlOcEhBVVJYMlFjWVk5bDVMaEV2?= =?utf-8?B?SFNCMDZVdnV3Q0tGWmZzNGVDU0ZUbW9aYU82dzJabU1rNlppY1FyK1lwejB0?= =?utf-8?B?M05tUG9MZzY5cjVVbElsN2l2YUJtSE1xOWVpY0VJY3gvb3RWS1dFNXJ2UjRy?= =?utf-8?B?bzRVNFdGbGw4bFhobFczeS9lS01mZHdlUXJqNXhBRTVqeG8vb1hpcDFMdGVK?= =?utf-8?B?UVorLzZLNWJGdHB3dnhaK3BxSW9PVDBLQ3VGdmtzTDZHTDNzWlFUWnAyaExG?= =?utf-8?B?eU4zeFJGeFdQRVQ3MGh1d00rYndCWUViL3A5Z1dOLzZIZkVzSGYzdHVSWEts?= =?utf-8?B?d3dtVitIK29UK2RITlRzK1Zza0ovK0J6REZDVTZ3Mmo2d1lrb0huOGxpMUZH?= =?utf-8?B?ZEdRRS9ZWCtPT0ExcVE1am5BU3J2dk9jUTJ1UzNrWFRrcC9lWFBzK1AwdTdy?= =?utf-8?B?UzJpbUJ1elpSaERNQU1BbDNVVlBJRW9Fazl0dStHTGRQYVJibTFZSFdORVo3?= =?utf-8?B?QzZIbHdBd3JDU1RadUZtT042RmJEVDhrS28xcGx4aEI3MHRCNWgxS1FHZUJ1?= =?utf-8?B?UnlzeUZ6SU8zTCs0ODRpd0FGVDRPOXhkU3dQcXZqV0V3U28rd00yc2wwMGhH?= =?utf-8?Q?eI5DJQM034LETxMA0XW1xZ0=3D?= X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: eNg+E8f7Cc4an1G6ElcugMf5Z+5lqtAKSBpx2EBlOqHorNvh0LyB9z1xx4kgpRUGDXcxrSTU/6pTs+Iid6PD9qH8AQ49Ot0nXm1Ok4yjcs4K7uWOnk4zaTeAv0/PU6TZpO2WjUPFPbPtdRQWsUhwL8caXP0Me1NweB8VzXJS3OrWuVST/mNgyVTCoxtui+378BSsKZlcC83C1u8sd+gBgoquN4kALwYCPyHeiJS9utE1tg1QwZ6P5YPDdwilAL6TIr3TJMSsR1YNgUTeQQaxfWfBb5iuf6tObEfU9fUsS7LuU+nPb476kcOnx0/IMCkORypZYiTy4nKOIXtGXmdWv4sm+IHyjlsOerxCa98fBQFsnu9lQzPMJwfMRCpHJ1HH7RZ+NzP5iVHPw/+n+rD7+XP5POcfEHj3REIhT5aMPO1qxtNF3EksBQcH0LggtSvtO4efViH4/Bj3/5Gporx34yGBPdlgoKT6dYST+XcI0KzgZ5nEAuI7eyolZHQhXUCbvGQQmLHds0AhYR+ed3E8X/7e3DbuKPRy5HeQV+o/ox4tC29wcdvMPGBio9tvTsok2Ed9/6DuxjrYCt4UT4mPWhQ0OehY9RYRbBZbgQS12go= X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: c396b384-e1ef-495d-b94f-08dca1dcbe5e X-MS-Exchange-CrossTenant-AuthSource: MWHPR1001MB2191.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Jul 2024 19:07:43.9232 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: PqWM1OnXXEHvnS+fW7EZt6kbz/yK5w+AP3WJ380D5na2R1EWbMXzcPkYOhyu5mGs2yxKD9yOswgPxGrq/9hZ+Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV3PR10MB7982 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1039,Hydra:6.0.680,FMLib:17.12.28.16 definitions=2024-07-11_14,2024-07-11_01,2024-05-17_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 bulkscore=0 mlxscore=0 adultscore=0 suspectscore=0 malwarescore=0 phishscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2406180000 definitions=main-2407110131 X-Proofpoint-GUID: 53BigvSXy9RY1CVz4alYCDngADtyKU0v X-Proofpoint-ORIG-GUID: 53BigvSXy9RY1CVz4alYCDngADtyKU0v X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,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: On 7/11/24 06:15, Richard Sandiford wrote: > Indu Bhagat writes: >> On 7/1/24 12:49, Richard Sandiford wrote: >>> Indu Bhagat writes: >>>> +{ >>>> + enum aarch64_operand_class opnd_class; >>>> + unsigned int dw2reg_num = 0; >>>> + >>>> + opnd_class = aarch64_get_operand_class (opnd->type); >>>> + >>>> + switch (opnd_class) >>>> + { >>>> + case AARCH64_OPND_CLASS_FP_REG: >>>> + dw2reg_num = opnd->reg.regno + 64; >>>> + break; >>>> + case AARCH64_OPND_CLASS_SVE_REGLIST: >>>> + dw2reg_num = opnd->reglist.first_regno + 64; >>>> + break; >>>> + case AARCH64_OPND_CLASS_MODIFIED_REG: >>>> + case AARCH64_OPND_CLASS_INT_REG: >>>> + case AARCH64_OPND_CLASS_ADDRESS: >>>> + /* Use a dummy register value in case of WZR, else this will be an >>>> + incorrect dependency on REG_SP. */ >>>> + if (!sp_allowed_p && opnd->reg.regno == REG_SP) >>>> + dw2reg_num = GINSN_DW2_REGNUM_R1_DUMMY; >>>> + else >>>> + /* For GPRs of our interest (callee-saved regs, SP, FP, LR), >>>> + DWARF register number is the same as AArch64 register number. */ >>>> + dw2reg_num = opnd->reg.regno; >>>> + break; >>> >>> I think the AARCH64_OPND_CLASS_ADDRESS case should look at opnd->addr >>> instead. AARCH64_OPND_CLASS_MODIFIED_REG should look at opnd->shifter. >>> >> >> Made the correction for AARCH64_OPND_CLASS_ADDRESS. >> >> But for AARCH64_OPND_CLASS_MODIFIED_REG, the register information is >> still correct in opnd->reg.regno, IIUC. It seems to me that the only >> information available in the opnd->shifter is how the register is >> modified by additional work (shift, multiply etc.); This information is >> not used by SCFI: >> - an add/sub with two source register and destination REG_SP/ REG_FP >> makes REG_SP/ REG_FP untraceable. So ignoring the shift amount etc does >> not hurt SCFI correctness. >> - Cant think of other operations where the shift amount will affect >> SCFI correctness.. >> >> So I am not sure of the "AARCH64_OPND_CLASS_MODIFIED_REG should look at >> opnd->shifter." of the review comment. > > It's more about type correctness. "shifter" is the data associated with > AARCH64_OPND_CLASS_MODIFIED_REG and "reg" is the data associated with > AARCH64_OPND_CLASS_INT_REG etc. I think it's mostly a coincidence > that the "reg" and "shifter" alternatives of the union put the register > at the same byte offset from the start of the structure. > The shifter struct is out of the union in struct aarch64_opnd_info. >>>> + default: >>>> + as_bad ("Unexpected value in ginsn_dw2_regnum"); >>>> + break; >>>> + } >>>> + >>>> + return dw2reg_num; >>>> +} >>>> + >>>> +/* Generate ginsn for addsub instructions with immediate opnd. */ >>>> + >>>> +static ginsnS * >>>> +aarch64_ginsn_addsub_imm (const symbolS *insn_end_sym) >>>> +{ >>>> + ginsnS *ginsn = NULL; >>>> + bool add_p, sub_p; >>>> + offsetT src_imm = 0; >>>> + unsigned int dst_reg, opnd_reg; >>>> + aarch64_opnd_info *dst, *opnd; >>>> + ginsnS *(*ginsn_func) (const symbolS *, bool, >>>> + enum ginsn_src_type, unsigned int, offsetT, >>>> + enum ginsn_src_type, unsigned int, offsetT, >>>> + enum ginsn_dst_type, unsigned int, offsetT); >>>> + >>>> + aarch64_inst *base = &inst.base; >>>> + const aarch64_opcode *opcode = base->opcode; >>>> + >>>> + add_p = aarch64_opcode_subclass_p (opcode, F_ARITH_ADD); >>>> + sub_p = aarch64_opcode_subclass_p (opcode, F_ARITH_SUB); >>>> + gas_assert (add_p || sub_p); >>>> + ginsn_func = add_p ? ginsn_new_add : ginsn_new_sub; >>>> + >>>> + gas_assert (aarch64_num_of_operands (opcode) == 3); >>>> + dst = &base->operands[0]; >>>> + opnd = &base->operands[1]; >>>> + >>>> + dst_reg = ginsn_dw2_regnum (dst, true); >>>> + >>>> + if (aarch64_gas_internal_fixup_p () && inst.reloc.exp.X_op == O_constant) >>>> + src_imm = inst.reloc.exp.X_add_number; >>>> + /* For any other relocation type, e.g., in add reg, reg, symbol, skip now >>>> + and handle via aarch64_ginsn_unhandled () code path. */ >>>> + else if (inst.reloc.type != BFD_RELOC_UNUSED) >>>> + return ginsn; >>>> + /* FIXME - verify the understanding and remove assert. */ >>>> + else >>>> + gas_assert (0); >>>> + >>>> + opnd_reg = ginsn_dw2_regnum (opnd, true); >>>> + >>>> + ginsn = ginsn_func (insn_end_sym, true, >>>> + GINSN_SRC_REG, opnd_reg, 0, >>>> + GINSN_SRC_IMM, 0, src_imm, >>>> + GINSN_DST_REG, dst_reg, 0); >>>> + ginsn_set_where (ginsn); >>>> + >>>> + return ginsn; >>>> +} >>>> + >>>> +/* Generate ginsn for addsub instructions with reg opnd. */ >>>> + >>>> +static ginsnS * >>>> +aarch64_ginsn_addsub_reg (const symbolS *insn_end_sym) >>>> +{ >>>> + ginsnS *ginsn = NULL; >>>> + bool add_p, sub_p; >>>> + unsigned int dst_reg, src1_reg, src2_reg; >>>> + aarch64_opnd_info *dst, *src1, *src2; >>>> + ginsnS *(*ginsn_func) (const symbolS *, bool, >>>> + enum ginsn_src_type, unsigned int, offsetT, >>>> + enum ginsn_src_type, unsigned int, offsetT, >>>> + enum ginsn_dst_type, unsigned int, offsetT); >>>> + >>>> + aarch64_inst *base = &inst.base; >>>> + const aarch64_opcode *opcode = base->opcode; >>>> + >>>> + add_p = aarch64_opcode_subclass_p (opcode, F_ARITH_ADD); >>>> + sub_p = aarch64_opcode_subclass_p (opcode, F_ARITH_SUB); >>>> + gas_assert (add_p || sub_p); >>>> + ginsn_func = add_p ? ginsn_new_add : ginsn_new_sub; >>>> + >>>> + gas_assert (aarch64_num_of_operands (opcode) == 3); >>>> + dst = &base->operands[0]; >>>> + src1 = &base->operands[1]; >>>> + src2 = &base->operands[2]; >>>> + >>>> + dst_reg = ginsn_dw2_regnum (dst, true); >>>> + src1_reg = ginsn_dw2_regnum (src1, true); >>>> + src2_reg = ginsn_dw2_regnum (src2, false); >>>> + >>>> + ginsn = ginsn_func (insn_end_sym, true, >>>> + GINSN_SRC_REG, src1_reg, 0, >>>> + GINSN_SRC_REG, src2_reg, 0, >>>> + GINSN_DST_REG, dst_reg, 0); >>>> + ginsn_set_where (ginsn); >>> >>> It looks like this ignores any shift that is applied to src2_reg. >>> >> >> Yes. An add/sub operation with two source registers makes REG_SP/REG_FP >> untraceable (if dest is REG_SP/REG_FP), so any further information >> carried forward in the ginsn is of little use for SCFI. >> >> For a usecase apart from SCFI, yes, this may amount to loss of vital >> information. I will add a TBD_GINSN_INFO_LOSS comment. > > If SCFI doesn't handle add/sub of two registers, then do we still > need this code for correctness? I would have expected SCFI to handle > unrecognised writes to SP in a conservative way, even if there is no > ginsn type defined for the instruction that sets SP. > Correct, we dont need the two register ADD/SUB for SCFI correctness. A placeholder insn like GINSN_TYPE_OTHER emitted via the aarch64_ginsn_unhandled () code path should also be sufficient for SCFI. >>>> + if (opnd->type == AARCH64_OPND_Rd_SP) >>>> + { >>>> + dw2_regnum = ginsn_dw2_regnum (opnd, true); >>>> + if (dw2_regnum == REG_SP) >>>> + skip_p = true; >>>> + } >>>> + break; >>>> + >>>> + default: >>>> + break; >>>> + } >>>> + >>>> + return skip_p; >>>> +} >>>> + >>>> +#define AARCH64_GINSN_UNHANDLED_NONE 0 >>>> +#define AARCH64_GINSN_UNHANDLED_DEST_REG 1 >>>> +#define AARCH64_GINSN_UNHANDLED_CFG 2 >>>> +#define AARCH64_GINSN_UNHANDLED_STACKOP 3 >>>> +#define AARCH64_GINSN_UNHANDLED_UNEXPECTED 4 >>>> + >>>> +/* Check the input insn for its impact on the correctness of the synthesized >>>> + CFI. Returns an error code to the caller. */ >>>> + >>>> +static int >>>> +aarch64_ginsn_unhandled (void) >>>> +{ >>>> + int err = AARCH64_GINSN_UNHANDLED_NONE; >>>> + aarch64_inst *base = &inst.base; >>>> + const aarch64_opcode *opcode = base->opcode; >>>> + aarch64_opnd_info *dest = &base->operands[0]; >>>> + int num_opnds = aarch64_num_of_operands (opcode); >>>> + aarch64_opnd_info *addr; >>>> + unsigned int dw2_regnum; >>>> + unsigned int addr_reg; >>>> + aarch64_opnd_info *opnd = NULL; >>>> + unsigned int opnd_reg; >>>> + bool sp_allowed_p = false; >>>> + >>>> + /* All change of flow instructions are important for SCFI. */ >>>> + if (opcode->iclass == condbranch >>>> + || opcode->iclass == compbranch >>>> + || opcode->iclass == testbranch >>>> + || opcode->iclass == branch_imm >>>> + || opcode->iclass == branch_reg) >>>> + err = AARCH64_GINSN_UNHANDLED_CFG; >>>> + /* Also, any memory instructions that may involve an update to the stack >>>> + pointer or save/restore of callee-saved registers must not be skipped. >>>> + Note that, some iclasses cannot be used to push or pop stack because of >>>> + disallowed writeback: ldst_unscaled, ldst_regoff, ldst_unpriv, ldstexcl, >>>> + loadlit, ldstnapair_offs. FIXME double-check. >>>> + Also, these iclasses do not seem to be amenable to being used for >>>> + save/restore ops either. FIXME double-check. */ >>>> + else if (opcode->iclass == ldstpair_off >>>> + || opcode->iclass == ldstpair_indexed >>>> + || opcode->iclass == ldst_imm9 >>>> + || opcode->iclass == ldst_imm10 >>>> + || opcode->iclass == ldst_pos >>>> + /* STR Zn are especially complicated as they do not store in the same byte >>>> + order for big-endian: STR Qn stores as a 128-bit integer (MSB first), >>>> + whereas STR Zn stores as a stream of bytes (LSB first). FIXME Simply punt >>>> + on the big-endian and little-endian SVE PCS case for now. */ >>>> + || opcode->iclass == sve_misc) >>>> + { >>>> + opnd = &base->operands[0]; >>>> + addr = &base->operands[num_opnds - 1]; >>>> + addr_reg = ginsn_dw2_regnum (addr, true); >>>> + opnd_reg = ginsn_dw2_regnum (opnd, false); >>>> + /* For all skipped memory operations, check if an update to REG_SP or >>>> + REG_FP is involved. */ >>>> + if ((addr_reg == REG_SP || addr_reg == REG_FP) >>>> + && (((addr->addr.postind || addr->addr.preind) && addr->addr.writeback) >>>> + || aarch64_scfi_callee_saved_p (opnd_reg))) >>>> + >>>> + err = AARCH64_GINSN_UNHANDLED_STACKOP; >>> >>> The way I'd imagined this working is that we'd use two-directional data >>> flow to record which callee-saved registers are "protected" at which >>> instructions. That is, for saves we'd walk the cfg forward from the >>> entry point, recording which registers have been saved earlier in the walk >>> (and being conservatively correct for cycles). And for restores we'd >>> walk the cfg backwards from the exit points, recording which registers >>> are restored later in the walk. If a register is both "saved ealier" and >>> "restored later" for a given instruction, it wouldn't matter what the >>> instruction does with that register. >>> >>> (For infinite loops we would pretend that all registers are restored later.) >>> >>> It seems like instead, we'd generate a warning for: >>> >>> ... >>> str d8, [sp, #...] >>> ... >>> ld1d z8.b, p0/z, [sp, #...] >>> ... >>> ldr d8, [sp, #...] >>> ... >>> ret >>> >>> even though that should be ok (even without interpreting SVE instructions). >>> >>> On the other hand, any read or write of a callee-saved register is suspicious >>> if it isn't saved earlier or isn't restored later. >>> >>> In other words, it seems like this information should be context-dependent, >>> or used in a context-dependent way. Whether a particular register matters >>> depends on whether the register might still contain the caller's data. >>> >> >> We do something similar for non-memory ops: >> - In the aarch64_ginsn_unhandled () codepath, if the destination is of >> interest (REG_SP, REG_FP), synthesize a GINSN_TYPE_OTHER with the >> appropriate destination register if no ginsn has been generated. >> - The SCFI machinery checks if this instruction affects SCFI correctness. >> - If it does, only then the insn is issued a complaint for and brought >> to attention. >> >> What you suggest is take a similar approach for memory operations too. >> I think it makes sense. It needs some work now to accommodate this, but >> I think we can re-evaluate after some basic handling for Z registers is >> in place ? I plan to work on adding handling for Z registers after this >> series is merged. (I have renamed an old testcase involving Z registers >> to "scfi-unsupported-2.s" to keep track of the currently unsupported >> cases to be worked on in near future, so I dont lose track of this..). > > Yeah, leaving it till later sounds ok. But I don't think this should > depend on recognising Z loads and stores. It should just depend on > processing Z registers in the operand lists, and recognising that the > low 64 bits of Z8-Z15 are the same as D8-D15. > Yes it is orthogonal recognizing Z loads and stores. I just meant that once we recognize Z loads and stores, the utility of such a workflow (i.e., do not error out on unrecognised load/stores conservatively as they may not be necessary for SCFI correctness at all) is reduced as less code blocks will trigger that. > In other words, I imagined the set-up would be: > > (1) the operand list should tell us whether a register is referenced > > (2) recognising 8-byte+ loads and stores, plus support arithmetic, > lets us recognise instructions that would function as a save or > restore (and at what offset) > > (3) dataflow analysis based on (2) tells us, for a given instruction, > which registers might have caller data > > (4) A reference to possible caller data triggers a warning > (references detected by (1), caller data by (3)) > > Is that roughly how it works? > Roughly yes. I need to hook a few more things in (3) for the additional warning.