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 65B7D3858D28 for ; Fri, 6 Jan 2023 15:58:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 65B7D3858D28 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 48EF892009C; Fri, 6 Jan 2023 16:58:08 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by angie.orcam.me.uk (Postfix) with ESMTP id 41CAB92009B; Fri, 6 Jan 2023 15:58:08 +0000 (GMT) Date: Fri, 6 Jan 2023 15:58:08 +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: Message-ID: References: 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=-1169.0 required=5.0 tests=BAYES_00,GIT_PATCH_0,KAM_DMARC_STATUS,KAM_INFOUSMEBIZ,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_NONE,SPF_NONE,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: Hi Andrew, In the course of reviewing outstanding upstream mailing list traffic I came across this change of yours. On Thu, 3 Nov 2022, Andrew Burgess via Binutils wrote: > diff --git a/opcodes/mips-dis.c b/opcodes/mips-dis.c > index faeebccfc3b..1d9875f2bb0 100644 > --- a/opcodes/mips-dis.c > +++ b/opcodes/mips-dis.c > @@ -2515,7 +2515,10 @@ print_insn_micromips (bfd_vma memaddr, struct disassemble_info *info) > } > } > > - infprintf (is, "0x%x", insn); > + if (length == 2) > + infprintf (is, ".short\t0x%x", insn); > + else > + infprintf (is, ".word\t0x%x", insn); 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. FWIW, Maciej