From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60059.outbound.protection.outlook.com [40.107.6.59]) by sourceware.org (Postfix) with ESMTPS id C81BD385B189 for ; Fri, 25 Nov 2022 09:56:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C81BD385B189 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=RVdAta5qpPj2ykCvNHoohu4LTAhIMr6sBQOkSmn4Nz3azJZqhJON2buZxkDEGaQY9vLlY4RB/mTd7VXgqoKmgxOkLJWgCJLNnHl9atNhAdUJg1OexR02RMNv/sMIqvfsPdeeO5H9N02bpLuu+YzkViJnwicvemPZc4+j0framfcPOsAp8OuihgKtJfu/8nA0Ob07J4JxidDa7z42AFFRgfeFFLEsl7g9/m25kDZbfpjpSC4Weww+l1J05Kf0orAbmKpwfGvwEcD4UwA4FjrRt+hnRodDa+4lG8X9BCgSIf0DyZt3cNKMmhZkSjIZeJTacfQ73wvZ++VOen1fVq+2MA== 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=0n5xfQx6x6CtZRRsIpUj8e4QgboMbJHiOR5Y9jTcZtg=; b=S92ElQyikSvfGK+KYbAMpsjPk3nEHVSh/m4XA+6yQCiyoLDr/0Fnv74pPlNlHLW5qtajMGn5Jbw8so1+8TmEHdtTYmFaSCxeYlOYwLf5CBjpYlePAYTh6rCFJtPWTLbG/WDgSLopQDK5hMJRjBOzHyGI6Gcgr1PREXXD6jH6Y3pgtHUBxSOsZhy0GasgDzTYknWLbcFTPKuicGJxEcHspl2GYUNszJ471cu0uRQcNV1LliRM1eD9/W2wHkykGgOLvLlRCOcnEGV0syIJ3kWJJ2RXKBBIk8ecHbkb3JxlSTZ7MZbvEU2Ov/RxYGu0nkhD5e262gGBdysjzVXXya8olg== 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=0n5xfQx6x6CtZRRsIpUj8e4QgboMbJHiOR5Y9jTcZtg=; b=GlPZMXy6V8wljZR0i779VfPBjCrU29Bp0pf190hRyvp5n3x1QEELumG8Y0skP7Lc9yVwonG0JA1b2H95qV4CvDakWx6JwNlzgMgDW7H6NQaDVEdpnFOqbtcCdXQk/vmzmbo8pb6PdcNteKjw0wZNtjU308HOlZhuaYuUt94s532ld6uc2+flV8wgTTxPfzzhXcHc/ovz0BgLqCjn5lyrQ5HznIybJ2i3JWunacNV1RhZWR2Kqn15Wwb9eDgWE8QWd0TD8oWNkV0M1yd61aE5r6jrNh3weYqaSFg+W+2VigQ6zkDMA6P3/fhJDRf/XI5XDLTm31K72i404QqB+4MUdA== 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 AS8PR04MB8385.eurprd04.prod.outlook.com (2603:10a6:20b:3f3::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5857.20; Fri, 25 Nov 2022 09:56:27 +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:56:27 +0000 Message-ID: <21f73985-0cfb-7e0e-522f-7ff0cbd5b5ab@suse.com> Date: Fri, 25 Nov 2022 10:56:26 +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> <766c70f2-0b34-7c43-4d88-082740e598f1@suse.com> <73fa81b0-afd7-e90e-57c1-8e32f8326002@irq.a4lg.com> From: Jan Beulich In-Reply-To: <73fa81b0-afd7-e90e-57c1-8e32f8326002@irq.a4lg.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: FR0P281CA0078.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:1e::17) To VE1PR04MB6560.eurprd04.prod.outlook.com (2603:10a6:803:122::25) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: VE1PR04MB6560:EE_|AS8PR04MB8385:EE_ X-MS-Office365-Filtering-Correlation-Id: 77e1181b-dfb6-4016-20e5-08dacecb51ef X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Pxu8bjEUuHAxK/CDakG49k4sEmpyLCxHEyPeQWVZZ+DFg+HA2GzZwHj/RYdiRwXydz5UnWrseIZ4kNDilPjHUAL66mBgF+UDSCi0md0gSn5GiFs/PQougUzJN/HnPOn4qZwDAhDV43ncJh0YElWxVkOuVPksg/FG/hftY2k7iXQcuvlb81Sq1b9exQWjzUrCc5IPXuAzqWRNIlv8hhE9Kc5MvrxZzPZJyZmhqVQsVRHV5a7+UT1KuofE8Zz96RkPHo7fER4swS8RCGCS04pdGmOWeUcEhoPhnY/pfMTTfGdtJHQPNng+FnU7UPJyQvrTqv6a8+x2Av+Zv6iDdnaCVzHQW/NOOkN+7nRY7GCRame/5MjA6i137FIRebl8mTGfJFEmDMCMpaV2QmEzlyAGNdsd4KpJiRw4vRmnxV07tvShwCLAY/rymuiX1e5EFKc8mROJ2QQAWGbLwT1hPiNGPvb0A8cYmP5YqEE7LlpcHX+JHjxhJYxsc2WWtjPVZni5VAsB9XSDHxKLJVDaLFGKaos1LuDUAeNtbyvxePukCH/f0AINMS1uuHnL63yZ5FjZ6KpenJS5qVyjtf/SZWnYQkuKxZw+hfVdVSf8iO/am22+92t0o7PCplNWVyvaUNXRianlBXDvhGe0HIa6IX8fljxpY0x5YyP8FAn3/fxmdK9SvCRVEhVKK7R68HlgYmqH8CciPw8ABMXZZaRD/M7jsTznvgemQskj/EkrgM2LAv51cULTn+ujCLZUnpNIBqWz 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)(136003)(366004)(376002)(39860400002)(346002)(396003)(451199015)(6486002)(83380400001)(2906002)(31686004)(478600001)(6506007)(53546011)(38100700002)(36756003)(316002)(6916009)(26005)(8676002)(66556008)(4326008)(66946007)(6512007)(66476007)(41300700001)(86362001)(5660300002)(31696002)(186003)(2616005)(8936002)(45980500001)(43740500002)(376954003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?dHphYUZqaTRnNnlxbERobmFRRjBqZDNFd3krdUVZcG1CVU9tTFlGVmN2STJ1?= =?utf-8?B?aktyejVmVWwvMCtOTXQ1UFp2Tit4U09ZNUlCa0pCaG92YUUwUXFpTW1IZEZ5?= =?utf-8?B?QVpMTUJzMmk5blU4RWlSTXIyOHJIQ0dqeHRwZzNoSU5VUm9uSjJ0YVcvWjVo?= =?utf-8?B?anJybEJ5d1NoWXlyM3lvakl1YzhzQVVWRGx1NlZvcDJnbUVDR3lHTDkydjBY?= =?utf-8?B?cXJmNmFudmladG1KNXFiclZZcGRCMTJ4aWdlNXMxNGJmbkl3ZHg4c1NuaHEz?= =?utf-8?B?QWtuNEpibHlIc1NnOFB6dWNlWjNpSmhXOGJFZ1crODU1SVBxcmlhVEN5YTZm?= =?utf-8?B?M0Nic3hsd3JkbU1zazVUN0YvRFBiL1YxVk8zaVJvbVNUczBrY0NWRE55aGNR?= =?utf-8?B?Ymd1cU1INTdYcGNwWVpMaTRxRzltbFlvbythc09hYTBmMnAxRm1xbXBwYjRQ?= =?utf-8?B?eW9qTUg5UEJJSWxUVWExNjQzYkFrTHM5SE5oaXAzTEJlY0NzZ2QzRGVkY0Jt?= =?utf-8?B?UnFxZVF0bllkenhZZUZ6SGUrV3ZtTGM4aWVpYXBGYTdYNE5Qa2l0eWJycDBw?= =?utf-8?B?RjcrUURtRXZLVHpQb1FMditqemQvMFNxNjM4dWJHZFl4ZXd4bmlNOHI1K2VD?= =?utf-8?B?YWZINEtVeFVvb0FLTmhwWWN4aXlucTVlWlRUME94Y2NENGlBQnB6a2ZtQ1BR?= =?utf-8?B?T0FBZjRQSVlHeHh5UzIremYzT2FCZUwvcG5rQlRWUHBHR0dIUGlHZHQ4SWc2?= =?utf-8?B?SkEvelZMd0NodktKa2dqOWVLNjIrT3RkRmtPeEx6ZGNtNnkxT0NvVVdTR3B5?= =?utf-8?B?ck5pMVQ5UGNGK29HRUdQem5PS3NNc3l0VFdkL1JlK0txUFVYRWRlZTJKd2xi?= =?utf-8?B?SlFsMTcrczd1R2ZGRko3NFpjakw3V2pQeCtpNkFiQWFRVWp0TFUxcE4ySnk3?= =?utf-8?B?ZVoybDFJVTFYcDlHM2N2U25wazYyR1pNSEZGV0l4ZzNUNUZoOURDSUltaFZ6?= =?utf-8?B?eVp2NzRpNkFvZGtUVk50Q0d3UnRMbnFFRXU1UFoxUmpVRGlpckVtOFRNNUk1?= =?utf-8?B?dE5xNXB5YWxmUXAvbW41b3h6RkRoOXBVTTUySVYzQ1h4V1BDL2ZRcFNsTG9a?= =?utf-8?B?Unh6RFh5cjNOdTBDRXVLcm81dlBBUjlhQWdXN3VOYUhSbzhtNG90bng1K2Jr?= =?utf-8?B?Nm5jc3JobDBIeHBVRTNqak84RzM5WnEvN0hUS3Z1ZkpkZVNRUHFiTXZmZVN6?= =?utf-8?B?T0J4bERZVzFCWHdhV3pBTFU3cDg4T252QTZjMytiYkNTcmY3RFUxZ004TXVh?= =?utf-8?B?aVdnY3lQSjNhd2graVRkOUhTSUp0dnBFTC8yK1Y2ZWc1OGw4UVc1dFV0OExT?= =?utf-8?B?RUpMaWZBNHowMmdrV2Q0VUdwR1lWbUUwdll3WExIVXNjc1pGc1hPamxrUUcy?= =?utf-8?B?cmNUdGtkUHczZWR4M0JTRzdEU295Z2lVY3lUTnY0S0U4aTBqM2djNllmUWZl?= =?utf-8?B?RFpZU0xWaXBmWTRBcHZDbk1hQkxiOXRteEJRblVaMEduZXNFY2I0NXBWclIy?= =?utf-8?B?TElSVmVtMm94YlhvN0ZXTWwwVVJSTUhmQVhBOCtwK1kxSkR4cTdhcDUxODhy?= =?utf-8?B?b3JqTlJYSmUrL1RaTHFrUnlSZFdjeUZpTGFsajlITStra1pDWmhwVXFYQzB0?= =?utf-8?B?YTl3NWkwZlFGVStxVFJYK0szYXQ2RTJLR2VJallCNjFzSFpyZ2lYVTU1QmNY?= =?utf-8?B?c2hNaFhPT3BqN0QvcWpaRUJMYUpkQVNleHNNNlV2YkltRXZQc0Q0WHEyOXlv?= =?utf-8?B?TjcrQ2lsd3FXcWNNNjZRTHM1c0JqemtkRWlLK3pRdXBxWGFuVDRZSHkvMm5U?= =?utf-8?B?Q2ZSQS83NTRGVXoyc1RkdUI1OSs4eVF5SXZnTUNFUXVnY3V0eGpmcVZlQzhC?= =?utf-8?B?Sm1hdzJOdkZtV1RETEpTRndzdnFUYTlzQTJqbzRPV2ZsOUZLcGNKbWozS3h1?= =?utf-8?B?Y3V0QnV0SnJPRW5SNzhBMEVxVWhYbEVHQm5kVWVwR2ZVNGJISnhvZCtGcnhC?= =?utf-8?B?TXBhTVRoSERVNlNsYWNkWmJGMUFqeFY0cGh4aVBESDhaamhKaG5qWU1ib0gr?= =?utf-8?Q?GgaeB3z1O/4106e6Yc3gmDb4a?= X-OriginatorOrg: suse.com X-MS-Exchange-CrossTenant-Network-Message-Id: 77e1181b-dfb6-4016-20e5-08dacecb51ef 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:56:27.5749 (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: JTD5OZCzzDrCaveH94EPCc0u6xTx3DzZ95mxF1aJoB63AQIBaHKLawAqn09qG24eNCooGHUSOOS/Tp+Klc+jIQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR04MB8385 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 10:18, Tsukasa OI wrote: > On 2022/11/25 18:04, Jan Beulich wrote: >> 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. > > That's simply not true. > > Again, quoting from PATCH v1 cover letter (BEFORE THE PATCH > [disassembler part]): > >> 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 > > Compare hexdump and printed bytes (in ".byte"). You can see that "1e: > 89ab..." are different from corresponding ".byte" (0x00, 0x00...). > They are completely separate and PATCH 1/2 only changes ".byte" output. > > If ".byte[ ]+0x7f, 0x60..." does not check anything the first part > didn't already check, the dump would look like this: > >> 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: 0000 0000 0000 0000 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> 26: 0000 0000 0000 zeroed out after first 64-bits (but matches to hexdump) > > If the hexdump and ".byte" output always matches EVEN BEFORE THE FIX, > that's what I can call "redundant". But in reality, they do not. > That's why I want to leave a test to make sure that the issue is fixed > (now hexdump and ".byte" output always matches). Oh, apologies: Disassembly then was wrong _only_ for the .byte part, but _not_ for the raw encoding? While indeed (going back) you said so in the original cover letter, the description of patch 1 doesn't make this clear. In that case, yes, I agree that the .byte part wants to be part of the expectations (but patch 1's description also wants adjusting). Jan