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 4F0C13858D28 for ; Fri, 3 Nov 2023 05:45:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4F0C13858D28 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 4F0C13858D28 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=1698990352; cv=pass; b=sTnCnKzfZPTudEl2KBxvkLTyfMPnCWglcRol4VKgojN/BdRQ3qPkPrnxsieXNuFIQKEX8SAfAvGN60oD8TfA21GAj9rBMpM1uN3PW/tWxeWEBiV8yNvwlv1g/049kLBLBFZJ2ER0Mt8ebFAzqEVSqtgcHgQBHw9u7m7rpe6MnYQ= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1698990352; c=relaxed/simple; bh=0ueVEDmqL2K28tkOLtSM9bs0ErWs+UjeiArAqRgPNck=; h=DKIM-Signature:DKIM-Signature:Message-ID:Date:From:Subject:To: MIME-Version; b=uZm5kc0ch8fveb+5qDLlRW9jEaUhAnOZJlQ0E7MwPc/5AxNpSlMQ8IB91yzFL+/jejbBgUUpNiJT3AoSR2hpZorOlvqk0xfnGEnd71nrlKlNBJe6d9Hfkjw4YplrOewn8pjUDvLpaZFmBJCfZtoume5xT7Ei1fr4/6jLclYY5Bw= ARC-Authentication-Results: i=2; server2.sourceware.org Received: from pps.filterd (m0246631.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 3A2NOEwq030947; Fri, 3 Nov 2023 05:45:41 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=message-id : date : from : subject : to : cc : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=corp-2023-03-30; bh=i8LCfcg9HoHi8Tc7RbS7WDNZNrrk3CRHFA36zwe0OlA=; b=GQVA0QsoEUaciI3fWTqjWv0vsVDi0NumTYdRJn+qFfeU3OzH1uZiFo1n+wlmpXZeRrfe OaRA9AaYxyi/JFipkVkSnCR7jR3ydkWdp5J+lnVgOl51y9MFR4hEPwom7zQ0pghc6zrM /c+zIkuJb8c8I9TEGdj0PPqLyBfZthpyUZPRbm2SGjznP1UfJNl+N7OjDkUbkE7xCx/9 d0pbVwOu9WZjufyyWhddxEbLoStmr2r0DUBudFVmLfTlQNfU5gJXZVEQaLApTvyDOCqK VuwMfi+aLe0PoFMNXOhv6n5IUCU6H3/wHialH7xtOLNr3Ujdl8pvFOoJUMita0JoVfQr 2A== Received: from iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta02.appoci.oracle.com [147.154.18.20]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 3u0s343e15-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 03 Nov 2023 05:45:41 +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 3A33dbKc022484; Fri, 3 Nov 2023 05:45:40 GMT Received: from nam04-dm6-obe.outbound.protection.outlook.com (mail-dm6nam04lp2040.outbound.protection.outlook.com [104.47.73.40]) by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id 3u0rr9muxn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 03 Nov 2023 05:45:40 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FlrQjtUQ8ykRA522qKTRn0pTMsFGMnmdPb3YdvgGktdQniQBw/A2R/QT1ezV4ORQwntKxxC0aTtsjGxeZ9qN3ZGl0bPr9JGG4baFXTo6okyX2MfY6A5ckBgP10yCLy73ybEJgFpMBP9BroIT5pgOkkh7B9+RIWHLHz72XcKc8iXa/PChfKYD9BL48NlQlJQ8uU1O6Jb8YnYlJm/y3534d2QMugqe7PZWTginoimQjg3Ap6ecW1LwUOrAgnt/hYwKkLKGvO90QJJqucoyT7Rzrvx2n9PWdGJA4fTTaDV8+b1lM64o53WqL+FrETSpdgAMSXCnM7gzY8jMMY5aTeQ3Kg== 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=i8LCfcg9HoHi8Tc7RbS7WDNZNrrk3CRHFA36zwe0OlA=; b=hAU+v9vr0RyWGz+YqvTBZRsAuStuJiNDHoFnSGdDOH/L7nTaP5xIk1Mkil5NIIqTTwCDu82PpA1dM9HFsKBppngvK7+bXf7uZjLagJQdw/82bMGjCAjKhj60F3D/1XfCQdR697w8zk+q++vAZEoYCM04KJq3UHYaPfRLAqJjP3XNAufj8rq3JGUALjXr3JWIRTY148qt2bHCE3SoDgRNIvpCAlKQ0u2ChqeNRTt/BZQy4uQL0lzvlxAaVUc8+TO/jmbxPMJ44qoekr1kQQlydkRxTtDN3zRjUfIcbt+25UNgpPCRbLnNKe7eRUDwDjLjEFZzDP1Cjrv2rjUrqwXhFA== 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=i8LCfcg9HoHi8Tc7RbS7WDNZNrrk3CRHFA36zwe0OlA=; b=SIzDD6v1ipqcAZKp3+F8WGhVMjCs/L7mXOUi3SU61MV32B3oqVHPzXf+TpWE23nUJjt+SqFRFa6Q5wvbaBknqw+fHLjmcDd0Ly2SmbgFSdMWiSKX1b3L5+M/u616rYmlwr10Pq6oaqSCuFGtYUevqIr7IcMr4Fvn0KwaI/Qevjw= Received: from MWHPR1001MB2158.namprd10.prod.outlook.com (2603:10b6:301:2d::17) by DM4PR10MB5941.namprd10.prod.outlook.com (2603:10b6:8:ab::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6954.21; Fri, 3 Nov 2023 05:45:38 +0000 Received: from MWHPR1001MB2158.namprd10.prod.outlook.com ([fe80::40e0:a5cb:e318:c51f]) by MWHPR1001MB2158.namprd10.prod.outlook.com ([fe80::40e0:a5cb:e318:c51f%6]) with mapi id 15.20.6954.021; Fri, 3 Nov 2023 05:45:38 +0000 Message-ID: <66f17782-5cf3-4aed-b1ec-1f8a7dea202c@oracle.com> Date: Thu, 2 Nov 2023 22:45:36 -0700 User-Agent: Mozilla Thunderbird From: Indu Bhagat Subject: Re: [PATCH, V2 09/10] gas: testsuite: add a x86_64 testsuite for SCFI To: Jan Beulich Cc: binutils@sourceware.org References: <20231030165137.2570939-1-indu.bhagat@oracle.com> <20231030165137.2570939-10-indu.bhagat@oracle.com> <33168ad4-97c6-6028-7055-2f21434ccfd1@suse.com> <13294625-0ab1-dfa6-08dd-d5c1ec541ec7@suse.com> Content-Language: en-US In-Reply-To: <13294625-0ab1-dfa6-08dd-d5c1ec541ec7@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: MW4PR04CA0184.namprd04.prod.outlook.com (2603:10b6:303:86::9) To MWHPR1001MB2158.namprd10.prod.outlook.com (2603:10b6:301:2d::17) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MWHPR1001MB2158:EE_|DM4PR10MB5941:EE_ X-MS-Office365-Filtering-Correlation-Id: 1d61969b-5927-4393-782d-08dbdc301b61 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: TQq8Px6OYg45f2HpIph74smrk6Xba31TziWpELVcEYeXgiztHRXMor8H+E0P5slXm59nn5PgFF6aWzMica5OOLVhwu1HZYvaRC/2YstDlVSMb19//TrFQR/B38I0hI74fiFYJSOaZ91PWAhKidFfqo/sbsdw8AUET5aNwQswjVnAYaSHg30hbvqu5UawQ2UKr1Y7J7js9UtbdqQ8IrsOR768U9UOe5PYUtqBU/mGIhbtBaV3c1olI6Tfadj0N3UHLVYXh1rcELEZkc36k8uLnZj5shd/xpcmWnQ8PPdApjogpOzMjVW/IvC+Lh3d1k0qskd9bbWW/trVX7zv+XNI5VAth7/yE1zCiyCaozHdmUADQkeTAimuvRl3du/RVSb7KRarhUhzHEurWJSPuAkYHNAT0oH8ulk8JsfSfSCp0j+HzrM6f+LYsCBWfhWO2r4vd2if6iCWCWu51K+0+oySCR3sufuhClDUhorwupPsG8dZ0hOkibY8I6oQ2s+RvO3l0Ln/upygm8pkrbNxsN7XIDz44+Pn8cgS1eqe62sFwH+NAjPZ9TAFd94yEUIisk7QQhVMFqz8S0zdwiZu5m1L6u+iVGx8CHJgt3q+LcqXTP2iW5/Ae8za2fadev4yX0umbBw8M9Z/Dr/+EIF8Rx7mzviuNYLtNiBrLgYLkCL+q2+cElq9DxdGF9Ya2tG6gio9ba9sW/tTMsTiJQFJ7Zcq3Q== 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)(346002)(366004)(376002)(39860400002)(136003)(396003)(230273577357003)(230173577357003)(230922051799003)(1800799009)(64100799003)(186009)(451199024)(2616005)(6512007)(478600001)(6506007)(53546011)(83380400001)(2906002)(5660300002)(30864003)(44832011)(41300700001)(6486002)(66946007)(66556008)(4326008)(8936002)(6916009)(8676002)(316002)(66476007)(38100700002)(86362001)(31696002)(36756003)(31686004)(2004002)(45980500001)(43740500002);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?QkpRQjNYZXFhQkJtT3o1elRhUWQ3WDV2aDJBTGVhYVRxSXdsTW1DdktrUXZ6?= =?utf-8?B?RWJ5VnE2d3AyaEx1dWlTdzZvdVBTeXhUZWhVSWZHVnBWMXIvUzRIYnM4WW5q?= =?utf-8?B?NzMwcm5zMWJxdkU5K1FVSjl6YmFjRFlxZlltdlB4Nkk4R2UwMmtVdzVaVm01?= =?utf-8?B?eWVuNUtrUkMvbHFjbEJuVW1kU2RTaGxlRVRlTFA2cnF4ZENpVHpJNkZERFlE?= =?utf-8?B?bWprZkdLczVIaEh2MmpITy9LSVRBTDBSY3R0cmZBenZxWnZwNHBXU3k5M2g1?= =?utf-8?B?V3ZNQmhqWlUybFBlWW5ZK2Z4Z01MVkVCQXJCeUtZcEFITG5KTVFDandHOE8z?= =?utf-8?B?ZlhmS2g1NjVCbnN6aGsrN25RY1ZFQ05SUEl6VFRyM3JvV01hakEyTFpUN2tV?= =?utf-8?B?QkFJREtoRWJQNHlnRFlFTEE2ZmdVK1NRdXZUTlYwVzJkWFI1V2g0ZHZaNXNv?= =?utf-8?B?MS9hUlhKRXE4SGc2RC9DaEpaYldBbDJsdHZBRk56NzVnSlVLQlRDWWI0WnpG?= =?utf-8?B?YlN3aEM0NkVlc2s5SHZEZUJXM3daS2l2R2VrOHA5SWtvbDhLenUydFFUOG41?= =?utf-8?B?V0VuUWxCbFpFc3Q0WHU5azFMaFNjMUtEVXhlNHc2aFhSZ0dwRDlQSGxQbHUw?= =?utf-8?B?bS9ScXBQdFhjdEYwOHpaRVllamxKUXVvMzFYcVM5MTczOUFCWFEzNDZNRUxj?= =?utf-8?B?dUFBYTVYRWd6all4ajFvU29sVjJJb0gyTStEWG5Yb3BRb3I5aFcyZ1RxYk91?= =?utf-8?B?VEd4Szh6cThUaEZGTW9pWTcxTEZxOGpVT3JERExVUTZuNmZMZGRBcy9tK2pv?= =?utf-8?B?SFl6VmJsd1E3THV0dnFyaFkzcThlNHUwMnVZbWdNMnF5eG91NU54NVQ5eDlo?= =?utf-8?B?ZjkzK3ZMVWpUL0UwZHF4Z2RLWHlwOFNKeDRJdGxqUW1Bdm1oY2JaaU1lVS93?= =?utf-8?B?VXBJWC9TQ0ZESmlYNFJ3MXdBK0g2NUdHZnV6YkdkZkYrdCt2M21hK0xlSVZ0?= =?utf-8?B?RlJuTUJBOVZXMDhwKzVYQVJPWGNEajNaMzlVTTNCSmxBOVRVVTlHU2N2V0Ew?= =?utf-8?B?WWp0bUEyMTlkejlSeWhIaWVWSzFoSnM2VW1ycHVxeGRZVG53Z25icm82Rytu?= =?utf-8?B?d1M3bDhhN1BDZDFWME9aSU1Rck9wUGhOL2Z4L2lSa3pSdnc2UDlSbTJydFFv?= =?utf-8?B?Y3ZiRTRra3ZWTDI5dTNnbnZkWFhkYjhKV0lSTXkrMWhxeHFSc1AwN3NVaFFm?= =?utf-8?B?ZnlqZ21BRmlOeHM0VXBRWGptMVNDY1BJTGFxUExGZGNuMVJ1aklsNGxrZHpl?= =?utf-8?B?OFZHclBVVUVRNVN1anF3SW53SWJiT1BTT2FlMk8zaE1yRklrZmx3cUdDSVl5?= =?utf-8?B?V2JuZVExT1I5S01ZMEFyNmk4S3JqSTY1NUhzTW1IUDN4WkxDRVg3Smd5bVl0?= =?utf-8?B?SUNobjZvVmJuRUVSZ3QwWllqRU9qOHlJekF2dlRPa2ZuTllXMTV6Z2drMmNr?= =?utf-8?B?Vll3VHo2RUhxU0hJRGNPNUlueW91NmFjanNXWHF1QWhCU1U1Q1FCWnBxQnJu?= =?utf-8?B?b2pVNG1nc1JrM3BoUG5KRjM4SVNYaWJtbENVczhGY2tCaWVZSXIrRy9CUUsx?= =?utf-8?B?bkdGTkpZc3p2aXRoWm9ZNmQrRmliZEFqVWVJMEs3UDVBaFBDbkQ4QysvTUlr?= =?utf-8?B?VXMrYitoUGlzdEVBVWdxQkdYSUZBUHN6alhzY0dhcTFDbnRiVWhGWEo1YnhW?= =?utf-8?B?N0NGcGgwRVBpaDQvWkxBREdMSTBPUkdBMU5qNEI1NjFBUmM3d0Q1OC9Ydk5X?= =?utf-8?B?TUZ4NDI3T0o3emJVZGxDY2ErZk4xeG5Ca1BHMVZ0bWgvSEY1cjJSRC9Jd2NJ?= =?utf-8?B?TWlsWUg1VFM0Nk53UStsTjZhemhJdkVGSHJWNjNmVFpORHA2VUNLMTRITjdw?= =?utf-8?B?SnRLM0lSQk0rN0I3V1REUE5yOC9lRUwxeGNaR1IrL1dIZjM5QVM5RWNvUDRT?= =?utf-8?B?cy9USXBiUTlOVHdMZ0I0eXJoV2JRODNQZmVsNFdWUlE3YlBDelh5N0oyMDBr?= =?utf-8?B?dG1LbHhIWDBINFlkM3RSZU55eW5GRHJmeXlXNHZybHhPQVYrUEV0ekQvRjhF?= =?utf-8?B?Z2FRWFl5WGlhTk9TZzM0emZBZWpNZkxZZUlaakJrSEhNMnJ1anh3Q1dXNito?= =?utf-8?Q?CIY7dbkjCZMGlhxl+f2SXAY=3D?= X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: NAU8U6XVpq7vw6iYNpxgghtbMkQ+5fV/hQKsVGn8nPVdZo3yKtJHOadgYecJtlb1FIAEJDOIlHsThWF4Fu3G8LNemxOnNW9M+Or8qSOzLPb0E2YFCyscPrxKXBA9cuerzvv5VWsnGbWojFHv5YVswT54qnN+OFRkm82/cNysHcvK0eBJWfktsDtdaKNSZyGLsZaZpSkPY3+ApyzSLEEbNLs784dasH7w+i8ElDJQFUAl+5wmhreHmphuVw0kHMUOMzQczTHjut4X/tFqPiuSZO4P+0IEbMQEWkzh8AzyTJuYTnJ5uKiDrF+k7O8WITYkeCZO8Ek7elDPY2B0g+rB7LWf7xnmbOAEb3zsb5R5CELWMvpqCGFauABljrpU17U0EKALjENOneSpl2cHlXkvkgnIJ+aZ1TmWzH7yX+/z3KH6IP1hPp6kR6boRrAFOVMGI9pca5c6TKw9PD/YWItYo+NcZwijCzG/krXUx5XJiolOqwKzSc0RH0BEHHZti7c7K84pKNapxVXw2BbYi6SPsJdBV/yYfiqAA7xZfeNCTbXkB3f2BFAZrUNZO+8ntgQF6elS2hCnFASprmSHOv8aEcNB3pqaUEthCPjkcE50m4xczjaqdaIs239SmecCttB72Fb4rx1smuPpa4ePYTcDxaMO4+uS2RgmNvKg/C7rVr9RPYtLHj7dzci3TCmpz6WCV+smPzFrC68JXMpQoAiSmQlr1BybkOIr2y8kJG4ApMtgBV1lF7XjF8/RYSxoQJTl6Wqy2t3dnSuQHTP2skobmXfvOdZJk6YhfrdyBee6rGc= X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1d61969b-5927-4393-782d-08dbdc301b61 X-MS-Exchange-CrossTenant-AuthSource: MWHPR1001MB2158.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Nov 2023 05:45:38.0074 (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: gpv1pMXcJzBgGZgnKy3UUUNk9SRsN0dSODrLoN48H1LF6UfQsKatpfjuGXjUyyYx88uor2SUyU+q1zbRa8p44Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR10MB5941 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.987,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2023-11-03_05,2023-11-02_03,2023-05-22_02 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 mlxscore=0 mlxlogscore=999 adultscore=0 phishscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2310240000 definitions=main-2311030046 X-Proofpoint-GUID: _RUPK0CJKxgcqGK0arhMU3t2X3SY4wa3 X-Proofpoint-ORIG-GUID: _RUPK0CJKxgcqGK0arhMU3t2X3SY4wa3 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 11/2/23 05:28, Jan Beulich wrote: > On 01.11.2023 07:24, Indu Bhagat wrote: >> On 10/31/23 09:13, Jan Beulich wrote: >>> On 30.10.2023 17:51, Indu Bhagat wrote: >>>> --- /dev/null >>>> +++ b/gas/testsuite/gas/scfi/x86_64/scfi-add-2.s >>>> @@ -0,0 +1,48 @@ >>>> + .section .rodata >>>> + .type simd_cmp_op, @object >>>> + .size simd_cmp_op, 8 >>>> +simd_cmp_op: >>>> + .long 2 >>>> + .zero 4 >>>> + >>>> +# Testcase for add instruction. >>>> +# add reg, reg instruction >>>> + .text >>>> + .globl foo >>>> + .type foo, @function >>>> +foo: >>>> + .cfi_startproc >>>> + pushq %rbp >>>> + .cfi_def_cfa_offset 16 >>>> + .cfi_offset 6, -16 >>>> + movq %rsp, %rbp >>>> + .cfi_def_cfa_register 6 >>>> + pushq %r12 >>>> + .cfi_offset 12, -24 >>>> + mov %rsp, %r12 >>> >>> You copy %rsp to %r12 here, and ... >>> >>>> +# Stack manipulation is permitted if the base register for >>>> +# tracking CFA has been changed to FP. >>>> + addq %rdx, %rsp >>>> + addq %rsp, %rax >>>> +# Some add instructions may access the stack indirectly. Such >>>> +# accesses do not make REG_FP untraceable. >>>> + addl %eax, -84(%rbp) >>>> +# Other kind of add instructions should not error out in the >>>> +# x86_64 -> ginsn translator >>>> + addq $simd_cmp_op+8, %rdx >>>> + addl %edx, -32(%rsp) >>>> + addl $1, fb_low_counter(,%rbx,4) >>>> + mov %r12, %rsp >>> >>> ... you restore it here, but both without any .cfi_* annotation. >>> It is therefore unclear whether this is in any way related to ... >>> >> >> There are no .cfi_* annotations for the %rsp updates here because the >> CFA tracking has already been switched to REG_FP based tracking. From >> the perspective of DWARF CFI, this usages of the stack do not need to >> tracked. If unwinding happens from any instruction in the above >> sequence, we already have the correct and complete unwind information. >> >>>> +# Popping a callee-saved register. >>>> +# RSP must be traceable. >>>> + pop %r12 >>>> + .cfi_restore 12 >>> >>> ... what the comment says about these. >>> >> >> The comment here means that hand-written programs may use stack for >> their local usage etc. but must ensure that before or in the epilogue, >> rsp is restored to the desired value (before register restores via pop >> instructions). > > And how exactly do you tell that the "mov %r12, %rsp" is a restore, not > the setting of an arbitrary new %rsp value? > It checks that there must have been a "mov %rsp, %r12" seen earlier. The SCFI machinery caches such a save of stack pointer state. >> This is not a special handling in the SCFI machinery but it is what is >> needed to ensure correctness of the function. For asm not adhering to >> the ABI/calling conventions, SCFI cannot be used. > > But the calling convention doesn't go as far as dictating local frame > layout in a function, I don't think? > No you are right on that one. In this example, we only concern ourselves only with the callee-saved registers and their save/restores; the components that affect the CFI annotations. The local stack usage is not of interest per se; the program is allowed to allocate and use as it pleases. >>>> + leave >>>> + .cfi_def_cfa_register 7 >>>> + .cfi_restore 6 >>> >>> Using numbers here isn't very helpful, I'm afraid. >>> >> >> I am not sure I understand. The DWARF register numbers and the offset >> values are required by the semantics of those CFI directives. > > Offsets are (largely) unavoidable to be numerics, yes. But .cfi_* > directives support register names, and using them is (imo) far better > than Dwarf register numbers - you may have memorized them by now, but > others likely won't. > Ah ok. Yeah I can use register numbers. >>>> --- /dev/null >>>> +++ b/gas/testsuite/gas/scfi/x86_64/scfi-asm-marker-3.l >>>> @@ -0,0 +1,2 @@ >>>> +.*Assembler messages: >>>> +.*9: Warning: --scfi=all ignores some user-specified CFI directives >>> >>> Is repeating this for (about?) every test really necessary / useful? >>> If multiple passes for every test were to make sense to me, I'd expect >>> one pass with SCFI and one pass without, where the directives then >>> take effect. And then the same set of expectations should match. >>> >> >> re: is repeating this useful? Strictly speaking no. _But_, I think as >> the code evolves, we may add more diagnostics to the SCFI machinery. >> Explicitly checking for the set of warnings helps us ensure no new >> warnings show up where they are not expected. In a way, it is a stricter >> check and ensures no unintented slippage. > > Well, okay, that's fair. You didn't respond to the other part of my > comment, though. > Sorry I missed that. Yes, we could do two runs for the meaningful tests, one with --scfi and another without. That should be useful. I recall there was only one case (dont recollect which one) where the generated FDEs were reversed in order with --scfi, but it was not a functional difference. Other than that test, rest all should match. >>>> --- /dev/null >>>> +++ b/gas/testsuite/gas/scfi/x86_64/scfi-bp-sp-2.s >>>> @@ -0,0 +1,49 @@ >>>> +# Testcase for switching between sp/fp based CFA. >>>> + .text >>>> + .globl foo >>>> + .type foo, @function >>>> +foo: >>>> + .cfi_startproc >>>> + pushq %r14 >>>> + .cfi_def_cfa_offset 16 >>>> + .cfi_offset 14, -16 >>>> + pushq %r13 >>>> + .cfi_def_cfa_offset 24 >>>> + .cfi_offset 13, -24 >>>> + pushq %r12 >>>> + .cfi_def_cfa_offset 32 >>>> + .cfi_offset 12, -32 >>>> + pushq %rbp >>>> + .cfi_def_cfa_offset 40 >>>> + .cfi_offset 6, -40 >>>> + pushq %rbx >>>> + .cfi_def_cfa_offset 48 >>>> + .cfi_offset 3, -48 >>>> + movq %rdi, %rbx >>>> + subq $32, %rsp >>>> + .cfi_def_cfa_offset 80 >>>> +# This mov does not switch CFA tracking to REG_FP, because there has already >>>> +# been stack usage between here and the push %rbp >>>> + movq %rsp, %rbp >>> >>> Yet another constraint? >>> >> >> Not sure I understand. This is not a constraint for SCFI. A pattern >> where the user does: >> push %rbp >> .. more stack usage.. >> movq %rsp, %rbp >> is not using frame pointer for stack tracing, but simply as a scratch >> register. > > Why might it not be? We're talking about hand-written assembly, and > assembly writers are free to e.g. first push all (necessary) callee- > saved register and then copy %rsp into %rbp. For a function with many > stack locals this has the benefit of allowing more of them to be > accessed via (%rbp). > You are right on this one. It should be allowed. The mov %rsp, %rbp should switch to REG_FP based CFA in this example. I will fix it. >>>> --- /dev/null >>>> +++ b/gas/testsuite/gas/scfi/x86_64/scfi-cfg-1.d >>>> @@ -0,0 +1,36 @@ >>>> +#as: --scfi -W >>>> +#objdump: -Wf >>>> +#name: Synthesize CFI in presence of control flow 1 >>>> +#... >>>> +Contents of the .eh_frame section: >>>> + >>>> +00000000 0+0014 0+0000 CIE >>>> + Version: 1 >>>> + Augmentation: "zR" >>>> + Code alignment factor: 1 >>>> + Data alignment factor: -8 >>>> + Return address column: 16 >>>> + Augmentation data: [01][abc] >>>> + DW_CFA_def_cfa: r7 \(rsp\) ofs 8 >>>> + DW_CFA_offset: r16 \(rip\) at cfa-8 >>>> + DW_CFA_nop >>>> + DW_CFA_nop >>>> + >>>> +0+0018 0+0024 0000001c FDE cie=00000000 pc=0+0000..0+003a >>>> + DW_CFA_advance_loc: 1 to 0+0001 >>>> + DW_CFA_def_cfa_offset: 16 >>>> + DW_CFA_offset: r3 \(rbx\) at cfa-16 >>>> + DW_CFA_advance_loc: 37 to 0+0026 >>>> + DW_CFA_remember_state >>>> + DW_CFA_advance_loc: 1 to 0+0027 >>>> + DW_CFA_restore: r3 \(rbx\) >>>> + DW_CFA_def_cfa_offset: 8 >>>> + DW_CFA_advance_loc: 1 to 0+0028 >>>> + DW_CFA_restore_state >>>> + DW_CFA_advance_loc: 9 to 0+0031 >>>> + DW_CFA_restore: r3 \(rbx\) >>>> + DW_CFA_def_cfa_offset: 8 >>>> + DW_CFA_nop >>>> +#... >>>> + >>>> +#pass >>> >>> Seeing this recurring pattern (the last three lines): Why not just #pass? >>> >> >> I thought adding #... is clearer as it indicates that the test knowingly >> skips lines thereafter. > > Well, #pass alone already says exactly this. If you didn't expect further > output lines, you'd _omit_ #pass. > OK. >>>> --- /dev/null >>>> +++ b/gas/testsuite/gas/scfi/x86_64/scfi-cfg-1.s >>>> @@ -0,0 +1,47 @@ >>>> +# Testcase with one dominator bb and two exit bbs >>>> +# Something like for: return ferror (f) || fclose (f) != 0; >>>> + .text >>>> + .section .rodata.str1.1,"aMS",@progbits,1 >>>> +.LC0: >>>> + .string "w" >>>> +.LC1: >>>> + .string "conftest.out" >>>> + .section .text.startup,"ax",@progbits >>>> + .p2align 4 >>>> + .globl main >>>> + .type main, @function >>>> +main: >>>> +.LFB11: >>> >>> Coming back to "hand-written assembly": The above looks very much like it >>> was compiler output (earlier tests did, too, but it's perhaps more >>> prominent here). That's not necessarily what a human might write, and >>> hence I wonder about the overall coverage that can be gained that way. >>> >> >> Yes, its inspired by compiler generated output. I ran into this when >> running some tests. Its still a good basic cfg test for SCFI - a >> function with two return paths. > > You understand though that I used this only as (sutiable) example. My point > being that hand-written assembly frequently doesn't resemble compiler- > genertaed code. Otherwise, i.e. if the resulting code wasn't to be different, > why would one write assembly code in nthe first place? > True. Open to suggestions on improving the testsuite. >>>> --- /dev/null >>>> +++ b/gas/testsuite/gas/scfi/x86_64/scfi-diag-1.s >>>> @@ -0,0 +1,23 @@ >>>> +# Testcase for REG_FP based CFA >>>> +# and using REG_FP as scratch. >>>> + .text >>>> + .globl foo >>>> + .type foo, @function >>>> +foo: >>>> + .cfi_startproc >>>> + pushq %rbp >>>> + .cfi_def_cfa_offset 16 >>>> + .cfi_offset 6, -16 >>>> + movq %rsp, %rbp >>>> + .cfi_def_cfa_register 6 >>>> +# The following add causes REG_FP to become untraceable >>>> + addq %rax, %rbp >>> >>> But this isn't a problem as long as FP isn't further used. Indeed ... >>> >>>> + .cfi_def_cfa_register 7 >>>> + pop %rbp >>> >>> ... its original value is restored right afterwards. Yet another constraint? >>> >> >> Hmm. I need some clarification on the statement "Yet another constraint". > > By "constraint" I mean assumptions you make on the way assembly code is > written, for your machinery to be usable. The more such assumptions, the > smaller the set of code "eligible" to (future) use of your work. Hence > also why I think all such "constraints" need to be spelled out in a > single place, such that one can > - verify that everything meeting these constraints actually also works, > - check up front whether one's assembly code is actually suitable for > enabling --scfi. > OK, Thanks. We are on the same page wrt "Constraints" then. In the above example, though, the "constraint" is due to the desire to be able unwind/stack trace asynchronously. Which is why it confused me in the first place, I think I wouldn't call this a "constraint" here. But this is a subjective line. In the above example, the 'addq %rax, %rbp' does cause a problem for unwinding because the CFA is REG_FP based. And the SCFI machinery needs to be able to tell what offset from REG_FP is the CFA. I think its correct for the SCFI machinery to complain with a ".*14: Error: SCFI: usage of REG_FP as scratch not supported" right away, because the unwind information at the next instruction is already affected. That said, I do agree that the constraints need to be spelled out in a single place. I already have done some of it in scfi.c, but there is room for improvement, I see. >>>> --- /dev/null >>>> +++ b/gas/testsuite/gas/scfi/x86_64/scfi-fp-diag-2.s >>>> @@ -0,0 +1,55 @@ >>>> +# Testcase for a diagnostic around assymetrical restore >>>> +# Testcase inspired by byte_insert_op1 in libiberty >>>> +# False positive for the diagnostic >>>> +.type foo, @function >>>> +foo: >>>> +.LFB10: >>>> + .cfi_startproc >>>> + endbr64 >>>> + pushq %rbp >>>> + .cfi_def_cfa_offset 16 >>>> + .cfi_offset 6, -16 >>>> + movq %rsp, %rbp >>>> + .cfi_def_cfa_register 6 >>>> + pushq %r12 >>>> + pushq %rbx >>>> + subq $24, %rsp >>>> + .cfi_offset 12, -24 >>>> + .cfi_offset 3, -32 >>>> + movl %edi, -20(%rbp) >>>> + movq %rsi, -32(%rbp) >>>> + movl %edx, -24(%rbp) >>>> + movq %rcx, -40(%rbp) >>>> +# The assembler cannot differentiate that the following >>>> +# mov to %rbx is not a true restore operation, but simply >>>> +# %rbx register usage as a scratch reg of some sort. >>>> +# The assembler merely warns of a possible assymetric restore operation >>>> +# In this case, its noise for the user unfortunately. >>>> + movq -40(%rbp), %rbx >>>> + movq -40(%rbp), %rax >>>> + leaq 3(%rax), %r12 >>>> + jmp .L563 >>>> +.L564: >>>> + subq $1, %rbx >>>> + subq $1, %r12 >>>> + movzbl (%rbx), %eax >>>> + movb %al, (%r12) >>>> +.L563: >>>> + cmpq -32(%rbp), %rbx >>>> + jne .L564 >>> >>> But this is pretty common usage. Imo this (the false positive warning) >>> cannot remain like this. >>> >> >> The warning of "Warning: SCFI: asymetrical register restore" was added >> to alert user if they do something like >> pushq %rbx >> pushq %r12 >> ... >> popq %rbx >> popq %r12 >> i.e., asymmetric save and restore. Now the user may do a restore to any >> register and use what was saved on stack as scratch regiser; the only >> way to differentiate between a "true reg restore in epilogue" vs "reg >> restored for scratch purposes" is to know whether its the epilogue. GAS >> will not be able to determine that easily. >> >> We could remove the warning altogether. I just thought it provides >> users with some protection / validation of hand-written asm. > > I'm in favor of such assisting warnings, but they're useful only if there > are few false positives and few false negatives. Too many warnings makes > people ignore them all (or shut them off), while too few makes people > mistrust them being helpful. > Noted. And I do agree. I just so happens that I dont have a solution to this problem of false positive warnings yet. >>>> --- /dev/null >>>> +++ b/gas/testsuite/gas/scfi/x86_64/scfi-x86-64.exp >>>> @@ -0,0 +1,103 @@ >>>> +# Copyright (C) 2022-2023 Free Software Foundation, Inc. >>>> + >>>> +# This program is free software; you can redistribute it and/or modify >>>> +# it under the terms of the GNU General Public License as published by >>>> +# the Free Software Foundation; either version 3 of the License, or >>>> +# (at your option) any later version. >>>> +# >>>> +# This program is distributed in the hope that it will be useful, >>>> +# but WITHOUT ANY WARRANTY; without even the implied warranty of >>>> +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the >>>> +# GNU General Public License for more details. >>>> +# >>>> +# You should have received a copy of the GNU General Public License >>>> +# along with this program; if not, write to the Free Software >>>> +# Foundation, Inc., 51 Franklin Street - Fifth Floor, Boston, MA 02110-1301, USA. >>>> + >>>> +if { ![is_elf_format] } then { >>>> + return >>>> +} >>>> + >>>> +# common tests >>>> +if { ([istarget "x86_64-*-*"]) } then { >>>> + >>>> + global ASFLAGS >>>> + set old_ASFLAGS "$ASFLAGS" >>>> + >>>> + run_dump_test "scfi-cfi-label-1" >>>> + run_list_test "scfi-cfi-label-1" "--scfi --warn" >>>> + >>>> + run_list_test "scfi-diag-1" "--scfi" >>>> + run_list_test "scfi-fp-diag-2" "--scfi" >>>> + run_list_test "scfi-diag-2" "--scfi" >>>> + >>>> + run_list_test "scfi-unsupported-1" "--32 --scfi" >>> >>> Perhaps a 2nd run with --x32, unless (see above) you choose to support >>> that ABI as well? >>> >> >> At the moment, the plan was to next work on --scfi=inline and add >> support for aarch64/aapcs64 ABIs. No plans to add support for x32 >> unless a need arises. > > But that's precisely my point: As long as you don't support --x32, you > want to check that its use is properly diagnosed (just like use of > --32 is). > Ah, apologies I construed this comment differently earlier. Yes, I agree we can add another run with --x32.