This is the mail archive of the
mailing list for the binutils project.
Re: objdump of binary for micromips.
- From: "Maciej W. Rozycki" <macro at imgtec dot com>
- To: Kenneth Johansson <kenneth dot johansson at inteno dot se>
- Cc: <binutils at sourceware dot org>
- Date: Wed, 11 Jan 2017 20:37:20 +0000
- Subject: Re: objdump of binary for micromips.
- Authentication-results: sourceware.org; auth=none
- References: <firstname.lastname@example.org> <20161223175720.GL9608@vapier.lan> <email@example.com> <alpine.DEB.firstname.lastname@example.org> <email@example.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
> 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)
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.