From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=roLM=5H=orcam.me.uk=macro@sourceware.org>
Received: from angie.orcam.me.uk (angie.orcam.me.uk [IPv6:2001:4190:8020::34])
	by sourceware.org (Postfix) with ESMTP id 609EB3858D33
	for <binutils@sourceware.org>; Tue, 10 Jan 2023 22:58:06 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 609EB3858D33
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 C5D719200B3; Tue, 10 Jan 2023 23:58:03 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
	by angie.orcam.me.uk (Postfix) with ESMTP id C273A92009E;
	Tue, 10 Jan 2023 22:58:03 +0000 (GMT)
Date: Tue, 10 Jan 2023 22:58:03 +0000 (GMT)
From: "Maciej W. Rozycki" <macro@orcam.me.uk>
To: Jan Beulich <jbeulich@suse.com>
cc: Andrew Waterman <andrew@sifive.com>, Jim Wilson <jim.wilson.gcc@gmail.com>, 
    nelson@rivosinc.com, Nick Clifton <nickc@redhat.com>, 
    binutils@sourceware.org, Palmer Dabbelt <palmer@dabbelt.com>
Subject: Re: [PATCH] gas/RISC-V: adjust assembler for opcode table
 re-ordering
In-Reply-To: <4a67f41c-3473-3833-c0fc-ed4f69a062e9@suse.com>
Message-ID: <alpine.DEB.2.21.2301102247420.65308@angie.orcam.me.uk>
References: <mhng-da78c63b-1a53-4a49-8adc-e0e97b9c9259@palmer-ri-x1c9a> <alpine.DEB.2.21.2301092144270.65308@angie.orcam.me.uk> <4a67f41c-3473-3833-c0fc-ed4f69a062e9@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: <binutils.sourceware.org>

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?

  Maciej