From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60049.outbound.protection.outlook.com [40.107.6.49]) by sourceware.org (Postfix) with ESMTPS id 5F440385223A for ; Fri, 25 Nov 2022 09:04:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5F440385223A 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-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bdlhMJisoEm/UwOJ72W3Wny6sQKMrig4QWLkKstXYUAeAiTY7fg1sEtxN+ac0CzVg2YLDoLUYs/pkzXy6xrwdSF8NaJxTDfo+ZjGlcA9un4DPxiKYDa9Eoke1gzfg1qRsMMLUjv0+FRh74+jiwQ4mhnKDl9SzjSeuX652I8rJinDJXx884U0Z2b1/GNP8bJ/xdZ6h2HivyptrnuILInmwakU44kjQxglGySgA4j6FT6epwmMe0rlvyVWhdqdXdGpcgCJoiefplEZ8RyphPeLaaBYFuSY0VbBR9D7N+oV27FjMT9ivQqzMX/Zdcnb8ZclOU83OnvP0qHIU+sTb1D6NA== 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=gbh/NJ4LFvb+Qpopq0qwnbi4i9fv2IfFDtlFGueAPbU=; b=GQZnMNj3On3FhLl4VZrt17Ug9eAJyxIWc9hybeZBQwGMPf8JPlIf6qQ5uw8lGTOnsY7d8JcjtgfFdw1wKbVZ2dCnbLK2iMKoYPXkWnAwR8CxyD7VmSNx+iUyroWrY91O6i29aHdMiCo77PzEA3DAU5rBENtbVqhDPQ5A5vUvkBF42cMPwUo6s67GXvc5T0LV+aBuzLMk4Z+Sf64b2X355sZ+kLeOJUX7T0Y+lTqj91DO8ElbvZHDpSvSMIRqEbTb7ipZgeAOYj8Z2nHip17J1ZcZMBkzWqYRMCU/c4coWyiEGRtvj56DA4rhIXSGxxLaTDLHYXn/hVY4yu87n4CKjA== 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=gbh/NJ4LFvb+Qpopq0qwnbi4i9fv2IfFDtlFGueAPbU=; b=Nwxeq3cv7+fA4vaIMZuLQETqiWdKoG2VxkODL9XEo+Ll9wbDIR6tKSoLK+QQo04+6UKlZ9jMdVbFF9/xnnjPMG7pjOwO3Pv2aysuETvLUFV+osJ3vqfRbYDMGViNKqGoHdfEOHQVDbUg5ACpe4iPbVv3XCjn4R4+MRVcL6YMBmV65AMrlFA96/1q229VMgVC7xbNlUANgD6iDD/+9hH4SmOqeNJ8I/qaRfUaFcmt6M6hRZYSxMltjS9Xm9ESEdcxeQ09CLII6JOm3+tN6nOO6APJ5OjExlQQynEYrH6+rYQP3AQSUQi3EpdE0zilSlK1/0nnMfKWtrW2sJdUYmhsrg== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com; Received: from VE1PR04MB6560.eurprd04.prod.outlook.com (2603:10a6:803:122::25) by AM9PR04MB8066.eurprd04.prod.outlook.com (2603:10a6:20b:3eb::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5857.17; Fri, 25 Nov 2022 09:04:23 +0000 Received: from VE1PR04MB6560.eurprd04.prod.outlook.com ([fe80::4da2:ea8b:e71e:b8d8]) by VE1PR04MB6560.eurprd04.prod.outlook.com ([fe80::4da2:ea8b:e71e:b8d8%4]) with mapi id 15.20.5857.020; Fri, 25 Nov 2022 09:04:22 +0000 Message-ID: <766c70f2-0b34-7c43-4d88-082740e598f1@suse.com> Date: Fri, 25 Nov 2022 10:04:20 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0 Subject: Re: [PATCH v3 2/2] RISC-V: Better support for long instructions (assembler) Content-Language: en-US To: Tsukasa OI Cc: binutils@sourceware.org References: <47d1751320314f02bede4f6096c09b7f6585c94d.1669342633.git.research_trasio@irq.a4lg.com> <5f723e04-ee60-08e2-0314-51ebd9418947@irq.a4lg.com> From: Jan Beulich In-Reply-To: <5f723e04-ee60-08e2-0314-51ebd9418947@irq.a4lg.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: FR3P281CA0124.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:94::15) To VE1PR04MB6560.eurprd04.prod.outlook.com (2603:10a6:803:122::25) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: VE1PR04MB6560:EE_|AM9PR04MB8066:EE_ X-MS-Office365-Filtering-Correlation-Id: c3b4d616-4e4e-40df-edf0-08dacec40b30 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 77nxA5H9uLJM30KxrHbdIHmkPGIkLfM00sUXW8Surr1CWjMhl+v9l9UntQTIXCuWhsALooOzIy9UPIR+eYNqL/7r7p1g4QyvDxK2C5Te5X2YmNuntVYCRE8aKIMhz+tBQ56s1kdy9Nvxi/O0RVJ+csGOWNkdYNWpp3mYpuQGTfb0v1oU++8jkmUfrO6A6mird7UwQp0h8ZG8+kJuso/bCwpZ5X3YRoQNfF82OGeFhjH29rgSYBcRGHhPjz6XxrBRVfVwx1/DXEPS2h1jisKGIxrbaL8MY6RKsbr60m0fZxFCjTr2XLcR/D1MRZBtKkv8Z2UvnZWKXJ3EdZFqLk3ecJCu9C8jiGoevaydwCnbA2TIlyktuOjcd6Qg1a5z0JAE30s3ultZ5GJG4UwRaccrL9UEGOLWKGqwDQ4PdRRSfRZiQpfLkGlJ8Syz06JRwXT+rMkYPR5olBV0mfd2y5G6B9asH8KrP634rNLdjFf8MBDwzsIXprPIavmv/eTvNNzFMKR2vtWiKc0hj/V2p7Lb6x2hTprwVlKcjlp17mHd8opwRurjBpEo1bRcA6XeEAgdEprNbcJU3P9cx1KVXxCutOUzF0zEumq6vkSN+2615l4ktq574jz+cNhSEHY5qH9EwwMZv5HbP5yA6klq2pQmkHvsfSdYCkd63Q0PtrK4Dk4/uEKZmd9IZ/Zwpm/y6Gl2rL/NzPFTVBwcOyNxSrNnv6QZvwPh6SNBYK1EVGirev2XlOnBvO9bHBhW1bxbQVcU X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:VE1PR04MB6560.eurprd04.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230022)(396003)(136003)(376002)(366004)(39860400002)(346002)(451199015)(41300700001)(86362001)(2616005)(6486002)(26005)(53546011)(6506007)(6512007)(4326008)(478600001)(8676002)(66556008)(36756003)(186003)(83380400001)(66476007)(6916009)(66946007)(316002)(31686004)(2906002)(38100700002)(31696002)(8936002)(5660300002)(43740500002)(45980500001)(376954003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?azRUejZBQTJ1NjczcEI4ZDE3Yy9OZ210MVpKTWFvclZrS1M1U0FSTDI3Nyt2?= =?utf-8?B?Zm00SjN4UEJoK041Sk1zRHZIMDJIa1o2N1JSOERYMzE3NXppd3dDeVJheWY5?= =?utf-8?B?bFFlRkVOSkgvMWFxNVpwUjA3MHhRU1prb29VVDg2OHg1ZmxXUWd2aUFaOFJU?= =?utf-8?B?VFVvOVdNWm91bnpmcXdoNm1OYTVaalNqS1hyK3BOWHdkVmRYMFlJSnU2SE92?= =?utf-8?B?bFk3Z3QrRFlPNGV0QTU2eldSYW1GWTRFd3dxeFh4WjFqVUdKUDl2bWZiSkN5?= =?utf-8?B?OWEzR0s0WmJuT09ZczFKS3g1Y3NoeldHTHpTMC9iMnJFTTdwcjBGNzF5TVhT?= =?utf-8?B?S3FtR0s0WGFURnlXUXIvOG1wbUEyV1I3Tk5vaXFKQ2FzTEI2WTQrcHdybnNl?= =?utf-8?B?UHdxemVaVEFjTmJka1o1RDcyUWNmZTVWZVppWVVGcGhLcTU0dHp4amh6WTBn?= =?utf-8?B?MTlEUUdlT2lxNDgybU1GVkN2RzN4S2xrL0lKQjYraVRqam1YTlQ1bEZ6Zkps?= =?utf-8?B?MENqTW9zOWwycHZkM0M2VFFvcUdlVTQxLzlsZG80bHFuak9OL3JUTFp5b1RU?= =?utf-8?B?eDhQK0pqM1VseVZTbzViL3Q5MFFlZmRKYVZJS3E2dmg2WFlPMms1MUVyVHJ4?= =?utf-8?B?RFJBVjZlK3RFd3RtekNSQkljNEdEL2ZKZzQyZGFDQ3lneWVBb3BtTFdzSmxG?= =?utf-8?B?Qkw0bUpiT1BXSitaYzBPVm5vRUJzY0FQUmhNUlU0UnhFMjBuMTZoTDFHSGNT?= =?utf-8?B?VEhPS3BEMVhKOWNtOUVQYzNtSUorL2EvaHJycEIxaFNnOWsrb3Y3RWZacWhs?= =?utf-8?B?eHJDSFRnaUlMVTErbHU3R3BSaWRpakQ0UjNhRElmZ0djc1M3TFFpOVNobCtY?= =?utf-8?B?ZEtLbXF1cm10ZnJZLzd6TEFiTmhOUHdXY1AvcnlqT1RDUlZ3cUZHazd6aUxw?= =?utf-8?B?dTg5ZVNCOW1DTDluWUxRSGZRc0JkR2tIdVlYcmlGeWl0Sjc0U0haVVUyQTZH?= =?utf-8?B?cWJDYTJHNHZCeVBWUkhRdEh3Ty9rQmlLMVR3MXpIMHU1UW1qTnMyT0hkeXpo?= =?utf-8?B?UzdFcGNGUWdBWTVUbnM1TEI0ZUlDRE9IV0NQUDFld3JWbHVyMWNDWU1IZW5j?= =?utf-8?B?VERGNllrbUpLa0NzLy9NZWRYZlU2czlqN3MwVHhHVnBRd09iNXh3NHI0dVZT?= =?utf-8?B?V29aTGwwUFBGelphS1ZGOE5UazFJZnBPTnVsdG9Jdm9mRTVOVkdBblFEclJI?= =?utf-8?B?dFFtNlh5ZjNZZDFZRHRUNG5udmw3cW1DcGNzSElSZjNaRlJEYTZ6MDI5TkR2?= =?utf-8?B?b25nSXlENCsva083Y0gvOHZZZWJIM3lmRzQrQ2RtUXFNeXFQYmswNXNrVWgy?= =?utf-8?B?aDhNYkI3TFhxbXhwOExtUCt1TUhrZVVyZWZscVJ1UmRDQWV3ZTQ0S1pyZlFD?= =?utf-8?B?cUk3VVAwaUptandmSkNtR2lwVWw5cWxZV3ZFQkY2QU5FN1JJbDdKWjFKRko2?= =?utf-8?B?Q3FlSjZWcldJVmhlOFJPZ09jTkJURnh6RmMzbEo2YmdWRElyakszOVRvWUhj?= =?utf-8?B?cTZxUUdpT2d1b0NwTUpsSVJiN3hOVjROU1RBd1E4YTFUb0ZYWDUxV29yYzla?= =?utf-8?B?M291YU5tcWFMSnU5Z3FRanVFWmpxN0hmQnVVMlF5RUo3NHY3STBnL0dkbUkw?= =?utf-8?B?dmF6Z2ZQYXpFU0diNUgzYkh5VUpLL3NzL3lXcUFxOW1YSTlNS0JPeEM0MlhJ?= =?utf-8?B?Y3daNTk0WlB4WTd2SCtibkNPM2pZbW0vcWxJZGJhVVZHUlNLT3Y2b0t0TU9K?= =?utf-8?B?bGJERFJhdG9MZkcyRWM0ZFFoYWFQVzNvNFJWWmNiTkhTWkdoYXFRNXlOUk1m?= =?utf-8?B?a1VjQ25tNlpyRWZGcmNIc0Z5dGxlYlp0cmh2em9vZVRVMzFZWTRoTEYrUmgx?= =?utf-8?B?L0FBanNxZ0FEdEJJeERJMXdPWHFkNWxzNlJkeTZndEdYWC9YM1VYcDFDWjZF?= =?utf-8?B?ZUZtZnk0dFBCRGcyeGpKbVpDSld6dlNDekl2Z0NGSFlOOVcrY1RYTnFvR2NJ?= =?utf-8?B?RW52clZCUS9Rdmxpc01LeGh5ZjJncWNQVFB5MEplT1hWTXl6SUVuMkhVY1cx?= =?utf-8?Q?Pnrny8kRScPCS+CSfaPhmR5aV?= X-OriginatorOrg: suse.com X-MS-Exchange-CrossTenant-Network-Message-Id: c3b4d616-4e4e-40df-edf0-08dacec40b30 X-MS-Exchange-CrossTenant-AuthSource: VE1PR04MB6560.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Nov 2022 09:04:22.6607 (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: EsVwVGEwyfyjKEwwInfAjn75iSZQX2165S89q1UnQzgC3G7QlkJzrIPE2pgQHN4BOOos2NR7Q8umif/un0xC6g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9PR04MB8066 X-Spam-Status: No, score=-3029.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 25.11.2022 09:39, Tsukasa OI wrote: > On 2022/11/25 17:15, Jan Beulich wrote: >> On 25.11.2022 03:17, Tsukasa OI wrote: >>> --- a/gas/testsuite/gas/riscv/insn-na.d >>> +++ b/gas/testsuite/gas/riscv/insn-na.d >>> @@ -73,3 +73,11 @@ Disassembly of section .text: >>> [^:]+:[ ]+007f 0000 0000 0000 0000[ ]+[._a-z].* >>> [^:]+:[ ]+0000107f 00000000 00000000[ ]+[._a-z].* >>> [^:]+:[ ]+607f 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000[ ]+[._a-z].* >>> +[^:]+:[ ]+007f 0000 0000 0000 8000[ ]+\.byte[ ]+0x7f, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x80 >>> +[^:]+:[ ]+007f 0000 0000 0000 8000[ ]+\.byte[ ]+0x7f, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x80 >>> +[^:]+:[ ]+607f 89ab 4567 0123 3210 7654 ba98 fedc 0000 0000 0000[ ]+\.byte[ ]+0x7f, 0x60, 0xab, 0x89, 0x67, 0x45, 0x23, 0x01, 0x10, 0x32, 0x54, 0x76, 0x98, 0xba, 0xdc, 0xfe, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 >> >> I have to admit that I still don't see what good the ".byte ..." part of >> the expectations does for the purpose of the test. In the cover letter >> you say "They are not 4-byte aligned (10 and 22-bytes) and unlikely to >> change any time soon." But changing that is exactly my plan (unless >> objected to by the arch maintainers): Showing insn components as bytes >> is imo reasonable for RISC-V at most when things aren't even 2-byte >> aligned. IOW I'd see these to be "disassembled" to ".2byte ...", >> matching the "raw opcode" output left to .byte. In fact when raw >> opcodes are output I question the need for any .byte - it's fully >> redundant> >> Bottom line: As before I'd prefer if these parts were dropped (to limit >> the churn on the files when changing the .byte granularity), but I'm >> not going to insist. Apart from this the change looks good to me. > > Okay, I have to admit that I misunderstood your intent. > > Quoting my PATCH v1 cover letter: > >> [Disassembler: Instruction is trimmed with 64-bits] >> >> In this section, we reuse the object file generated by the section above >> (two 22-byte instructions). >> >> 0000000000000000 <.text>: >> 0: 607f 0000 0000 0000 .byte 0x7f, 0x60, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 >> 8: 0000 0000 0000 0000 >> 10: 0000 0000 0000 >> 16: 607f 33cc 55aa cdef .byte 0x7f, 0x60, 0xcc, 0x33, 0xaa, 0x55, 0xef, 0xcd, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 >> 1e: 89ab 4567 0123 3210 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> 26: 7654 ba98 fedc zeroed out after first 64-bits >> >> See ".byte" at the address 0x16. It's trimmed at 64-bits. >> The resolution is simple. If we simply add a char* argument (containing all >> instruction bits), we can easily resolve this. >> >> 0000000000000000 <.text>: >> 0: 607f 0000 0000 0000 .byte 0x7f, 0x60, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 >> 8: 0000 0000 0000 0000 >> 10: 0000 0000 0000 >> 16: 607f 33cc 55aa cdef .byte 0x7f, 0x60, 0xcc, 0x33, 0xaa, 0x55, 0xef, 0xcd, 0xab, 0x89, 0x67, 0x45, 0x23, 0x01, 0x10, 0x32, 0x54, 0x76, 0x98, 0xba, 0xdc, 0xfe >> 1e: 89ab 4567 0123 3210 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> 26: 7654 ba98 fedc all instruction bits are correct > > At least, I want to test whether disassembly of this part (after first > 64-bits of an instruction) is fixed. That is exactly what's fixed in > PATCH 1/2 and I want to make sure that this part is changed correctly. Which you already achieve by the raw opcode output 607f 89ab 4567 0123 3210 7654 ba98 fedc 0000 0000 0000 The subsequent .byte[ ]+0x7f, 0x60, 0xab, 0x89, 0x67, 0x45, 0x23, 0x01, 0x10, 0x32, 0x54, 0x76, 0x98, 0xba, 0xdc, 0xfe, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 does not check anything the first part didn't already check. > If you change the output, you can freely remove or replace the testcase > according to the new output format but until that happens, I want to > keep those. What am I missing? I can only restate what I've said earlier: Testcases would imo better be supplying as strict as necessary but as relaxed as possible expectations. If it was truly the _intention_ for .byte (and not e.g. .2byte) to be used here, _then_ it would make sense to have this be part of the expectations. And then, by recording it that way, you also raise the barrier of someone changing the behavior - after all the testcase then says it is intended to be that way (rather than, as I assume here, it being merely "the way it is"). And yes, if you look at other testcase expectations you will frequently find way too strict expectations (often enough people simply take the output of the dumping tool, massage it suitably to be regex-es, and be done - sometimes with the effect of event recording outright wrong expectations, simply because huge output is cumbersome to check for correctness). In many cases this has resulted in unnecessarily big code churn when extending such testcases, or unhelpful mishmash because of people then always adding to the end instead of at a more sensible place (e.g. next to related stuff). Hence in particular for a still relatively new and tidy port like RISC-V is, it would seem desirable to me to learn from mistakes made elsewhere before. Yet to reiterate - I'm not going to insist, first and foremost because binutils, unlike other projects, has overall relatively relaxed acceptance criteria for patches. Jan