Re: objdump of binary for micromips.

["Maciej W. Rozycki" <macro at imgtec dot com>]

On Wed, 11 Jan 2017, Kenneth Johansson wrote:

> no this was from a binary blob so no symbols no nothing and turned out to be a
> mix of normal mips32 and mips16 and not micromips as I thought it was.
> 
> The only way I could read it was to disassemble only small parts at a time and
> then change the flags if it looked to strange.

 Indeed, I can imagine it can be tedious this way, but offhand I know of 
no better way readily available either.  You might want to experiment with 
`objcopy' and build an artificial symbol table using its `--add-symbol' 
option repeatedly while making an ELF file for the purpose of disassembly 
only, but you may not be able to set the ISA annotation with this option 
(I don't know the exact semantics of the `FLAGS' parameter and its 
description is lacking in the `objcopy' manual).

> But one thing I do think is a "bug" or at least a missing feature is that
> there seems to be no way to make loads and stores that is relative to a
> register display the offset in hex now it only uses decimal and that is very
> inconvenient.
> 
>  890372a:       f401 da88       sw      a0,3080(v0)
> 
> would have been much easier to read/grep if it would have been
>  890372a:       f401 da88       sw      a0,0xc08(v0)
> 
> as it happens that most(all) documentation for hardware uses hex numbers for
> hardware register addresses.

 I agree it can be troublesome sometimes, but it does make sense for the 
sake of negative offsets, which would otherwise have to be shown in the 
full address width, e.g.:

 890372a:	f411 da88 	sw	a0,-29688(v0)

vs:

 890372a:	f411 da88 	sw	a0,0xffffffffffff8c08(v0)

for the n64 ABI, causing readability issues.  We could have a disassembler 
option to switch to this format I suppose though, although implementation 
would not be as easy as it might seem offhand, as we'd have to have the 
immediate data width implied by the operand codes used in opcode tables 
separately for 32-bit ALU operations (e.g. ADDIU), 64-bit ALU operations 
(e.g. DADDIU) and ABI-dependent address calculations (e.g. LW).  Right now 
there's some overlap, e.g. ADDIU and DADDIU both use the same code for 
their immediate operand, so they cannot be told apart in disassembly.

 NB for regular MIPS and 32-bit microMIPS instruction encodings you can 
actually get the hex offset from the raw instruction dump.

  Maciej