From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from angie.orcam.me.uk (angie.orcam.me.uk [78.133.224.34]) by sourceware.org (Postfix) with ESMTP id 9BFE73858D32 for ; Sun, 8 Jan 2023 16:05:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9BFE73858D32 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 A525C92009C; Sun, 8 Jan 2023 17:05:37 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by angie.orcam.me.uk (Postfix) with ESMTP id 971C792009B; Sun, 8 Jan 2023 16:05:37 +0000 (GMT) Date: Sun, 8 Jan 2023 16:05:37 +0000 (GMT) From: "Maciej W. Rozycki" To: Andrew Burgess cc: binutils@sourceware.org Subject: Re: [PATCH 1/2] opcodes/mips: use .word/.short for undefined instructions In-Reply-To: <87fscny5tr.fsf@redhat.com> Message-ID: References: <87fscny5tr.fsf@redhat.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=-1163.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 Fri, 6 Jan 2023, Andrew Burgess wrote: > > FYI, I find this questionable as `.word' (at least with the MIPS target) > > implies natural alignment while 32-bit microMIPS encodings, valid or not, > > are not. Also, given the endianness peculiarity (analogous to the MIPS16 > > extended encodings), I think this needs to be ".short\t0x%x, 0x%x" really, > > with the instruction word split into halfwords for any reasonable meaning. > > This is already reflected in the raw hex dump of instruction streams; the > > numbers printed need to match it. > > > > With the naked number previously used this obviously didn't matter as it > > stood out without any attempt to pretend to have a meaning. This is also > > the reason why I chose to keep it as it used to be since forever. > > Below is an initial patch. When I set the environment variable > DISABLE_MATCHING then the disassembler fails to match all instructions, > so prints .short for everything. > > Right now I can't find anything where this doesn't work, but I don't > believe that the answer is actually this simple. Given your deeper > knowledge of the target, could you take a look at what I have below and > point me at some tests/configurations/whatever where this isn't going to > be good enough? > > Alternatively, if this is enough, then I'll write this up into a proper > patch. Your change is probably right. I'd have thought we have coverage for this in the testsuite, but perhaps we don't. If you try this source code (which uses a reserved 32-bit encoding in the microMIPS ISA): .module micromips foo: .insn .short 0x7f6e, 0x5d4c and assemble it for both endiannesses (i.e. with `-EL' and `-EB' passed to GAS respectively), then I'd expect output like: Disassembly of section .text: 00000000 : 0: 7f6e 5d4c .short 0x7f6e, 0x5d4c ... from `objdump -d' in both cases. If this is the case, then the change is right. You can use this example, preferably along with the change itself, for a testcase to place in binutils/testsuite/binutils-all/mips/. I suggest using `run_dump_test_o32'/`run_dump_test_n32'/`run_dump_test_n64' all at a time just as with most of the preexisting test cases just to make sure all the three BFD backends involved handle this right. Let me know if you need further information. Maciej