From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-he1eur04on2049.outbound.protection.outlook.com [40.107.7.49]) by sourceware.org (Postfix) with ESMTPS id EE32E3858D1E for ; Tue, 31 Oct 2023 16:13:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org EE32E3858D1E Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org EE32E3858D1E Authentication-Results: server2.sourceware.org; arc=pass smtp.remote-ip=40.107.7.49 ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1698768825; cv=pass; b=DW/RnBzXtvu1aq9VAc3zjrpOtQKBbHaioeUUqf9peLAdEYJ9ZOl5Q9wy/tkLsgiq3RdGa1kYIY7+VQIsiyKtYvrgP3aFBUTdriStc/GY+reeIe81ZtOXOU3J/NbYPCRl3cG1QlW5Vmqrmc3LI8QMq7E/0nUUzpAvtPEb+TB6IZs= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1698768825; c=relaxed/simple; bh=Lpvjco4VrwtosBnfflgILcp/bZP7OlETtN6/cTRBTVU=; h=DKIM-Signature:Message-ID:Date:Subject:To:From:MIME-Version; b=ZYtr1Lwm6/ODKeUCP9oyZYXT+8cpZZh7kH9S80SelzgqN1xwjK63q5nBaGqI1NJ5X/cSZpqwuiDCKT3oBJiUIo6soj8keMZECoHU25xe7MHoFMG/w1Ww9ft91RRmcwpIg6gfyNQdoXu9oEX2Tm7kjNnTx6/ryhA9pEFRlFd/Qjw= ARC-Authentication-Results: i=2; server2.sourceware.org ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ww2KTzeZTRcc5+guvyHlRH5cOpeVhpw/SOJpsFWiQdq1I/dlz3UByoGjfDrCRpo7ShrESTvJ6V9YL9AQoVg7FBodnncxBlJHKPde5FWQpbHIL1MqBOjwo81GNrmA75vI5YOPbBj4nXQSXilkn01Wymsf4QHp4lvifyMuagY9Hn/NIWHXSXn5zB/W9jVrrytxqgLM5tjakfug2CRcTEVyavIlplfmIQv7zEZJXOgdrzwqQdPvliDU/1H/m5Kz26fPF3UR8IlgZOscXeRv7jmxIlguWPUaxdP1JcS1mGqJPM7Wb8uf4o8ccaqwb1yYro/n3dgrWyhrZZ3pY5UxdczkDA== 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=TdGiFiTLbWzBg9HBtPEvd0DrBwPdgB9MgL4s9nffWVg=; b=kgtykSHFKmF5c78usSH1XQtKsOMhlvP/6x0mdjp3v9dCqj5dJV+CqWxoaLqBKx8+bJzftnEzi/1/r3aVU6Yr9V4/KgI0I29J0qXolr86IWZ+LeVC3nn1QeJ1l6YxIEXj3hp7RKn+R0ueQ1IK2u6wWiuxqqHK75q6WzXRaOnncnoWZEM/V3KCp/a1MfdbRbTKooajA7eLDg857HnIN7wwkZ2w27iVgHxGQL8DmiRCEvf8jzlcOgZf3xpCZahhEku6DTAgKWdynXjYbRx4YpdcCYDt3+459NVfuk8/T9tM7v/0z6giXfqggc+yE8YkNqHac5W0fLalLffE+U8VwSe7ag== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TdGiFiTLbWzBg9HBtPEvd0DrBwPdgB9MgL4s9nffWVg=; b=QkD3Lsup4YtbWthJ0PIqJ6/upjkp4b8acO2Wp5BuyslGOqOWrT+pe3PEQ2KooKs6GYX1HJE0Od5J6+f+vKA789o23TyEiU2mCaR3UrNx0m2JIPZvgneJIM7/3StjYQTaZjf6OW6t5tcPWW2NhUm/MvcmmBYB10A+lDwXYldDb5HqETP7p2uivcmcMzYxzGjmx0dgtui4vvgs0L/cXf0gTVY2VE6PXbZyWfSKyQYjpUAZhUneUpDGMbe5BJhKJc626CfqmKu4jdwzyGakIkUi1dgG6/11IPCmdQMkfsHr61G6u9Ivqo+gN3yNZBDlxlzkR2phMFFbA5rDohFDxLB1uA== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com; Received: from DU2PR04MB8790.eurprd04.prod.outlook.com (2603:10a6:10:2e1::23) by PAXPR04MB8878.eurprd04.prod.outlook.com (2603:10a6:102:20d::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6954.16; Tue, 31 Oct 2023 16:13:36 +0000 Received: from DU2PR04MB8790.eurprd04.prod.outlook.com ([fe80::d924:b650:a2ad:7b25]) by DU2PR04MB8790.eurprd04.prod.outlook.com ([fe80::d924:b650:a2ad:7b25%3]) with mapi id 15.20.6954.016; Tue, 31 Oct 2023 16:13:36 +0000 Message-ID: <33168ad4-97c6-6028-7055-2f21434ccfd1@suse.com> Date: Tue, 31 Oct 2023 17:13:34 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Subject: Re: [PATCH, V2 09/10] gas: testsuite: add a x86_64 testsuite for SCFI Content-Language: en-US To: Indu Bhagat References: <20231030165137.2570939-1-indu.bhagat@oracle.com> <20231030165137.2570939-10-indu.bhagat@oracle.com> Cc: binutils@sourceware.org From: Jan Beulich In-Reply-To: <20231030165137.2570939-10-indu.bhagat@oracle.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: FR0P281CA0170.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:b4::8) To DU2PR04MB8790.eurprd04.prod.outlook.com (2603:10a6:10:2e1::23) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DU2PR04MB8790:EE_|PAXPR04MB8878:EE_ X-MS-Office365-Filtering-Correlation-Id: e637bf21-ef02-465d-feb3-08dbda2c5610 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: z7lVH1wwtUZAjTyQAdJUR05q0COXgtubFeRrsp20IXV4pmE4aJevRsXx3M2Yq8DeKXvjIRzyetRf71uO9YHHBs3A0kNwb4tt5zeKtUJsbchFOdkAYilJ7+gSP4MzyTOWfJzJVzoo3a5bNbqwE43ec8HcvakP4cCD75DQckgoXx6xmosP6C4G6yA2O6hm08lYyAZZv9kCsftCeHNr6xkAhAem2IoDSGvqIGTRav1XR5z2eTH7+X06CAqEKxYd809iE/wz9+yEmUus/VqehSTBBh2EVBRGemvRZvPDcTs7stdvh/TO+HVuvWIB03sRn9LjF6fheDbumcIxw6hqSbnMG5nKWsyBJYPhV6crdLi19kHsOW5tx1Zcy1JiK3l5XsebWBIm5mWfJM1nNjG+rd4EyG7KAXyHY2AU8eiYaY2GgkQJGF+3KP5ueMj7+F+hh4i+mc9dFc7qYF/RdvQVm1YzKre0fSb1V2SvP8F/OwsZB/WSq3hngydgmp3i8xYtaNT1PNALrZbNUW67xNwRHy3l09IwyVbZ0qWNlovwpt8w4fmSJOO6E/4+DrStAPA6zl+ug/D7uegX32A8x2HEMThOhr+mfc8Z0RCXRLnd+lrchM3OfD4gU1kOpTRqR+DuusO2AeoIiy1DRvuvi+t50nVEse2pFDhpmyaj6/5UQOtjBIGnEQ6+zg3AdxoX6Uwpuuu5QmSVhlXIzu27v2/A9RTB+w== X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DU2PR04MB8790.eurprd04.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(366004)(376002)(136003)(396003)(39860400002)(346002)(230173577357003)(230273577357003)(230922051799003)(186009)(1800799009)(64100799003)(451199024)(83380400001)(30864003)(41300700001)(2906002)(5660300002)(36756003)(31696002)(31686004)(26005)(2616005)(86362001)(6512007)(38100700002)(6506007)(53546011)(6486002)(478600001)(6916009)(66556008)(66476007)(316002)(66946007)(8676002)(8936002)(4326008)(2004002)(45980500001)(43740500002);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?TmcrL2RqRDBZRHpyU3BmcUxpRnlsdFpwTjEzNW1kQ24yMzFlWXVQbWZ3Tmky?= =?utf-8?B?TmlpUEovNHJCSWc5SGp6OGYrODdySkMyemNSNE4zaFgrOFBYdXNrVWdEME5r?= =?utf-8?B?aFN2YkgwVXdRZk5KdXVrMGVFK2llSG9VUkxYRUc0aTlhRktKdEJEMmdhMmFn?= =?utf-8?B?cHZnR2grQWV3QTZHNkZ4R3RHa2xOMmNEemQ0Tmg1KzZGUjFJTjNwSWY2M0dh?= =?utf-8?B?ZmtUSzdjTm94QklDd1NnbmJveDUzUEJRZjB4RGdlSUJJWHdJalF4d2lsMi91?= =?utf-8?B?NVJTQS9CcWZNaGozOE0reFFMcmZWclhpRzRVK0JoSVQvOFU1TTBRV0Flb1pr?= =?utf-8?B?YitzNHAvSlo0RDNwSVlHWkJNRTFxeHc1TkUveXdqcWVkYjVFUGZtZW1sS3hh?= =?utf-8?B?QUY2NUg5OW1GSGYxYjZqQjA2MFVjTmVIR0huNytWRitJYU1Cb21BVFk4Vy9X?= =?utf-8?B?Z3B2TmR3Q3JXclByUjdFU1orUGxEOTZ4TDMxV0x3d0NGWW1lRWdGZTFIeFZV?= =?utf-8?B?ZWpMczFtY3ZrRHJMZmVDbDFGOWl2eHZQa1cvaTl6QStEdkpYMlJSTjZBdFk5?= =?utf-8?B?enFXTkNuTGJ6WkFwVnVCc1dHUnNVMXBkMFJBTGNMOGNYS01DQzhlcjVsUEE0?= =?utf-8?B?bjhJTUFONmtPZUJiMUJDMjd2MGo4emJrODRobTRaQ2RMWTlFZ0E3OWRJNEF2?= =?utf-8?B?YWRQazBxQ2FEUDRGcG5wRmROekdHNXNDajlFejVxUDFSbEVac21aV1ZWT016?= =?utf-8?B?dys1ZVI2aUVNZlgzeW12Y242TFdrc2RpL1p5SW9aVnlLcC8yWlVzc2Mveklp?= =?utf-8?B?ZnB1YU5oSGZOdlRIbElxNytlQTZIZE5GSGtVbmJmMkZpOGZtaEN5VnpPTnUw?= =?utf-8?B?VFpSV0YwODhWZjNzdG13QXFVSXh5S1FXdDhaNTB3amt2Q09Wc3Z0M1kwVzZW?= =?utf-8?B?UGZVRjJ0RUtLelc3bTZxcStXV2pqTVpGRGJ4ajhvNytMN1I3Yzc3NExBelZ1?= =?utf-8?B?dXdnK3htSTc2SEVsVjlmdTJKSUZQTm1teWRBcmJwaFp1dTZyUnVvalhDTjRG?= =?utf-8?B?Ykt0OEFGcmEveFJ2NVF4TEhIUlcvMnVwUC90NXVZM1RJSnFPTU1hSVd6RFU1?= =?utf-8?B?QmtML3ZnVVUzSi9uSUc0aEZyMlRVY25Hclh4b1Z3b0hwTUlSMzBBakRYRGg1?= =?utf-8?B?aEJsNGdReUtmUHZaQURWSktXV2ZzWW1HcGYrZFVscURxZkRTUzJ4SjR3RGNI?= =?utf-8?B?OGpwSVpNdFdzeDFtbENqeGI5NklydVZDYWZWaTgvYVB5U25KOGF5KzZTM3RL?= =?utf-8?B?enVjdnYrSVJTZmJzUUp0UFMzMHdFSHBJKzYrS3ZvVmNzcjdtN2pzV2N0cy9v?= =?utf-8?B?aG1leWNzcnR3N0NGeDhBdlh3eFJPSFZjTDN4RG5oTjZCcE94aG9RN0FlWXgx?= =?utf-8?B?RjI2RVBEajZXVDlFd3F1UWdWWXorSzJlUGxQMDZoTEt6b2NzeE1yVnlOdTdQ?= =?utf-8?B?THRQMy9wZ1F2MkhCcm1PWXUvS2FtVXBtY0JpLzJkS3g3U0ZwSit4U3c2SlJj?= =?utf-8?B?ZkFkeHJqbklRU3k5TzBkejZ2SWNWMFlVaXJoN2toUkZQTkR4Wko2TU10R1RW?= =?utf-8?B?UDVCWFcycEsxQ3Z1WWl1cFB5aHFTd0xrZ01XK0t5N3pEalJUMlBIRlQ0RE1R?= =?utf-8?B?Q3hVSFJQL2ZHWUtpOU0vblE0N0FyWlZ4eDBYTG1BdXo1QjRzQVlFajh3aHU0?= =?utf-8?B?L0xSN3lEM0YzQmQwbS9ZZlBXRFNXcERsemJjZGs5ZjZjS2hXeXg1WkRGWlFE?= =?utf-8?B?RXN0eVNIS0d6bkU5TGxZMGhJck5lc1FFRUh4ZUZGenQyZ0c1MDFHYnE2b2Yv?= =?utf-8?B?bksxVXNOSnY3czNBTndKejBJa1ZsNC9IK2VIRDQ4UkYxZVNQZllsQUlKbFFq?= =?utf-8?B?TnBZTlAzWGg4ajJDOXRWdytURTRncVFaY2JlWlp2QW9WNXhReHlsZFcyZ3Bx?= =?utf-8?B?QnhpU3pMbXlJZGhZZFJMbWo0TWZCMitqdms0andCak5NVElpYUJWMWo2bXhD?= =?utf-8?B?OEs3OEU0T0tQZWVYMFZSYVNRTGJuNlVDODNmTGdjRk1GOG9wNXFYNXdFMWpw?= =?utf-8?Q?U5ptoQXtbpJvGltsAw1FnAYZ0?= X-OriginatorOrg: suse.com X-MS-Exchange-CrossTenant-Network-Message-Id: e637bf21-ef02-465d-feb3-08dbda2c5610 X-MS-Exchange-CrossTenant-AuthSource: DU2PR04MB8790.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Oct 2023 16:13:36.1736 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f7a17af6-1c5c-4a36-aa8b-f5be247aa4ba X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: bxmMH9bqQMUIzwubfBwjM0O4Tri7CItoQ1RoWJcMWhnZxo9m+tSe/WPaHwuF4SEcEhDvy4JR7bTmh7zNmCWdfw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAXPR04MB8878 X-Spam-Status: No, score=-3034.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS,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 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 ... > +# Popping a callee-saved register. > +# RSP must be traceable. > + pop %r12 > + .cfi_restore 12 ... what the comment says about these. > + leave > + .cfi_def_cfa_register 7 > + .cfi_restore 6 Using numbers here isn't very helpful, I'm afraid. > --- /dev/null > +++ b/gas/testsuite/gas/scfi/x86_64/scfi-asm-marker-1.s > @@ -0,0 +1,27 @@ > +# Testcase where a user may define hot and cold areas of function > +# Note how the .type, and .size directives may be placed differently > +# than a regular function. > + > + .globl foo > + .type foo, @function > +foo: > + .cfi_startproc > + testl %edi, %edi > + je .L3 > + movl b(%rip), %eax > + ret > + .cfi_endproc > + .section .text.unlikely > + .cfi_startproc > + .type foo.cold, @function > +foo.cold: > +.L3: > + pushq %rax > + .cfi_def_cfa_offset 16 > + call abort > + .cfi_endproc > +.LFE11: > + .text > + .size foo, .-foo > + .section .text.unlikely > + .size foo.cold, .-foo.cold Related to the comment: Is it "may" or is it rather "need to"? (In the latter case it would be yet another constraint on when this new machinery is actually usable.) > --- /dev/null > +++ b/gas/testsuite/gas/scfi/x86_64/scfi-asm-marker-2.s > @@ -0,0 +1,11 @@ > +# A programmer may not bother to set the size of the > +# function symbols via an explicit .size directive. > + .globl foo > + .type foo, @function > +foo: > + .cfi_startproc > + testl %edi, %edi > + je .L3 > + movl b(%rip), %eax > + ret > + .cfi_endproc Wasn't it said elsewhere that .size needs using after the function? > --- /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. > --- /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? > + xorl %eax, %eax > + addq $32, %rsp > + .cfi_def_cfa_offset 48 > + popq %rbx > + .cfi_restore 3 Nit: inconsistent indentation (also elsewhere). > --- /dev/null > +++ b/gas/testsuite/gas/scfi/x86_64/scfi-callee-saved-1.s > @@ -0,0 +1,26 @@ > + .text > + .globl foo > + .type foo, @function > +foo: > +# .cfi_startproc > + pushq %rax > + .cfi_def_cfa_offset 16 > + push %rbx > + .cfi_def_cfa_offset 24 > + .cfi_offset 3, -24 > + pushq %rbp > + .cfi_def_cfa_offset 32 > + .cfi_offset 6, -32 > + popq %rbp > + .cfi_def_cfa_offset 24 > + .cfi_restore 6 > + popq %rbx > + .cfi_def_cfa_offset 16 > + .cfi_restore 3 > + popq %rax > + .cfi_def_cfa_offset 8 > + ret > +# .cfi_endproc Why are startproc/endproc commented out here? > --- /dev/null > +++ b/gas/testsuite/gas/scfi/x86_64/scfi-callee-saved-2.s > @@ -0,0 +1,42 @@ > +# Testcase for save reg ops for callee-saved registers > +# These latter two pushq's of callee-saved regs must NOT generate > +# .cfi_offset. > + > + .text > + .globl foo > + .type foo, @function > +foo: > + .cfi_startproc > + pushq %r12 > + .cfi_def_cfa_offset 16 > + .cfi_offset 12, -16 > + pushq %r13 > + .cfi_def_cfa_offset 24 > + .cfi_offset 13, -24 > +# The function may use callee-saved registers for its use, and may even > +# chose to spill them to stack if necessary. > + addq %rax, %r13 > + subq $8, %r13 > +# These two pushq's of callee-saved regs must NOT generate > +# .cfi_offset. > + pushq %r13 > + .cfi_def_cfa_offset 32 > + pushq %rax > + .cfi_def_cfa_offset 40 Why "two" in the comment? %rax isn't callee-saved, is it? (Same in variant 3 of this kind of test then.) > --- /dev/null > +++ b/gas/testsuite/gas/scfi/x86_64/scfi-callee-saved-4.s > @@ -0,0 +1,55 @@ > + .type byte_insert_op1, @function > +byte_insert_op1: > +.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 > + .cfi_offset 12, -24 > + pushq %rbx > + .cfi_offset 3, -32 > + subq $24, %rsp > + movl %edi, -20(%rbp) > + movq %rsi, -32(%rbp) > + movl %edx, -24(%rbp) > + movq %rcx, -40(%rbp) > +# The program may use callee-saved registers for its use, and may even > +# chose to read them from stack if necessary. The following use should > +# not be treated as reg restore for SCFI purposes (because rbx has been > +# saved to -16(%rbp). But even if the value was read back from -16(%rbp) you wouldn't know for sure that that's the ultimate restore. Yet another constraint? > --- /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? > --- /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. > --- /dev/null > +++ b/gas/testsuite/gas/scfi/x86_64/scfi-cofi-1.d > @@ -0,0 +1,5 @@ > +#as: --scfi -W > +#objdump: -Wf > +#name: Synthesize CFI for add insn > + > +#pass > --- /dev/null > +++ b/gas/testsuite/gas/scfi/x86_64/scfi-cofi-1.l > @@ -0,0 +1,3 @@ > +.*Assembler messages: > +.*12: Warning: --scfi=all ignores some user-specified CFI directives > +.*22: Warning: Untraceable control flow for func 'foo'; Skipping SCFI > --- /dev/null > +++ b/gas/testsuite/gas/scfi/x86_64/scfi-cofi-1.s > @@ -0,0 +1,23 @@ > +# Testcase with a variety of "change of flow instructions" > +# > +# Must be run with -W so it remains warning free. > +# > +# This test does not have much going on wrt synthesis of CFI; > +# it just aims to ensure x8_64 -> ginsn decoding must behave > +# gracefully for these "change of flow instructions" > + .text > + .globl foo > + .type foo, @function > +foo: > + .cfi_startproc > + addq %rdx, %rax > + notrack jmp *%rax > + call *%r8 > + jmp *48(%rdi) > + jo .L179 > +.L179: > + ret > + .cfi_endproc > +.LFE0: > + .size foo, .-foo What exactly is being tested here? The .d file is effectively empty, and the .l file expects a warning on the .size directive (which tells about nothing regarding the reason for the failure to produce SCFI). > --- /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? > --- /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. > --- /dev/null > +++ b/gas/testsuite/gas/scfi/x86_64/scfi-ignore-1.s > @@ -0,0 +1,13 @@ > + .text > + .globl foo > + .type foo, @function > +foo: > + .cfi_startproc > + pushq %rbp > + .cfi_def_cfa_offset 16 > + .cfi_offset 6, -16 > + ret > + .cfi_endproc > +.LFE0: > + .size foo, .-foo This, otoh, imo wants diagnosing. The framework ought to recognize that the RET doesn't use the correct stack slot. Additionally, isn't scfi-simple-1.s effectively testing the same? The code at least looks extremely similar. > --- /dev/null > +++ b/gas/testsuite/gas/scfi/x86_64/scfi-unsupported-1.l > @@ -0,0 +1,2 @@ > +Assembler messages: > +Fatal error: Synthesizing CFI is not supported for this ABI > diff --git a/gas/testsuite/gas/scfi/x86_64/scfi-unsupported-1.s b/gas/testsuite/gas/scfi/x86_64/scfi-unsupported-1.s > new file mode 100644 > index 00000000000..87d2a4971a1 > --- /dev/null > +++ b/gas/testsuite/gas/scfi/x86_64/scfi-unsupported-1.s > @@ -0,0 +1,10 @@ > +# Testcase run with --m32 (Not supported). > + .text > + .globl foo > + .type foo, @function > +foo: > + pushq %rbp This code, being built with --32, is bogus anyway. I wonder why this file has any insns in the first place. > --- /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? Jan