From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-00069f02.pphosted.com (mx0a-00069f02.pphosted.com [205.220.165.32]) by sourceware.org (Postfix) with ESMTPS id 3BC0F3858439 for ; Tue, 19 Dec 2023 07:07:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3BC0F3858439 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 3BC0F3858439 Authentication-Results: server2.sourceware.org; arc=pass smtp.remote-ip=205.220.165.32 ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1702969661; cv=pass; b=GgDhiljeB9Tjzo+tBzJZRiy4+YBkLoTVUOMPHwXR9iqbpQrt9h7asjJXXPiajkYeW+tpaf4WcFd/YSoQpNGhTei6TKwSzI1hHPcmyjEYxMueEfecOIpeNZiOftFAqBl7o+d2sDh+hFC9s5qWZ1PsIwWQHXX1bbgDAMSUVCL1S2I= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1702969661; c=relaxed/simple; bh=y/grwQoQx5tGehwccS5gc9O3sgRmlmIcIA6/H0+PZ9k=; h=DKIM-Signature:DKIM-Signature:Message-ID:Date:Subject:To:From: MIME-Version; b=SUw1dUMw+UFHXAlwTHcyCM49WzSGTJAjEAVJkSHJkoGxTlpr8lbwJr27VZl2EjbFMTqYME+AEW1Lzk8TiQDYGJS95XmBey+FCtUVXjfRFY1e/AJhCe/fIAO2FDg5jM+TUjtfeajuukGvwp9fM4wZAaeUxyEffWdnFs7qCw8AvT8= ARC-Authentication-Results: i=2; server2.sourceware.org Received: from pps.filterd (m0246617.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 3BJ0JUHx011345; Tue, 19 Dec 2023 07:07:38 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=QYzfqi3UsI+lOfVXLLczPuphaZEqbjAEoD/BTZlvZoE=; b=FsJ4pXDAaQ8sjdDIMXU4yztV87IEHd+467T4T9PpXDe0r5FBtkx+CsAQ5JJvZTpCcqQm QOrKQ9cZ4z3+Pc9O/mLNmnrMCYd9DiHrnBq6uM1veVYGT6YrVApG6NaMc8X0QTE9Mbqa rqdOYZBcx9vVruokxadhUFSJebvt363JtkHGMhHvCrFx6NZ8qyl4GzZINsfICK+RTvZe ooeABJSoIc0FNwwQN5pw1b8hpqU5hU09I5CIjorpDeG+aygDePoRbnZ+fq3fJtr0m4ID TsG6GSYCv1XEoPdl9p29XIRgqF6ClVfOVdq6WpBzXkepSJWpK34MMzNX6DYk0k+AkCqL 4Q== Received: from iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta03.appoci.oracle.com [130.35.103.27]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 3v14evd2gh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 19 Dec 2023 07:07:37 +0000 Received: from pps.filterd (iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1]) by iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com (8.17.1.19/8.17.1.19) with ESMTP id 3BJ6Ek9M028151; Tue, 19 Dec 2023 07:07:36 GMT Received: from nam02-dm3-obe.outbound.protection.outlook.com (mail-dm3nam02lp2040.outbound.protection.outlook.com [104.47.56.40]) by iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id 3v12bce2r5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 19 Dec 2023 07:07:36 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mrlixIV6+YYqtnCurhZRoSr8Iyo1QhOrqtHtgqjReT1RYvR8JRjAMsrbndKM0DaHHcJBDcyKPvVa027P4WChN1I94Se4IH62O2rJ2kwfmFEnLT8TMHgM6tQBD5z6HfKSbjRf2J7gNm8sf/OHh5XWlscy6KbvkacoxiEyyJxXML0gBSHGnwZYVPLEhZ3/GQOoWRGOEJ4eC2+FH3Xq89wRtEczykfbDWsJpGonnMcQ/NdCc0paGi1XHBUnbLGlJvAdVOMkGB4+oTqzL5Bj/jgSgzrFFX/LHLle+ibdFk3I9TuFpXdbsxGQwFPtBClQIshsPkJ8aOEwjloblX2yZ0FJvA== 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=QYzfqi3UsI+lOfVXLLczPuphaZEqbjAEoD/BTZlvZoE=; b=TT9yTkSpZs4G1VWpqXz6JlmySh/X7I0FkDs4RZatXDJ7WgwzylOoVaT6YzLQMaUF29YKky199cMN2EmLp7Fp4NrUIn2WViD14tbOhww/JZ+VkxaJuQHk61WGBRd9+fC0MJhLiX5n1HB6lbiBy4kZpqLIJidSiJCUhAO3uGDNDBsL2oG7r3XHLjD9g9f5h++b5W8FSwE99wi2P7k3uH5QEIPg7Q9dlgTocqA9WPzrBG3cInkyn3r/hzo9KME1HdnOmczS/2UTyuehlshTco88L8gEk0UlbomPZCxMgGpg9kiSVD6oHIPDy/DEGQRKm4FOCIdFJedzTBTlkHtactYCbw== 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=QYzfqi3UsI+lOfVXLLczPuphaZEqbjAEoD/BTZlvZoE=; b=SBNh7j02izoDxuG7UWmrfRyoneaesMbou8aEU/bPk3J1fs4GM5pD7sFGcFJN9e0qd1jRjohh+oqFdxXEbC2c2SMIipUGlFIVWcTW5xMO0LHObwCxMkM6Bcwg9bTpEB8obOJNigoEHPj4ioGkk95YDMRA/GD/ByTfUaC03Mls1Ug= Received: from MWHPR1001MB2158.namprd10.prod.outlook.com (2603:10b6:301:2d::17) by PH8PR10MB6672.namprd10.prod.outlook.com (2603:10b6:510:216::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7091.38; Tue, 19 Dec 2023 07:07:34 +0000 Received: from MWHPR1001MB2158.namprd10.prod.outlook.com ([fe80::88e2:4a2e:3111:e04]) by MWHPR1001MB2158.namprd10.prod.outlook.com ([fe80::88e2:4a2e:3111:e04%7]) with mapi id 15.20.7091.034; Tue, 19 Dec 2023 07:07:34 +0000 Message-ID: <6a6c837a-46d5-4fe1-945d-45621834631c@oracle.com> Date: Mon, 18 Dec 2023 23:07:32 -0800 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH, V2 07/10] gas: synthesize CFI for hand-written asm Content-Language: en-US To: Jan Beulich Cc: binutils@sourceware.org References: <20231030165137.2570939-1-indu.bhagat@oracle.com> <20231030165137.2570939-8-indu.bhagat@oracle.com> <7a101e5c-fe1d-4b3f-afdb-0ee11cf6a7c9@oracle.com> <060736aa-3a4f-320c-d0f6-37512be2e216@suse.com> <9ca4fc45-45b0-44f8-b9bc-3151f387d10a@oracle.com> From: Indu Bhagat In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: MW2PR2101CA0036.namprd21.prod.outlook.com (2603:10b6:302:1::49) To MWHPR1001MB2158.namprd10.prod.outlook.com (2603:10b6:301:2d::17) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MWHPR1001MB2158:EE_|PH8PR10MB6672:EE_ X-MS-Office365-Filtering-Correlation-Id: 01eb2735-d0a8-43a4-b58e-08dc00612c8b X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: rY6YJHlzBc9JpclYuh84V3De3GyDgfnrzUJ0NuG/SHvyDYkcyjLlwb//6JOPGJLoNPRQCOij9qHpWCFJkKcda2/1GVVz4WB3c+bPS4YAhJSH/aMBkqbN153UXcNcmXjFXkYXq/oqPAKwA6JD9/KYy2R37PIH2mH65+NrCoZfhrXiZL/XI+WPzI3OANOGdLUDCgPYp9oNBXjVlUbL+s/3rGGwwc1HzcHZvEkK+tmcCLi7KLLhuy3Zn9jpEyL/Aj2UcjKT08MyW8724353Z34GjsOPKJnsOJnIjz+a6H+DMkIe2Ose6SiFszuM/2tSIoyNXFM3EcRrFIF2SgSstyUKOZAHYu1x3PgyBbawT1uiRzw9Kvnd2jbvHrmwWOJG9RjR699B4WluxLOhphX4PIZtgMy1f4tOwy/VvcYTfliY6kn6YehHgf7USRwAa9xMuH64lgtiXX/YufVMiFIkMDQh6FcBbDQXOEaPRwCMTMpl5O3rx5OpxP2er8pnxZcp3lU8/5iDB141YgDSLbVJoUumJUv4m2HaQhg7k/3PBoN+IAVqdpk++kal4VXrRDekclTDre3Dgd4IeuAVnFB7QLPE/nd3XWyNIkcCQ/saRht69cMQ4GMtw7SbF4yIJZkidCgQaWoKsyxPKE7TmTN+3l39cYV2a3leBRRs0GCY1/f2tsYbXnDkdXep9/IKasowVSoD 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)(376002)(39860400002)(366004)(346002)(396003)(136003)(230922051799003)(230173577357003)(230273577357003)(64100799003)(451199024)(1800799012)(186009)(38100700002)(5660300002)(44832011)(8936002)(4326008)(8676002)(53546011)(6512007)(2906002)(66946007)(66476007)(66556008)(6916009)(316002)(83380400001)(30864003)(6506007)(41300700001)(31696002)(478600001)(31686004)(6486002)(86362001)(2616005)(66899024)(36756003)(43740500002)(45980500001);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?blJBejNsOTNvK01FckVCcXdOcENMSEdsR0R5YjRHWlJneFhQS044OUh3Q0F4?= =?utf-8?B?Vmp3MlgzMlNINDVsS2dzOWtTRXJUTU5zVUNmWnFsYlBhWlp1Z3h2YXd5WlZh?= =?utf-8?B?b0lIeGh6ZGJCRjVBRklsZElSUklxc2phNWlqYmRIY1FrVjlrcTZlV3BQdEx5?= =?utf-8?B?TnlQYWdZOWtpejNMMWIyNmxPV256QlpSaUdqYzQ4L1QxdE51TFdrdW1kamdC?= =?utf-8?B?V3l0S0t4RFZ1dTNsUDFQQmNZeDVsS2RLdW5FUU10V2c2dWtyUW1iV3lIdjdU?= =?utf-8?B?WHBUWmhwdXMrLzNzaGl0b3VSMW85ajN6MzZOS2tnNEVSSkJXME1nQXZvZnlL?= =?utf-8?B?VE00MlN4bjVGL2x2Z3RTa1ZzNFljMWE3R2hldlZlWUZnaU1FQjFZL2U2L1Jq?= =?utf-8?B?TkZxcW4ycWRHM1UzTWJHejR6cHdoa1ZCK0NaOHZsQ1RIK3NkQmNHWFRORXM1?= =?utf-8?B?eUJMdjRoaVpGeHJ4Q2FMenFjZmhtbU9rRDM2SXM3Z3FPUUxzbkxLKyt3NkVI?= =?utf-8?B?RXlMSEZnMDhrZGVuY0VUNjlUaE5teklGNWZ3dGJPNCt4dFBGU014NlN0c2ho?= =?utf-8?B?NDZ1WDF6MXVITzg5eHl0dkV0cW9ISUJVYVpIbFg2VkFISjA5MnlxMm5JM2dJ?= =?utf-8?B?eVk3TU9FZ2hDcSt6aWhSeUtjZTMxM3ZneG5uNldDOUJuRVRiNk9Vc3hqQW44?= =?utf-8?B?UE51bEh5OE4xOXF5MUlKa2ZIQW5HdmtqS2NyV2d6bTBhR04wSVRyZ1R3TGtK?= =?utf-8?B?SkdQTXZKRUxCQ3lmZnZmYjhmTFpyRjFNKzArejRXd3JHekpuZVdSZmF1OE91?= =?utf-8?B?RVY1aWNzdDN0czR5SFUvUUorYmRtTFh0UXN4Qm9yc2N2VUVXRStqR0xBT3BB?= =?utf-8?B?OVovRW53VHBUd3VrbEtiejBOcnBiVEJvU0hSN2MyM05DZnV3TFZncFFETDZV?= =?utf-8?B?Q0xlVzN1TTUveWNBZG52QlVTbndhbXlSLzVsY3B1TVgySm8ydTd0dmlGY3l6?= =?utf-8?B?aW42Mlo3cGJGVm1sRk1vQWZIajFQOW90N1hPK3ZhWmNnWG81WkZoNFdwcEpj?= =?utf-8?B?TWtkTzJFcmlRZlNkd0JZaVVSenNXNDZ1UGw4QlJrOWVNMXJJQ3pGbElESU1y?= =?utf-8?B?N0Ribi9sSGc1NzVjWjdOaFdOVnNnM2cxV3ZSLzVMUzdIaTVITGx2c0h4Q0c5?= =?utf-8?B?NkR1Yi84VlU1d0xScXUzNXQ1YVhaRndEaDhwUWpIdkQyemVEVmVZVWFHelVD?= =?utf-8?B?by9UU0xqQ0FocDM5Nnd6WXFSYjgyc3hGaWplNjFhOHFUeVJSRWprRklXdjRY?= =?utf-8?B?SDhaZmJUejdCVk1BcCt5S0dBNUtCN1ljc3FpRXRnd0tzLy90TForNzFCSjNG?= =?utf-8?B?WUVJejBSdWIxUWtjRXhOODNtc3NIcTg0Zi9QOUxMOExYSmVKZDlYUHBsWHJr?= =?utf-8?B?bENKR2VYNFdNYVlNTEQrVWJDRlBJdzc3c2RVdjNvRzlqK0h3b0dKT3o3VTR2?= =?utf-8?B?TFVuWnZna0FQYzRIc00xcW8wRkJNM0RaSzdIYk9vTGxacHpqK2o4L2JGQXlL?= =?utf-8?B?Znl0Mll2NGpLbGhKRXZCNk1la1grNzgvUEhCb2dCUzVFVFlKWm1vaURZU1Jk?= =?utf-8?B?TDBqQ2dmcllLMHAyelI1THdOalBxQ05ib3NaRUhkNFZ2V0JJQ2RzcFQvcklW?= =?utf-8?B?VE93QU5BTno0YTFIcVo0VXZJZURScytnNnYyMFA1WjBQc3RwYlhBWlRGM252?= =?utf-8?B?REtDbU8zeitxUDdDMUl5UERxTjQxZDMrZHAvcHh6NG14QjhFbVZNbGFvaUR5?= =?utf-8?B?WTZqYXYwcVdoQ3BicnoyalBLWWhuNkQrYTVZTFJscnI2bmxoV2hrRENoYndk?= =?utf-8?B?T2FwbHhIbkFaalpoc29ub0tHOVRCQmRCWHBrR3FsV1g3QjM1TG9jWkRUOGxt?= =?utf-8?B?UFlYeEFtZWQvRk1BNjFsTnhIeGRtZjhXbWxJb294aTFUdE1YUUZWZC81NDBI?= =?utf-8?B?QjgyeXRraFFEUUZocHhOSjd4c0FDZGk2T2srUHdlM1RZbXErUmt3dDhhWDVw?= =?utf-8?B?VGE4Q2wwWDM2YkdXRWJZUzFnUUxhR0puZUNwcnd3RTRzNG54M2libGdmWENr?= =?utf-8?B?L1hNYzZGOVpoOHRlT2xDbVJyQW11TU9qUXFYY2ZMa25HdllnWUpaRFY4YTZq?= =?utf-8?Q?eyue96kwfmPEdjmTbVWSYws=3D?= X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: Bpy2miETxCx+r3c/8eVOCW5nFasgbiPrAPow32WzcDhGPySJA5Je6IzlxxQENhYhUYhmcDwVrWRyBf2oolkNWbWh5oFP0mgLkJKxLOqgA6mp0i2jzJdUdKkPXiQcVTJGmhv/dyrFQt5zg8YLZ6StJYDqZLi8ap26kqK8P6PriNvVV+pkxoSnnfNeeSdip/SOjkMQoEAuXrreFOguE6EOWMZRgK5nIKCiwVY2gS+WEdtyfrUzUTWECBgctUurFGr8gQHlZ8R7+SOk7RcJ+ATnMUs17RWitIY9dv5fi7ig4AxNs8+/0RzQHvCuZUgRQfZDB4qu5eN+0tlr0Zt56jBvRH7euQcxd47klecxahRX+Kc1HujsEABItoCBmOSQMWZatHLJEKPrnyTLq4BPQ400d797/xXdXKOJ73XpfGe5T6uB7FmGKow42zbQNcT/XIWJJVsXQoIJ0pAtUltD7pU58S5KP7WMyjp3WyrGVKvvJwG4nA2z0LlB91barq+vpIoG/oK2USvtfPFc68Pl1pb4yuAYOb3plUYVAYxOMPz9nDSBkZbKZSTJSZ98ILSCYuixz0vy3vDf2rOxBpkK9somn57BHMpzS2FngljcziFPHF4= X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: 01eb2735-d0a8-43a4-b58e-08dc00612c8b X-MS-Exchange-CrossTenant-AuthSource: MWHPR1001MB2158.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Dec 2023 07:07:34.0625 (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: 1ywEcv/76rFa8ff6uVkHMzyZPs0auPNWk5Y05g5bo2BQAQ0ehG7mMOBU3kN0Woc5No1uwcwXdm7agLgwL2Ia9g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR10MB6672 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=2023-12-19_03,2023-12-14_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 mlxscore=0 spamscore=0 adultscore=0 phishscore=0 bulkscore=0 mlxlogscore=999 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2311290000 definitions=main-2312190051 X-Proofpoint-ORIG-GUID: 71ZrbkUdj4vCXtiLoFZYHbdLbhyXc3qY X-Proofpoint-GUID: 71ZrbkUdj4vCXtiLoFZYHbdLbhyXc3qY X-Spam-Status: No, score=-7.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,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 12/10/23 23:59, Jan Beulich wrote: > On 10.12.2023 11:22, Indu Bhagat wrote: >> On 11/2/23 04:39, Jan Beulich wrote: >>> On 02.11.2023 09:15, Indu Bhagat wrote: >>>> On 10/31/23 07:10, Jan Beulich wrote: >>>>> On 30.10.2023 17:51, Indu Bhagat wrote: >>>>>> gas/ >>>>>> * Makefile.am: Add new files. >>>>>> * Makefile.in: Regenerated. >>>>>> * as.c (defined): Handle documentation and listing option for >>>>>> ginsns and SCFI. >>>>>> * config/obj-elf.c (obj_elf_size): Invoke ginsn_data_end. >>>>>> (obj_elf_type): Invoke ginsn_data_begin. >>>>>> * config/tc-i386.c (ginsn_new): New functionality to generate >>>>>> ginsns. >>>>>> (x86_scfi_callee_saved_p): New function. >>>>>> (ginsn_dw2_regnum): Likewise. >>>>>> (ginsn_set_where): Likewise. >>>>>> (x86_ginsn_alu): Likewise. >>>>>> (x86_ginsn_move): Likewise. >>>>>> (x86_ginsn_lea): Likewise. >>>>>> (x86_ginsn_jump): Likewise. >>>>>> (x86_ginsn_jump_cond): Likewise. >>>>>> (md_assemble): Invoke ginsn_new. >>>>>> (s_insn): Likewise. >>>>>> (i386_target_format): Add hard error for usage of --scfi with non AMD64 ABIs. >>>>>> * config/tc-i386.h (TARGET_USE_GINSN): New definition. >>>>>> (TARGET_USE_SCFI): Likewise. >>>>>> (SCFI_NUM_REGS): Likewise. >>>>>> (REG_FP): Likewise. >>>>>> (REG_SP): Likewise. >>>>>> (SCFI_INIT_CFA_OFFSET): Likewise. >>>>>> (SCFI_CALLEE_SAVED_REG_P): Likewise. >>>>>> (x86_scfi_callee_saved_p): Likewise. >>>>> >>>>> For this arch-specific code there's a fundamental question of maintenance >>>>> cost here: It doesn't look very reasonable to me to demand of people adding >>>>> support for new ISA extensions to also take into consideration all of this >>>>> new machinery. Yet if any such addition affects SCFI, things will go out- >>>>> of-sync without updating this code as well. It may not be very often that >>>>> such updating is necessary, but right now there's APX work in progress >>>>> which I expect will need dealing with here as well. >>>>> >>>> >>>> I understand your concerns. FWIW, for SCFI, we will need to translate >>>> only a subset of instructions into ginsns (change of flow insns, >>>> save/restore and arith on REG_SP/REG_FP). >>> >>> Considering what you say further down regarding untraceability, I'm afraid >>> you will need to care about all insns which have SP/FP as their destination. >>> >> >> Yeah, All insns which have SP/FP as their destination must be seen by >> the SCFI machinery. If any instruction which has SP/FP as destination is >> missed, and the user has specified a --scfi command line argument, my >> thinking is that GAS should spit out an error or a diagnostic. >> >> That said, the current implementation handles the most commonly used >> instructions to manage stack pointer for dynamic and static stack >> allocation. For unhandled instructions which end up _possibly_ affecting >> REG_FP/REG_SP (I say _possibly_ because at this time I check both >> i.op[0].regs and i.op[1].regs for REG_SP/REG_FP), there is a warning: >> "Warning: SCFI: unhandled op 0x63 may cause incorrect CFI" > > Yet neither i.op[0] nor i.op[1] may represent the destination register of > an insn, when there are more than 2 operands. > I have now handled this case properly I think (will include this in V4). Thanks for your comment below. >>>>>> +static ginsnS * >>>>>> +x86_ginsn_alu (i386_insn insn, symbolS *insn_end_sym) >>>>>> +{ >>>>>> + offsetT src_imm; >>>>>> + uint32_t dw2_regnum; >>>>>> + enum ginsn_src_type src_type; >>>>>> + enum ginsn_dst_type dst_type; >>>>>> + ginsnS *ginsn = NULL; >>>>>> + >>>>>> + /* FIXME - create ginsn for REG_SP target only ? */ >>>>>> + /* Map for insn.tm.extension_opcode >>>>>> + 000 ADD 100 AND >>>>>> + 001 OR 101 SUB >>>>>> + 010 ADC 110 XOR >>>>>> + 011 SBB 111 CMP */ >>>>>> + >>>>>> + /* add/sub imm, %reg. >>>>>> + and imm, %reg only at this time for SCFI. */ >>>>>> + if (!(insn.tm.extension_opcode == 0 >>>>>> + || insn.tm.extension_opcode == 4 >>>>>> + || insn.tm.extension_opcode == 5)) >>>>>> + return ginsn; >>>>> >>>>> Why is AND permitted, but OR/XOR aren't? >>>>> >>>>> Also this is about ALU insns with immediate operands only, yet that >>>>> fact isn't reflected in the function name. >>>>> >>>> >>>> OR/XOR should be handled. I will fix this. >>>> >> >> Spoke too soon. I remembered later why OR/XOR is not handled but AND is >> (I have now added a code comment around this). >> >> An OR/XOR on REG_SP/REG_FP as destination makes the destination >> untraceable. So these operations are skipped here. At a later point >> (towards the end of x86_ginsn_new): the ginsn generation machinery will >> complain about these OR/XOR as "unhandled opcode for SCFI" and bail out >> if destination was REG_SP/REG_FP. >> >> On that note, AND operation also makes REG_SP/REG_FP untraceable, but >> they are being generated currently. This is because supporting DRAP >> pattern is something we plan to look into. Currently these are >> generated, but the SCFI machinery later bails out with a message "Error: >> SCFI: unsupported stack manipulation pattern" > > But why would you need special handling just to mark a register untraceable? > Generic code merely looking at the destination register ought to be enough? > Yes, now a ginsn on type GINSN_TYPE_OTHER with destination REG_SP/REG_FP as applicable is generated. The SCFI machinery then bails out if this ginsn makes REG_FP untraceable, when REG_FP based CFA tracking is active. If CFA tracking is _not_ REG_FP based, it is fine to manipulate REG_FP in a untraceable way. >>>>>> +static ginsnS * >>>>>> +x86_ginsn_lea (i386_insn insn, symbolS *insn_end_sym) >>>>>> +{ >>>>>> + offsetT src_disp = 0; >>>>>> + ginsnS *ginsn = NULL; >>>>>> + uint32_t base_reg; >>>>>> + uint32_t index_reg; >>>>>> + offsetT index_scale; >>>>>> + uint32_t dst_reg; >>>>>> + >>>>>> + if (!insn.index_reg && !insn.base_reg) >>>>>> + { >>>>>> + /* lea symbol, %rN. */ >>>>>> + dst_reg = ginsn_dw2_regnum (insn.op[1].regs); >>>>>> + /* FIXME - Skip encoding information about the symbol. >>>>>> + This is TBD_GINSN_INFO_LOSS, but it is fine if the mode is >>>>>> + GINSN_GEN_SCFI. */ >>>>>> + ginsn = ginsn_new_mov (insn_end_sym, false, >>>>>> + GINSN_SRC_IMM, 0xf /* arbitrary const. */, 0, >>>>>> + GINSN_DST_REG, dst_reg, 0); >>>>>> + } >>>>>> + else if (insn.base_reg && !insn.index_reg) >>>>>> + { >>>>>> + /* lea -0x2(%base),%dst. */ >>>>>> + base_reg = ginsn_dw2_regnum (insn.base_reg); >>>>>> + dst_reg = ginsn_dw2_regnum (insn.op[1].regs); >>>>>> + >>>>>> + if (insn.disp_operands) >>>>>> + src_disp = insn.op[0].disps->X_add_number; >>>>> >>>>> What if the displacement expression is other than O_constant? >>>>> >>>> >>>> For SCFI, a "complex" lea instruction will imply some untraceable change >>>> to the destination reg. For SCFI, the extent of untraceable change is >>>> not of interest, hence, in general, some information loss in ginsn is >>>> tolerable. >>> >>> As a fundamental request: For anything that's of no interest, can you >>> please try to cover this with as little (and thus clear) code as possible? >>> No taking apart of sub-cases when those are indifferent in the end anyway. >>> >> >> In general, this is something I have battled with on and off. In the end >> I chose the principle "Encode as precise ginsn as possible given its >> current representation". I have tried to follow this mostly >> (x86_ginsn_lea is the known outlier). For all cases known to be >> imprecise, it is my intention to have them marked with >> TBD_GINSN_INFO_LOSS etc. And to not have too many of those.. >> >> If I leave out more sub-cases (elsewhere) because they are indifferent >> in the end for SCFI at this time, two problems: >> - More of the currently generated ginsn will look imprecise. >> - More code will need to be revisited when there is other ginsn >> generation modes to be supported. > > I can see your view. Still there's the other view of code not really > being needed right now potentially also net being in the exact shape it > may be needed down the road, at which point it would similarly need > touching again. > >>>>>> +{ >>>>>> + uint16_t opcode; >>>>>> + uint32_t dw2_regnum; >>>>>> + uint32_t src2_dw2_regnum; >>>>>> + int32_t gdisp = 0; >>>>>> + ginsnS *ginsn = NULL; >>>>>> + ginsnS *ginsn_next = NULL; >>>>>> + ginsnS *ginsn_last = NULL; >>>>>> + >>>>>> + /* FIXME - Need a way to check whether the decoding is sane. The specific >>>>>> + checks around i.tm.opcode_space were added as issues were seen. Likely >>>>>> + insufficient. */ >>>>> >>>>> Furthermore opcode encoding space (SPACE_...) need to be taken into >>>>> account in all cases. >>>>> >>>>>> + /* Currently supports generation of selected ginsns, sufficient for >>>>>> + the use-case of SCFI only. To remove this condition will require >>>>>> + work on this target-specific process of creation of ginsns. Some >>>>>> + of such places are tagged with TBD_GINSN_GEN_NOT_SCFI to serve as >>>>>> + examples. */ >>>>>> + if (gmode != GINSN_GEN_SCFI) >>>>>> + return ginsn; >>>>>> + >>>>>> + opcode = i.tm.base_opcode; >>>>>> + >>>>>> + switch (opcode) >>>>>> + { >>>>>> + case 0x1: >>>>>> + /* add reg, reg. */ >>>>>> + dw2_regnum = ginsn_dw2_regnum (i.op[0].regs); >>>>> >>>>> You don't care about opcode 0 (byte operation). Then what about 16-bit >>>>> operand size? Or, since we're talking of a 64-bit-ABI-only feature, >>>>> even 32-bit operand size? >>>>> >>>> >>>> Operand size in some cases does not affect SCFI. So we dont keep >>>> information about operand sizes. The case that I should handle operand >>>> size is when they are pushed to / popped from stack. >>> >>> So you care about recognizing when %rbp is overwritten by an insn. And >>> you also care about the same for %ebp and %bp. In that sense operand >>> size may indeed be unnecessary to determine. Except that then you also >>> want to deal with byte operations, i.e. %bpl being the destination. >>> >> >> I have adjusted the ginsn_dw2_regnum to handle correctly 8-bit register >> usages so that any writes to REG_SP/REG_FP are detected. I also added a >> new test "ginsn-dw2-regnum" to exercise this API. >> >>>>> Also what about opcode 0x3? >>>> >>>> LSL instruction ? It doesnt look like it can affect DWARF CFI of a >>>> function. Please correct me if this is wrong. >>> >>> LSL is 0f03, i.e. opcode 0x3 in SPACE_0F. What my comment was about is >>> ADD with inversed operands (ModRM.rm soure, ModRM.reg destination). All >>> four of these flavors of ADD are covered by a single template, using the >>> D and W attributes to establish opcode bits 0 and 1 based on actual >>> operands (and possibly pseudo-prefixes). >>> >> >> I added handling for 0x3 ADD. >> >> Can you elaborate on the "using the D and W attributes to establish >> opcode bits 0 and 1 based on actual operands (and possibly >> pseudo-prefixes)." a bit ? > > Well, reg <-> reg/mem ADDs (taking the specific example) come in two > forms: ModR/M.reg reprsenting the source and the same representing the > destination. They're represented by a single opcode template, with D > indicating that both directions can be used. > > Similarly there are multiple operand sizes supported by several such > templates, with W indicating that both byte nad word/dword/qword > operation is possible to encode by OR-ing in a single opcode bit. > > For your purposes, W is likely of no direct interest. D may be, yet > then I take it that you work on actual operands, not on what templates > permit. In actual operands, destination (due to following to AT&T > syntax layout in the internal representation) is last at all stages of > assembly (for Intel syntax input after swapping operands, of course). > Thanks. We will now take the last reg operand, i.op[i.operands - 1].regs (after checks on i.operands and i.reg_operands) as destination and if the register is REG_SP/REG_FP, we generate GINSN_TYPE_OTHER with the appropriate destination register. I will include this change in a V4 posting. >>>>>> + dw2_regnum = ginsn_dw2_regnum (i.op[0].regs); >>>>>> + /* push fs / push gs. */ >>>>>> + ginsn = ginsn_new_sub (insn_end_sym, false, >>>>>> + GINSN_SRC_REG, REG_SP, 0, >>>>>> + GINSN_SRC_IMM, 0, 8, >>>>> >>>>> Note how the 8 here assumes flag_code == CODE_64BIT. (You further assume >>>>> no operand size override here.) >>>>> >>>> >>>> Hmm. Yes, I do assume no operand size override here. I will need to >>>> understand how to calculate the operand size here. Looks like I need to >>>> check for instruction prefixes 66H or REX.W. Is there an API in the >>>> backend that be used for this ? >>> >>> i.prefixes[] and (depending on the phase of assembly) i.rex should be >>> telling you. >>> >> >> I have added checks for prefix 66H to detect 16-bit ops now. IIUC, I >> dont need to detect REX.W prefix specifically. > > I'm not sure. REX.W clear likely means the destination becomes untraceable? > Whereas REX.W set means to full register is updated (upper half not zeroed) > and hence it may remain traceable? I see that Push, Pop instructions do not need the REX prefix. Hence, checking for 66H to detect 16-bit operand size suffices. Default operand size is 64-bit in 64-bit mode.