From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR03-AM7-obe.outbound.protection.outlook.com (mail-am7eur03on2042.outbound.protection.outlook.com [40.107.105.42]) by sourceware.org (Postfix) with ESMTPS id 73572385B800 for ; Wed, 11 Jan 2023 09:28:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 73572385B800 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=d3/8zKuWGNQYTW0jOmlEqkUpnXoAcUC+2L8Edxlkizjq+isXB/FRP97owXaZ7/KbQZA8b/cmR5WICrpbkyzaUclHCfhkqQQJmTou57j4GAG6KkhdqdhETYSXsSt74fupCTMKIbtFiRfOflLJCgTqSmW9Rf2nBCjiOhMi4NVRDS79ADSdXHxD2jKH5JtjEKhkkBHUkTHPKfXDb+xcbkU0yOCR9DbuJpyc7XOCPGPDKbiXOISXZFnLQ8FtbeeoVNMNgr+f01ChiEe0l3NwJ0A91CfTwe/GwXk7c3udWSkmrtQQzrQZt6X+hYwdQ1enLssLVTMsGrkpRvrBFj96E7etEQ== 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=6siyiP+qATnc9v123l2g+RF3wPTqGLThi5lvQbk1K0U=; b=dhLuFlJsq1vkz16ABm7fTEl+IOBfVfvzQOuYJY75CbnMMv4TZruykjn7E7f4R1d/IuzOcKgJKOWKYW32AOyi/1uJ5H0qkf7tZNwY4KPCiyuh7KgejZzvhWBPqfvNZiiGLPFn1/QJPf9FcpBZX+SO2dZ6xEz6wBREHCiVsQQgnuNJyvi+RMP2Sz8cgNPYqfQetf25TapcC6Zki0FVAYqW1gOg1gYRbidAQFKMyuOCnRducLXYoNAPJjYuH19zCaYKUBKZzqgMWFyuSBpbwmYYcX5+/0BuzxxyU86Uu6FklhieIXWdYvpjeP0VZFiIzhRZkafsOtFlbuR1cNx5Xoto6w== 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=6siyiP+qATnc9v123l2g+RF3wPTqGLThi5lvQbk1K0U=; b=pPa6Mm/EXFJ55bDGAFAoJOOuDhTTKipa07SN2O74FaMY/UV1fE9NhTaZIsKiw3VxHeTIM5Very1KqCyZIG2Dexb3qvif7Nombl5SD5/URMRNATwcp/0Plp01NrPjmlIj9GU6blkPpmPnvehOjSKwqERzDawNmyNULvvo6T4o+Q/LH9tVopImVlFlwVlJTq4YVCksdwv8oPU8/+1Npr6F7d9gMEg2jGLvBuKHRi1fpNWqri5QuWKy22NylbeIo7fyH4TesXYDvqJCkKMk1XBBVSwpcdn9S//XHFnbElC/ZoCN6BWMoyKwtZSyn6N9Rh9xa3COg2SrjqSYqVFkOOpp3g== 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 PAXPR04MB9155.eurprd04.prod.outlook.com (2603:10a6:102:22e::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6002.12; Wed, 11 Jan 2023 09:28:55 +0000 Received: from VE1PR04MB6560.eurprd04.prod.outlook.com ([fe80::2991:58a4:e308:4389]) by VE1PR04MB6560.eurprd04.prod.outlook.com ([fe80::2991:58a4:e308:4389%7]) with mapi id 15.20.6002.012; Wed, 11 Jan 2023 09:28:54 +0000 Message-ID: Date: Wed, 11 Jan 2023 10:28:52 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Subject: Re: [PATCH] gas/RISC-V: adjust assembler for opcode table re-ordering Content-Language: en-US To: "Maciej W. Rozycki" Cc: Andrew Waterman , Jim Wilson , nelson@rivosinc.com, Nick Clifton , binutils@sourceware.org, Palmer Dabbelt References: <4a67f41c-3473-3833-c0fc-ed4f69a062e9@suse.com> From: Jan Beulich In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: FR2P281CA0024.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:14::11) To VE1PR04MB6560.eurprd04.prod.outlook.com (2603:10a6:803:122::25) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: VE1PR04MB6560:EE_|PAXPR04MB9155:EE_ X-MS-Office365-Filtering-Correlation-Id: 8e947349-f193-42f9-3cb3-08daf3b64225 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 85XM24TbOJErpQzZA8jD69ovJCM50rkp2IFmzqOvOeFNN4za74JZUmvvkasLxO3Mg4UhdozYLBLNVbt4dgyRc1hbzqbwei5Edq+wCSG2hRoMy+aTFcsUcOJF8kjsb1yQhv+94yrqOB0WBivrLsQS1hHjAO86BHu5CD3Dc2CEiWm+5dCMbcYvO4WwSSpOW9LnPcLaoKRO+9RpBHgmbs0exeSPn1gwVpkDHgwwXInuRMjnpVM1oACqJ1F2c4iNICiUC69ftNLL1mPdMHLqOr6+UR3EX/vWey6jNxMCospEJi5ICnuOwhgW0dq5OxUwODGmJxcwgBTUa2tWyYjX+q+SnlmGd/lIws4G5GARls0HJ9ao/59vyR5sfrkKjx3AAHKQrm1uemgqCGmXJbpG3PPR90LEF8nsgS7MQM7eXrgRPYAGmVN8rFFg6QgsXo7nNGwLzS2iHZ3d+UJhh+YrUkxNebgw321SvGnYo2+KGKbTQL0h+5IDczBTA0Mw4p5jz/uG0WEszN/tk+FGUJkg0bmB4y9JqiU8pAOBzVzmNUfGGt0qh5RpSqTM8+/jNC4ZftisGdBtcv8x70xfrjaFALzH3pJPCSOS4t2jFrW6YZzF1oJ1zVFIkAwR096Hxe73PVzYfdzNEmWl9HqJKrxfDZa9Ry0H9k4z2Xf8vDjg3mG0FF5Bivw2/+ErnONWTWhKv+q/lJ5ElLuuFgBLTlLq09eJtWF2feLi5+RZ82tVrZnNr9Q= 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)(376002)(396003)(136003)(39860400002)(346002)(366004)(451199015)(6512007)(38100700002)(478600001)(36756003)(6486002)(53546011)(6506007)(86362001)(31696002)(186003)(26005)(41300700001)(5660300002)(66556008)(66476007)(66946007)(8676002)(6916009)(4326008)(8936002)(83380400001)(2616005)(316002)(54906003)(31686004)(66899015)(2906002)(43740500002)(45980500001);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?cDNRQk1hSnZmeVA1MkdjSjhqTzh1Y2dLa0ZySEpwbzh4T3JlVStrMmhPZ2Q2?= =?utf-8?B?dXhoSjZUa2VPZ2ZTMFBYYWhJTnhuc0JlMlVBY0kzMTl2Q0QzUWt6WWg3R2x2?= =?utf-8?B?OC9kZm13QUdZQ0xXME1uUlpEa2dwc2JMc2Zzd1hyRjFURTEvMU9Qbnlvdk94?= =?utf-8?B?dXJ0dTZ5bktYU3Z6QTcyMEkycCsxM1FLMVVET1Q1aWRScFBSMXZjRm9yblNl?= =?utf-8?B?MDNydUdVV1dhL1lJLzZWYUxwOG93cWVlZlpoUExraEh0RFVNYmlOV1pnVGE2?= =?utf-8?B?S29iVG0xa1ZMTEttMlhTeVRxUVA2em41M1RNUnlOM1AyaHVXd2hPc29FMDRM?= =?utf-8?B?aWZJaE1sMWx3U1UrNUtFRXJrNEpraHJlZmsvMkNFaTVTT2d1T3dFVmRxaWgx?= =?utf-8?B?clhLR1JXUjFmRktDd2JsMXo3eFRXVW8raEJjTzFlcnRoNWdUZW1HeTgrd3da?= =?utf-8?B?SGhrTHp0K0dTZml3WnRuK28yU2IwVnUyTUthVVI3OHJXVi9teEJTK1IyeFR5?= =?utf-8?B?SmdqYjkwejlpVkRBNXREZDYyZ1NDa1F4RFM1eWlpRGNUMUlMZVNBZXB2M0JF?= =?utf-8?B?cnZHaHBSN0psVlRwQjBsVk8zMHd3U0FzcnUrYWNkKzFhd1ZzWHdCYkhIMlcx?= =?utf-8?B?QWtrVTRpZVNaNFp0MkoxZW9uY1hkbE9WSXNKcUZMR0Q0d0ZrdVhaQ3Zva1VS?= =?utf-8?B?dWZFUGFsQSs1MTJJdzBkeHc0a05ZWGVtemxyb0Y2M3RFbkxPQVZjeStHOXZL?= =?utf-8?B?bmdkMzBEQ1B4dnJnMzMyd3NZQW5FakRuRjVITzVOOENWMlNjeTI0VjZqOEFL?= =?utf-8?B?RVlQdVc2WjlVcU1KVHFHSXk0WjFTK09OdjRHTjNGRjRRclNrcU1NMURjcmph?= =?utf-8?B?R21IazZCcXpIVzYrMnNrRFRvbXBISW01aENaSSt2eUFLYnluRi93ZDFleWhJ?= =?utf-8?B?bGcxeWYrYTFmM1JsYXE5SWNxZ1ZkUVdFV1JFbllRVmU1cFhQMVJqTzZoWkFR?= =?utf-8?B?dUVrZHpuSEFUczl4VUR1QWdXdXFwQUpRRFlScUlHUWdjUFNNT3ZPQnRSMkNx?= =?utf-8?B?dXNoelEwQVBSMkt3cGp2aGxobmIreHJydnI5dFpYL2s0K3l1NGZ1K1FBN1Y3?= =?utf-8?B?aC9EbHpVZUpOV2ZpRzZqeWhtWFFCU1RZdURFMWtjQ1lOV1R1S0V3dHdqMlAr?= =?utf-8?B?dzRxZWR6Uzk1ZXArYklrV2JHdFQyMTNVbWJwSWpvazRuUmVrYzl4dmlmT2dX?= =?utf-8?B?TDRxd3BsdzVLdXdFdmxLNEhMWUhWa2IvTE01enJzd0NLK05CZWFLOEEzbmZJ?= =?utf-8?B?RG1HSWRqMXg3Yk9uSWVndWwzV0tFd3NKU1JGRlBQcklZbHFwVE1hdGVGQWV0?= =?utf-8?B?V2NkU0pNOUwwVmVBN09WZk9UL0JLSEFuRWxSZnFaOFpwamI0dHloNTlRV2x1?= =?utf-8?B?V2k4YmNRemEvRlpMVStGSEJoTGZ1azJuendsMVh2TGlwa09ib3M0dW1kZE9y?= =?utf-8?B?QmxtU1lvNDRJVEQ5QkdBekJQcUxlYUhQQmd0Vm9UM05DZkt3R0lRUFZrUEp3?= =?utf-8?B?czE4cTVKZjRzaER3RExTSDJrQWI2a0kxa0Y3RFgydVIySnpjMjJ1M2VOeHRR?= =?utf-8?B?b1JVNU1zdkkyRUVzaVRxbWozNUgyZGRGTSsrZjZSdlBYRWR3b3l4NllQMnZF?= =?utf-8?B?b3RKdDduT21IT3ZTWTlLMFRJRzc4K090dWNKMVp5QlBqOVZkZW84Mk5BVGZ6?= =?utf-8?B?ZklHeUh4ZmxXcjArUzQvWXA5QXBENmppZ1U0K2UyRDNBR2ZDNmlKbWxRdlVr?= =?utf-8?B?OHJiY0RCRy9SQTEwOXNCVG1nZm1SUkpvTjZlWU9MdlcxRm81ak5hM2pHdncw?= =?utf-8?B?a3RlcDlxKzM4dUZYb3hMZURCa2V3eGMrMk9od1dkR2VqOEtKdUozQzZHWUtY?= =?utf-8?B?S213TjhrV1Rpcm5EUGFvaGRwQ0cxRklVR0Y3VGRTcktDRU00K1ZLZkNJN3Rw?= =?utf-8?B?K2RER0N2T09kOGNGd3hiRnY5V05QWDYybkJXTU5ZRDFWTTczd3orV1d4b05v?= =?utf-8?B?TmpEdHdBWGV4N3krcVp2SE9pMy9LZlVsZmp0UFZLYTUzVzlzVjZqSkphM3JY?= =?utf-8?Q?oVPEw7NINiKW2mt6nNhmsH3xB?= X-OriginatorOrg: suse.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8e947349-f193-42f9-3cb3-08daf3b64225 X-MS-Exchange-CrossTenant-AuthSource: VE1PR04MB6560.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Jan 2023 09:28:54.8180 (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: 9WY5RWx5sWp4YP+FJtV3z9KoMkT+dxW+LmJPemEfUoi+Rx3YLtEEqCdIAretACnnFlO47nPy5LjEYPyi8QI6kA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAXPR04MB9155 X-Spam-Status: No, score=-3028.7 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 10.01.2023 23:58, Maciej W. Rozycki wrote: > On Tue, 10 Jan 2023, Jan Beulich wrote: > >>>> Thanks for fixing this. I don't have any issues with what's there, but looks >>>> like I'm also getting some failures (glibc/multilib errno related stuff). I'm >>>> trying to bisect those so I can't really get a proper test up now, I'll try to >>>> do so ASAP as it's really late to have stuff broken. >>> >>> I wonder why the RISC-V port needs such a hack while the MIPS one >>> doesn't. >> >> Perhaps I misunderstood your earlier reply then. There you said you deal with >> this by carefully ordering the opcode table. Here restoring the original order >> would only be a temporary workaround, as it would re-introduce the >> disassembler issue that was fixed by altering the order: Alias entries need to >> come ahead of "real" ones, or else respective alias mnemonics would never be >> emitted by the disassembler. > > Correct. But why does it require such an intervention on the GAS side? > > AFAIK similarly to the MIPS port and like the disassembler GAS tries to > match instructions in the order they appear in the opcode table, except > that the disassembler matches by the opcode/mask, but GAS matches by the > mnemonic/operands. It is expected that a single-operand alias appears > first so that the disassembler matches it first (unless `-M no-aliases'), > but it is also expected not to match a two-operand assembly instruction, > so that GAS proceeds to the next candidate opcode table entry. > > And it does appear to happen, because correct machine code is produced > regardless of your hack, except for the spurious symbol produced. So is > it not the case that simply the state (interal relocations recorded) is > not correctly reset on an unsuccessful operand match? Why does it have to > be special-cased just for the `a' operand type? The parsing of an 'a' type operand involves expression(), a side effect of which is to insert a symbol table entry for symbols not otherwise recognized (and note how my_getSmallExpression() addresses the same issue by filtering out GPR names first [1]). Yes, in a way this is an "insufficient undoing" issue, just that undoing of that symbol table insertion would be quite hard and/or fragile (from all I can tell). And this is where the dual meaning of symbol names comes into play: This looks to be intentional, and hence we can't make use of md_parse_name() to suppress the symbol table insertion in the first place for symbols which (in other contexts) identify registers. As to "just" - the issue could in principle happen elsewhere as well (beyond what my_getSmallExpression() accounts for at present), but luckily (so far) it doesn't. Hence I thought it would be best to keep things isolated to 'a'. As suggested in a post-commit-message remark, another workaround might be to count actual and expected operands first, and skip right to the next table entry when the two numbers don't match. I didn't go this route because I have no insight into possible future plans as to operands which might themselves contain commas (see e.g. Arm or x86 AT&T syntax for examples of such), at which point counting actuals would become more complicated than just counting commas. Jan [1] As stated elsewhere, I think this is wrong, as I expect it breaks certain use cases of, in particular, equates. But correcting it would require finding another solution to the symbol table insertion issue.