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 03DE03857C52 for ; Wed, 10 Jan 2024 19:44:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 03DE03857C52 Authentication-Results: sourceware.org; dmarc=pass (p=none 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 03DE03857C52 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=1704915850; cv=pass; b=jU0osyKsT2f+n8ZWmTaMmMa1HL2a6SL755bOgARMc7sSUGr+RPJNwpJADkGPjZNFSBX8cCfreREOJXiajobtqIUqEiKEuh3liaIzAv1JaKuICi+qY7F6/DNl04pq5f+Oeb6xHVOhDChjGiu6fywBuh3Y4HusGpF8bST/nfbNaO4= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1704915850; c=relaxed/simple; bh=mLNTS85LU3nfsl58WX5ouhsaoz8UTG90v3dGl8ifBQk=; h=DKIM-Signature:DKIM-Signature:Message-ID:Date:Subject:To:From: MIME-Version; b=eiALj8hPETmaTAOYl0iC89nrEEhyY9gjIJIrrcqKTuq5fWp1A5kiLFYcsyodZzY4kfOZJMbWAVHTkEtMAw0zZZqE4gXAHKzDvDU+LcXCRO/93hoc7kI2jqoJn7Vn/AKMc5Xr1ru5ZO1nxaPN9dGxUTnSsemQQDw482dGPC5KXFI= 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.17.1.19/8.17.1.19) with ESMTP id 40AHtsr6013146; Wed, 10 Jan 2024 19:44:06 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=message-id : date : subject : to : cc : references : from : in-reply-to : content-type : content-transfer-encoding : mime-version; s=corp-2023-11-20; bh=DVGWFbcKgHyubbqVGgar5KE/TC4j40QB8Vn7Hn+gP6Y=; b=kS/0gP0wIC//k5y0/dMJdhUF3LDo6+6usp3EEM0CS+/fL37GRIw0j+8rSjrQ45udlYs6 4YWMbqvRbDnEZzVUjOCxyCdYl2sgdBarRMr0KYPWZGA+WDDZ1cTFa8KykMfQXRmvKE04 i9MWrHHGlxnrbl9LDFIj3Lgzjywe5fLv6CU3J6fTIzpa5LvvrLozXWjPS/dwqTabzz2a /n60jjVPI72Db+/gRmbNVn0tu7w01dXwnnvgHQleUjWYlUxVOpogy78LKenYlDEs5v1E pMU95nWQhgtRMHb8f0JaLTZos3uc48AhbJlVbIJ1I9Z6IDbo/QZyp2TlqKxbOd4hQuTx lw== Received: from iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta02.appoci.oracle.com [147.154.18.20]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 3vhs1x1767-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 10 Jan 2024 19:44:06 +0000 Received: from pps.filterd (iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1]) by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (8.17.1.19/8.17.1.19) with ESMTP id 40AIdPVv012177; Wed, 10 Jan 2024 19:44:05 GMT Received: from nam12-bn8-obe.outbound.protection.outlook.com (mail-bn8nam12lp2169.outbound.protection.outlook.com [104.47.55.169]) by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id 3vfuwjw7t4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 10 Jan 2024 19:44:05 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=X2jIEE8x4r5V+mfgyJYxkYSusEyeUtsj9tD/2NfkhC3yJ8rQjIrY6Aj5QiFEzc8MckK+J/M21T5aVjT582Yh4cmvky83NJ2q2Q4HBuOFOer9NKK1+b/NryQUMX2ruAnPjlSDqcXiT0n3AWwf65OpY5i8MdSYAXsHfX+t8G4I3C71YCjj/5elJFLMWN5YpsWax9TgVwti9PlQ8XnIpZNrGiesGmBqyrCo7zP2SAeC+XM5UajGhURipLIUS9ZbkvCcOlt4lgaG6LteJd0S1dXYu7cBQZdoJHrFoT73SYWt3mh6NSoIGQOVCUopOSS24rrV7yNpwNgXfX/weerPVRkC5Q== 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=DVGWFbcKgHyubbqVGgar5KE/TC4j40QB8Vn7Hn+gP6Y=; b=cnRmVGLGwAONIHrH6ZRJjgmilaA5VeAyOh8hKcZxFl5Ta6QfsYTMx1NraReZU9ibBhF/B9CrUAAsxDqTcKePw9jH9NN+t2R/EMrV1gaqMBtWj+LlanJ9zWjQvo/S2hx8KWcbeacuPnPbHBpxhwij0sIqGymQlox9j1WOyWnwyU+DGknpuM/ZAyBQBuQQG6eRpIqtJrfrATcGgqf4cb7bm9QQ55mGBzPw9qrEIoHqo4BCSPJkNa6Uo7SL8TBU4VnUsGfDgCDozlxpdaaQsgWJYEJ3HiaoPV2nFbyOQ3wY1dVqBgrzYKFDlMWFXUHi/aLEho2s08+ScUznoTM2dC6NLA== 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=DVGWFbcKgHyubbqVGgar5KE/TC4j40QB8Vn7Hn+gP6Y=; b=szsmwcDMsfLDYwiAEASWM7ySoloNI0tcrLMVGClK4yT/FOdF7mImWhwXgXLo7w84Hp9cGUhX1QCkw9ZekGv8+9sF9mohSHCQN2j8eWAQ8+KWlXNwwPe5Sy4qnP71aQC2uUPiVjtRAnyKasQFuKSJm0fJnEaDpveRLfmLA6wC5W4= Received: from MWHPR1001MB2158.namprd10.prod.outlook.com (2603:10b6:301:2d::17) by SJ0PR10MB5801.namprd10.prod.outlook.com (2603:10b6:a03:423::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7181.17; Wed, 10 Jan 2024 19:44:03 +0000 Received: from MWHPR1001MB2158.namprd10.prod.outlook.com ([fe80::fde7:fb92:8ea1:a5ac]) by MWHPR1001MB2158.namprd10.prod.outlook.com ([fe80::fde7:fb92:8ea1:a5ac%4]) with mapi id 15.20.7159.020; Wed, 10 Jan 2024 19:44:03 +0000 Message-ID: Date: Wed, 10 Jan 2024 11:43:59 -0800 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH,V4 10/14] gas: synthesize CFI for hand-written asm Content-Language: en-US To: Jan Beulich Cc: binutils@sourceware.org References: <20240103071526.3846985-1-indu.bhagat@oracle.com> <20240103071526.3846985-11-indu.bhagat@oracle.com> <0ecd9240-0700-4072-91d4-ccf9bdb56071@suse.com> <055b92ae-b781-41e8-bd34-4ad68bdc5f6f@suse.com> <78b9f98f-2030-4675-af0a-8f47d195711b@oracle.com> <20b71f7f-7c8b-41fd-a85c-6887cc19e5ff@suse.com> <409f6d2d-cd7e-4822-a29a-8970655c5af0@oracle.com> From: Indu Bhagat In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: MW4PR03CA0285.namprd03.prod.outlook.com (2603:10b6:303:b5::20) To MWHPR1001MB2158.namprd10.prod.outlook.com (2603:10b6:301:2d::17) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MWHPR1001MB2158:EE_|SJ0PR10MB5801:EE_ X-MS-Office365-Filtering-Correlation-Id: 8fd4f0a4-0114-426d-33d0-08dc12147feb X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Kbi28P6UCr1HxH6WatgDbH4au4DD+DNfGpQW9hJWXZXzCXka8WyQtvrcE4DhGNTl7c79R9SYizt9R0BUTULCdUWQa90OMd9yICU2Q7/RI846gTQKuw7CqnwAhPRWr7XSucld90F0Unu1I7zzyPsUzJX05pi0R9NcT11aAVkOl61gIyruqByvUpsthodxmm2/BDILknEgs7Hoi5i6lu5kFkszDcGu0vLSPKiTJb3Uw/6KGjyjFDuppwZuZH09NdJSeohXqsiRIeRqnft5s9qZ+morPhiqCOq8dd5VxdO0U8gpGxaHp5Wl+/8Yy+mjuXIXWqflfVLdWxxQwjODpM3FYlnkiYg3OovnpHV9r9Bh1YGlF8TCJKyE59ZpCjUik5jkpUW9CiSvoquDsYTV1pDAF8vlySOi+ER3D1IJ6CUfhcb4ohSuv0bGU5p6i6ype737iHlXkCIOMy3lSHVFq8UpX2itZOclp/v1MrKeFUE5FVnRkLrxv25GUVf1jbFoKievBbfXCIoTn97eZLTwgkYxyJYJAggeLHfv+HBwYW4Bkenz3DpKxqb85ASBCc8MI1aiQgjIDn7GoOIK4vM/Yz7X1QBpdE0xKEyUqcMJnPvWbuzZcqdmCE633y6DbvNTNshiHI/eWOXiX37RF2P9JUNyug== X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:MWHPR1001MB2158.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(366004)(346002)(39860400002)(376002)(136003)(396003)(230922051799003)(451199024)(64100799003)(1800799012)(186009)(478600001)(966005)(6486002)(38100700002)(83380400001)(31686004)(31696002)(8676002)(44832011)(4326008)(36756003)(8936002)(316002)(6916009)(66476007)(66556008)(66946007)(6506007)(6512007)(2616005)(86362001)(53546011)(6666004)(5660300002)(2906002)(30864003)(66899024)(41300700001)(45980500001)(43740500002);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?NzJWMkR4S3NsTEp1a2k1VTlhcG56eUcxS1E3d29Bb2ZRV1VUZHVrUloxWXhx?= =?utf-8?B?RC9SMGF2VnZDbzYvaDdEWXB1ZFd2TEx2ZGlaS0JVRUMyc0o1aG0vUXdzV2lV?= =?utf-8?B?Q1hPdFA0NmZ3YWhvb2tVcVVRQzBvNzZHbyt3S1IvRjM1R0NqWk91RDRJZTR1?= =?utf-8?B?SW5nWktZZUFMU1VqNXNQZlQvMFZlUE01YkJlWEo5R3dHMlJoWThQdTdFSVZM?= =?utf-8?B?K0dqNlowYklyNEhPbVFVSmJBU0wyS2FOamFwWDB4SDAzc05EWWpQc0tEQ3Yw?= =?utf-8?B?YmtaZnFrS0pZU2JLQXJsUTArZkNvclZMYW1VWFdXTFlrQUxQem5NbnJFUnN6?= =?utf-8?B?RmZyTDA0WHhla1A1dzM4aUlTcVAySWgyQ0RFNnZzdC9wbllpK1NqVmxBMzFZ?= =?utf-8?B?UFlSb1cyMVR6VjBGZFZ2U0lXcmZXRGpjTTJjRkkyYzk3d0hJUTdpeDZIYkNX?= =?utf-8?B?VWhtanBwWFQyN1cvQ01VK3g0RzJBOUhHSENwMVRLK1NMZDh6eGRGclJFRG1B?= =?utf-8?B?dm5LdVlqcnkwVzltd2xXRDQ2dFY5SFNaczlNNDNvbUFXbFpubkF3SXB1S1Rt?= =?utf-8?B?bU5SaWpUOEgzMHJickxFazZXcUtNMGJGcTVNOUZUMVgwZnByU1lGVzN3THpn?= =?utf-8?B?TGw0cU4xeVFUR1hVelVTaGtDMCtwa0licnBCSnJOOUplZjd6cTQwNlRnclFy?= =?utf-8?B?dTQwL3JhQUx2b2lrWDlTS1BXOE9pTzN5aCswQzlNY0N6bTBWTjN6UUh6RVNG?= =?utf-8?B?OUUyc284L2EyNndyQU91VS9zWElWVTNpbFFNYjNtSmpsM0VWRWgxK3lpWGg0?= =?utf-8?B?QmFKaEh1V0tDSW8xT1JGSHpvOE5ucVpKWHlUdDNGRFdrblJJdDdNTGFDTG9R?= =?utf-8?B?cGJ3cjRpVXJrZS9JWSt0R29PVTBQN050WDRyQ1pnOU1hL0wyODFnYnpTenRV?= =?utf-8?B?N1VoMERQRUFtWTVqRy9UQ3JkTTQ3QXYwSGd4bWRRc20rS3NpZ0pWQ2xnMUx2?= =?utf-8?B?RUY3NlJQa0RtUTZPV09BeXQrdGxGcis0MFd6b1FQQzE4K29OWUhpRzVGbWNw?= =?utf-8?B?SE8wYUZ0QmViWG5RbGxnZEVxdFdKWlA5ZE9mM2NVSEFVaTRwdXVubklvaUR0?= =?utf-8?B?NFVXTE9IbHZiaW1ScVNzQlowSVVtTjRaZGZXc2JFNGhkdEZJTUtQaHFYQnho?= =?utf-8?B?QzRRT3FoUkJ6NmllSEV5NndHbm1Ta0w2NHBkQmtxZDJubUtqOURHbHFxSkRu?= =?utf-8?B?VkZwM29XdEttUkRKREFxOE5rc0k3bmwzeGFqQnRHV3kyM01WcFpaRHJGdmVL?= =?utf-8?B?aG5kc29ZS2tyZVFNeDEwd01HUnhHclJnSVpDb2dGNWNVUFNNdDIzVklGNWE2?= =?utf-8?B?ME9nS0sxNDRQc2Z5UnAzc2VFSm1DUmlrbkVBZjZ5R2Z5cVl2eDNzcEFubmZ6?= =?utf-8?B?SUNCVGNvWUdlc3NJcFdjSDdHQ3V1V3daZU42ZXpBTXJ0NHpBdS9WejdJbkpC?= =?utf-8?B?VlVCYTgrb3ROaHdDUlpwQWNyOS93aGZqVEU3aU0rdkYxMWxoQVpGTG96aWxw?= =?utf-8?B?UmlMb2NZQUFtNWE5Wlg5U3dqUU9yYjdOOFhhaE85U0Nwb01FRG5IRkdtWllN?= =?utf-8?B?V29SWjZ5MkVwVHVmRkFSSm9qUnVMS082S3RBeHVVTzhIQTZQZVVydTlCbk5t?= =?utf-8?B?T1hPaStaelhIWEVPV3lpaS9vckNseFVtb1VRY01XVWh5N09LaWNYOHhrNm5O?= =?utf-8?B?b282VDd4M3AxQS8rM2FhWEllUmFYUFgyMk5jdVhwVFVpUVFPdDEvWTVURUNk?= =?utf-8?B?Y3ZzQmZ5ZHg5M1VLWkNnVDRqMCtZQkxqaThNRGVpelRCai9mL3R5SEJuUXhZ?= =?utf-8?B?bzQ2QVZ5N0pGM0JQUnp0T1BVWjlQaERtVmRHN1ZYTStFUFRneHkxc2dzUVoy?= =?utf-8?B?T2w3YjJPeHhoMU5nOHlYeG91ckdqVW4wNi9CMU9PUHN3RHdTbzV4OVo0bllC?= =?utf-8?B?N0lCeFJsOFhaa29EVXdXcThvekpkaVdDT1krNVlQMHhrUFJZNzFRRUY5SFFC?= =?utf-8?B?MkRrSEt6ZzJVTE5OVzd0clFGRFg5Yk5ybjVOdjJJdkMxc0F2c0RxcjlxeVBR?= =?utf-8?B?dHgzeXVseng4MS9qRktwN0RCSDlFTmtkeVBNK1Z0VC9jdEo2YlNtQUh6MGpC?= =?utf-8?Q?jAPkJj/ZyOJQ576oUTyQfv0=3D?= X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: B3f0mcxBJ+twBjtQuP1E6n7MwUyf7CfIx0ThTJ2a9qi4S1fDmFm91jkO1a0h4C9wpjM5g/figUKclNB57sPaF0PjkGLcTuG70co9OV5dtUEUg2BnOfkJR3bIc5kHthqR5MFr7qnyqQ45+/q19ZPRGs2G52yGKMAhW9VXPmdMj5oKzVAugQnYStmDHssjSNSAxcQRvXfPmOEwXIKSr2MtugjQvNLnw6nMaVc8wlFu/b3NXka7Dpf3mydbHwxvRLorH+pVC3qxZB1a4VhF5VZdmGykuk0uVAOvDX/aD+qhRZh98xNZDN5Sc2PrQeCZNIqpBLtOWQ1qYFqZqHz4TwX39fhP40clzwHhS81hrANA+jg93oaRJObHBGTOY8OPKdDoC84CvXMfQbehM/+IzzczpI6e1sPrjs+w9dr+EhjcT90t/s96evolXjE7E5ys2ccOKCKJND3T8IDPeC72x/uiFLHYZ+9EGPyGFDxaN7BtzJLHxPY85LlreSfE6Ai0QFCKOgKkTUInDHRIbsgh6bvVbfAmstd6JqFcQ6AgIlSUz5g5dOivzv1Wv5rUJs9xJBlw0VN/mCgNJWUbLFD71CNbJw2agLFblD+0bofn7HI/BvA= X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8fd4f0a4-0114-426d-33d0-08dc12147feb X-MS-Exchange-CrossTenant-AuthSource: MWHPR1001MB2158.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Jan 2024 19:44:03.6053 (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: QzgHQTUXFZgA9m6jUyu058CVUL1jbaGhX57CGaGPshlddrB/iRWx7PmOBcGQx7Oy5OZI34PbZv+Scxlp3L7WcQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR10MB5801 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.997,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2024-01-10_10,2024-01-10_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 mlxscore=0 bulkscore=0 mlxlogscore=999 adultscore=0 spamscore=0 phishscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2311290000 definitions=main-2401100157 X-Proofpoint-ORIG-GUID: EHpgHsY5sLQyTsZdU5sEAEAxuqqYpDkq X-Proofpoint-GUID: EHpgHsY5sLQyTsZdU5sEAEAxuqqYpDkq X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE 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 1/10/24 06:15, Jan Beulich wrote: > On 10.01.2024 12:26, Indu Bhagat wrote: >> On 1/10/24 01:44, Jan Beulich wrote: >>> On 10.01.2024 07:10, Indu Bhagat wrote: >>>> On 1/9/24 01:30, Jan Beulich wrote: >>>>> On 08.01.2024 20:33, Indu Bhagat wrote: >>>>>> On 1/5/24 05:58, Jan Beulich wrote: >>>>>>> On 03.01.2024 08:15, Indu Bhagat wrote: >>>>>>>> +/* Check whether a '66H' prefix accompanies the instruction. >>>>>>> >>>>>>> With APX 16-bit operand size isn't necessarily represented by a 66h >>>>>>> prefix, but perhaps with an "embedded prefix" inside the EVEX one. >>>>>>> Therefore both the comment and even more so ... >>>>>>> >>>>>>>> + The current users of this API are in the handlers for PUSH, POP >>>>>>>> + instructions. These instructions affect the stack pointer implicitly: the >>>>>>>> + operand size (16, 32, or 64 bits) determines the amount by which the stack >>>>>>>> + pointer is decremented (2, 4 or 8). When '66H' prefix is present, the >>>>>>>> + instruction has a 16-bit operand. */ >>>>>>>> + >>>>>>>> +static bool >>>>>>>> +ginsn_prefix_66H_p (i386_insn insn) >>>>>>> >>>>>>> ... the function name would better not allude to just the legacy >>>>>>> encoding. Maybe ginsn_opsize_prefix_p()? >>>>>>> >>>>>> >>>>>> Isnt 66H_p more readable and easier to follow because that's what the >>>>>> function is currently checking ? If more scenarios were being handled, >>>>>> ginsn_opsize_prefix_p () would fit better. >>>>> >>>>> Well, as said - with APX you can't get away with just 0x66 prefix checking. >>>>> That prefix is simply illegal to use with EVEX-encoded insns. >>>>> >>>> >>>> I am using the following in ginsn_opsize_prefix_p (): >>>> >>>> !(i.prefix[REX_PREFIX] & REX_W) && i.prefix[DATA_PREFIX] == 0x66 >>> >>> That addresses one half of my earlier remarks. Note however that elsewhere >>> we never check i.prefix[DATA_PREFIX] against being 0x66; we only ever check >>> for it being zero or non-zero. I'd like this to remain consistent. >>> >>> For EVEX-encoded APX insns this isn't going to be sufficient though. See >>> respective code in process_suffix(): >>> >>> /* The DATA PREFIX of EVEX promoted from legacy APX instructions >>> needs to be adjusted. */ >>> if (i.tm.opcode_space == SPACE_EVEXMAP4) >>> { >>> gas_assert (!i.tm.opcode_modifier.opcodeprefix); >>> i.tm.opcode_modifier.opcodeprefix = PREFIX_0X66; >>> } >>> else if (!add_prefix (prefix)) >>> return 0; >>> >>> So you'll need to also check for that combination, plus take care of >>> avoiding insns where PREFIX_0X66 alters operation, not operand size >>> (ADCX being an example). >>> >> >> But I am now disallowing APX insns for now, altogether, by doing this in >> the x86_ginsn_new: >> >> /* Until it is clear how to handle APX NDD and other new opcodes, disallow >> them from SCFI. */ >> if (is_apx_rex2_encoding () >> || (i.tm.opcode_modifier.evex && is_apx_evex_encoding ())) >> { >> as_bad (_("SCFI: unsupported APX op %#x may cause incorrect CFI"), >> opcode); >> return ginsn; >> } > > Well, if that's what you want to do ... (Even if you wanted to not support > APX for now, I would have expected the catch-all looking at just the > destination register to properly diagnose any use.) > I did intend to do it like that (tackle them in the unhandled insns codepath). I tested for some APX insns (push2, pop2, push2p, add, adc etc) and added a testcase scfi-unsupported-insn-1.s. So far so good. But later I realized that I should test more APX insns in general: failures in translation to ginsn is what I would like to test more. I will work it out in a separate patch later after the series goes in and remove this check and updating ginsn_opsize_prefix_p (). >>>>>>>> + } >>>>>>>> + >>>>>>>> + ginsn_set_where (ginsn); >>>>>>>> + >>>>>>>> + return ginsn; >>>>>>>> +} >>>>>>> >>>>>>> Throughout this function (and perhaps others as well), how come you >>>>>>> don't consider operand size at all? It matters whether results are >>>>>>> 64-bit, 32-bit, or 16-bit, after all. >>>>>> >>>>>> Operation size matters: No, not for all instructions in context of SCFI. >>>>>> For instructions using stack (save / restore), the size is important. >>>>>> But for other instructions, operation size will not affect SCFI correctness. >>>>> >>>>> But aren't you wrongly treating an update of %rbp and an update of, >>>>> say, %bp the same then? The latter should end up as untracable, aiui. >>>>> >>>> >>>> For ALU ops: >>>> - ADD/SUB reg1, reg2 >>>> If reg2 is the same as REG_CFA, then even in 64-bit mode, this >>>> causes untraceability. So there is untraceability irrespective of >>>> operation size. On the other hand, if uninteresting, it will remain >>>> unintersting irrespective of operation size. >>>> - ADD/SUB imm, reg will never trigger untraceability, irrespective of >>>> size. There is the element of ignoring the carry bit, but I think the >>>> current diagnostics around "asymmetrical save/restore" and the planned >>>> "unbalanced stack at return" should provide user with some safety net. >>> >>> I don't see how the carry flag would matter here. What does matter is the >>> size of the register: Anything not 64-bit will need to trigger >>> untraceability imo. >>> >> >> - For a 16-bit ADD/SUB imm, reg insn: if the 16-bit result had a >> carry, it will be ignored as only 16-bit result is copied to the >> destination address IIUC. If there is no carry bit, 16-bit ADD/SUB imm, >> reg is semantically the same insn as a 64-bit ADD/SUB imm, reg for the >> same immediate. > > Oh, that's where you see CF coming into play. I wouldn't view it from > this angle - you simply don't know whether overflow/underflow would > occur, so it's no different to ... > >> - For 32-bit ADD/SUB imm, reg insn: yes, I stand corrected. It should >> trigger untraceability as upper 32-bits are zeroed out. IMO, this 32-bit >> operation should likely be unintentional by the user; something better >> alerted to the user if we can. > > ... this case. > Hmm. Yes, I agree. I will address handling of 8-bit/16-bit/32-bit ops in a separate patch later. >>>>>>>> +/* Generate one or more generic GAS instructions, a.k.a, ginsns for the current >>>>>>>> + machine instruction. >>>>>>>> + >>>>>>>> + Returns the head of linked list of ginsn(s) added, if success; Returns NULL >>>>>>>> + if failure. >>>>>>>> + >>>>>>>> + The input ginsn_gen_mode GMODE determines the set of minimal necessary >>>>>>>> + ginsns necessary for correctness of any passes applicable for that mode. >>>>>>>> + For supporting the GINSN_GEN_SCFI generation mode, following is the list of >>>>>>>> + machine instructions that must be translated into the corresponding ginsns >>>>>>>> + to ensure correctness of SCFI: >>>>>>>> + - All instructions affecting the two registers that could potentially >>>>>>>> + be used as the base register for CFA tracking. For SCFI, the base >>>>>>>> + register for CFA tracking is limited to REG_SP and REG_FP only for >>>>>>>> + now. >>>>>>>> + - All change of flow instructions: conditional and unconditional branches, >>>>>>>> + call and return from functions. >>>>>>>> + - All instructions that can potentially be a register save / restore >>>>>>>> + operation. >>>>>>> >>>>>>> This could do with being more fine grained, as "potentially" is pretty vague, >>>>>>> and (as per earlier version review comments) my take on this is a much wider >>>>>>> set than yours. >>>>>> >>>>>> I would like to understand more on this comment, especially the "my take >>>>>> on this is a much wider set than yours". I see its being hinted at in >>>>>> different flavors in the current review. >>>>>> >>>>>> I see some issues pointed out in this review (addressing modes of mov >>>>>> etc, safe to skip opcodes for TEST, CMP) etc., but it seems that your >>>>>> concerns are wider than this. >>>>> >>>>> I earlier version review I mentioned that even vector or mask registers >>>>> could in principle be use to hold preserved GPR values. I seem to recall >>>>> that you said you wouldn't want to deal with such. Hence my use of >>>>> "wider set": Just to give an example, "kmovq %rbp, %k0" plus later >>>>> "kmovq %k0, %rbp" is a pair of "instructions that can potentially be a >>>>> register save / restore operation". >>>>> >>>> >>>> Hmm. I will need to understand them on a case to case basis. For the >>>> case of "kmovq %rbp, %k0" / "kmovq %k0, %rbp" how can this be used as >>>> save/restore to/from stack ? >>> >>> Maybe I'm still not having a clear enough picture of what forms of insns >>> you want to fully track. Said insn forms don't access the stack. But they >>> could in principle be used to preserve a certain register. Such preserving >>> of registers is part of what needs encoding in CFI, isn't it? >>> >> >> The kind of preserving is usually on stack. It can also be in another >> callee-saved register, in theory, but the latter defeats the purpose of >> state saving across calls. > > Callee-preserved registers, when they have a special purpose in the > architecture (like %rsi, %rdi, and %rbx have) may be cheaper to > preserve by moving to a call-clobbered register that isn't otherwise > used in the function. In the SysV ABI this only affects %rbx, the > special purpose of which is extremely limited in the ISA (xlatb). In > the Windows ABI, otoh, %rsi and %rdi are callee-preserved, and those > have very common uses in the string insns. > I am not sure I follow completely. Call-clobbered registers are not of interest for SCFI... >> BTW, I had earlier written down some notes about SCFI >> https://sourceware.org/pipermail/binutils/2023-September/129558.html >> Some bits are stale already though, but may be it helps. > > I had read through this before first reviewing v1 (I think it was). > >>>>>>>> + case 0xc2: >>>>>>>> + case 0xc3: >>>>>>>> + if (i.tm.opcode_space != SPACE_BASE) >>>>>>>> + break; >>>>>>>> + /* Near ret. */ >>>>>>>> + ginsn = ginsn_new_return (insn_end_sym, true); >>>>>>>> + ginsn_set_where (ginsn); >>>>>>>> + break; >>>>>>> >>>>>>> No tracking of the stack pointer adjustment? >>>>>> >>>>>> No stack unwind information for a function is relevant after the >>>>>> function has returned. So, tracking of stack pointer adjustment by >>>>>> return is not necessary. >>>>> >>>>> What information does the "return" insn then carry, beyond it being >>>>> an unconditional branch (which you have a different insn for)? >>>>> >>>> >>>> "return" does not carry any more information than just the >>>> GINSN_TYPE_RETURN as ginsn->type. >>>> >>>> So then why support both "return" and an unconditional branch: The >>>> intention is to carry the semantic difference between ret and >>>> unconditional jump. Unconditional jumps may be to a label within >>>> function, and in those cases, we use it for some validation and BB >>>> linking when creating CFG. Return, OTOH, always indicates exit from >>>> function. >>>> >>>> For SCFI purposes, above is the one use. Future analyses may find other >>>> use-cases for an explicit return ginsn. But IMO, keeping >>>> GINSN_TYPE_RETURN as an explicit insn makes the overall offering cleaner. >>> >>> Okay. And here you don't bother decoding operands. Hence why I'm >>> asking the same to be the case for (e.g.) CALL. >>> >> >> It seems I will need to deal with operands of RETURN insn soon. For >> implementing "Warn if imbalanced stack at return", we will need this info. > > Will you? Isn't stack state _before_ the RET what matters (and hence > the optional immediate still doesn't matter)? > RET with operand makes this tricky. My initial thought was: "Balanced stack at function return" will check that the RSP at the entry of the function (after the call instruction) is the same as that at the return from the function (before the return instruction). Now if RET with operand (which tells how much stack to pop before an eventual return) is in effect, I do need to check the RSP value right before the RETURN (RETURN being the microOP/ginsn equivalent). Basically we want to alert if the RIP is not where RSP points to at RET. >>>>>>>> @@ -5830,6 +6804,14 @@ md_assemble (char *line) >>>>>>>> /* We are ready to output the insn. */ >>>>>>>> output_insn (last_insn); >>>>>>>> >>>>>>>> + /* PS: SCFI is enabled only for AMD64 ABI. The ABI check has been >>>>>>>> + performed in i386_target_format. */ >>>>>>> >>>>>>> See my earlier comment - it's yet more restrictive (as in not covering >>>>>>> e.g. the Windows ABI, which importantly is also used in EFI). >>>>>> >>>>>> Not clear, can you please elaborate ? >>>>> >>>>> Hmm, it's not clear to me what's not clear in my earlier comment. The >>>>> set of preserved registers, for example, differs between the SysV and >>>>> the Windows ABIs (see x86_scfi_callee_saved_p()). Then again, thinking >>>>> of it, talking of anything ABI-ish in assembly code is questionable. >>>>> An assembly function calling another assembly function may use an >>>>> entirely custom "ABI". You just cannot guess upon preserved registers. >>>>> >>>> >>>> I think the confusion is stemming from my usage of AMD64 colloquially to >>>> refer to System V ABI for x86_64. I think "System V AMD64 ABI" is the >>>> correct term. I will use that. >>>> >>>> And yes, GAS can only work out SCFI if there is ABI adherence. If input >>>> asm does not adhere to the supported ABIs, and the user invokes SCFI, >>>> then the user is on their own. GAS will not (rather can not) warn about >>>> ABI incompliance. >>> >>> I don't recall documentation stating this explicitly. This is a pretty >>> important aspect for users to consider, after all. >>> >> >> I added a reference in gas/NEWS for now. >> >> * Experimental support in GAS to synthesize CFI for ABI-conformant, >> hand-written asm using the new command line option >> --scfi=experimental on x86-64. >> >> I will add a mention of "ABI conformance" in as.texi. > > Maybe for NEWS this is enough; personally I don't think it is when there > are multiple ABIs for the/any affected architecture. You limiting support > to ELF doesn't mean the Windows ABI isn't in use. As said, UEFI uses that > ABI. And GNU ld can link ELF objects into EFI binaries. > I can add "Supported for System V AMD64 ABI" too in the gas/NEWS and as.texi for now. I dont have a resolution to "disallow Windows ABI on ELF with SCFI". I will take suggestions.