public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: "Maciej W. Rozycki" <macro@orcam.me.uk>
To: Andrew Burgess <aburgess@redhat.com>
Cc: binutils@sourceware.org
Subject: Re: [PATCH 1/2] opcodes/mips: use .word/.short for undefined instructions
Date: Sun, 8 Jan 2023 16:05:37 +0000 (GMT)	[thread overview]
Message-ID: <alpine.DEB.2.21.2301081539290.2259@angie.orcam.me.uk> (raw)
In-Reply-To: <87fscny5tr.fsf@redhat.com>

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 <foo>:
   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

  reply	other threads:[~2023-01-08 16:05 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-03 13:58 [PATCH 0/2] MIPS disassembler styling Andrew Burgess
2022-11-03 13:58 ` [PATCH 1/2] opcodes/mips: use .word/.short for undefined instructions Andrew Burgess
2023-01-06 15:58   ` Maciej W. Rozycki
2023-01-06 16:40     ` Andrew Burgess
2023-01-08 16:05       ` Maciej W. Rozycki [this message]
2023-01-17 10:28         ` Andrew Burgess
2023-01-27 11:57           ` Maciej W. Rozycki
2023-01-30  9:34             ` Andrew Burgess
2023-02-01 10:40               ` Maciej W. Rozycki
2023-02-01 15:32                 ` Andrew Burgess
2023-02-02  9:48                   ` Maciej W. Rozycki
2023-02-03  9:31                 ` Andrew Burgess
2023-02-13 12:07                   ` Andrew Burgess
2023-02-14  4:43                     ` Maciej W. Rozycki
2022-11-03 13:58 ` [PATCH 2/2] libopcodes/mips: add support for disassembler styling Andrew Burgess
2022-11-28 17:15 ` [PATCH 0/2] MIPS " Andrew Burgess
2022-11-30 16:50   ` Nick Clifton
2022-12-05 10:08     ` Andrew Burgess

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.21.2301081539290.2259@angie.orcam.me.uk \
    --to=macro@orcam.me.uk \
    --cc=aburgess@redhat.com \
    --cc=binutils@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).