From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from angie.orcam.me.uk (angie.orcam.me.uk [IPv6:2001:4190:8020::34]) by sourceware.org (Postfix) with ESMTP id 9ACF83858D32 for ; Sun, 8 Jan 2023 13:53:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9ACF83858D32 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=orcam.me.uk Authentication-Results: sourceware.org; spf=none smtp.mailfrom=orcam.me.uk Received: by angie.orcam.me.uk (Postfix, from userid 500) id DF9C592009C; Sun, 8 Jan 2023 14:53:14 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by angie.orcam.me.uk (Postfix) with ESMTP id D89A492009B; Sun, 8 Jan 2023 13:53:14 +0000 (GMT) Date: Sun, 8 Jan 2023 13:53:14 +0000 (GMT) From: "Maciej W. Rozycki" To: Jan Beulich cc: binutils@sourceware.org Subject: Re: [PATCH] RISC-V: fix JAL aliases ordering in opcode table In-Reply-To: <9975504c-579e-48ee-751a-66c6b055a78c@suse.com> Message-ID: References: <20230104055936.1130680-1-aurelien@aurel32.net> <9975504c-579e-48ee-751a-66c6b055a78c@suse.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-3489.0 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,KAM_INFOUSMEBIZ,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=no 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 Thu, 5 Jan 2023, Jan Beulich via Binutils wrote: > >> I'm afraid reverting the "offending" hunk is only a workaround, as it > >> would re-introduce the disassembler side issue that the patch tried to > >> deal with (and which sadly looks to not be covered by anything in the > >> testsuite, or else you would have noticed breakage when testing your > >> change). Since I expect that in the course of table lookup it is still > >> the correct entry (in particular one with two rather than just one > >> operands) which is used, my suspicion is that something somewhere makes > >> a silent assumption upon the (original) ordering of table entries. It > >> would be that place which needs fixing then; I'll try to find time soon > >> to see if I can spot where that is. > > > > Thanks for the analysis. Do you think you have time to get a patch with > > that fix before the 2.40 release? > > I hope to get to looking into this tomorrow; whether that'll result in a > patch I obviously can't tell yet. In any event Nelson's reply (which > crossed with mine) suggests the reason for the problem to be different. > Yet then still that's where the change wants to be (albeit I disagree > with his proposal, yet that's without having looked at the code at all), > rather than re-introducing the disassembler inconsistency. The latter > would certainly be a short-term option for the impending release, if a > proper solution can't be found in time or turns out too intrusive. But > then the title and description would need adjustment to reflect this > (e.g. it wouldn't be "fix" but maybe "restore" or "undo"). FWIW we have taken a similar approach in the MIPS port, which I believe is where the RISC-V port took inspiration from, and by ordering the opcode table carefully we get the desired results; see the various `j*' and other instruction entries in opcodes/mips-opc.c. It has worked for some 30 years now, so it should be pretty straightforward to get this sorted here as well. Maciej