This is the mail archive of the
mailing list for the binutils project.
Re: objdump of binary for micromips.
- From: Kenneth Johansson <kenneth dot johansson at inteno dot se>
- To: "Maciej W. Rozycki" <macro at imgtec dot com>
- Cc: <binutils at sourceware dot org>
- Date: Wed, 11 Jan 2017 20:22:11 +0100
- Subject: Re: objdump of binary for micromips.
- Authentication-results: sourceware.org; auth=none
- References: <email@example.com> <20161223175720.GL9608@vapier.lan> <firstname.lastname@example.org> <alpine.DEB.email@example.com>
On 2017-01-11 19:55, Maciej W. Rozycki wrote:
On Tue, 27 Dec 2016, Kenneth Johansson wrote:
you specified the arch as mips, so you'll get mips32. if you run
`objdump -h`, you'll see a huge list of other arch values. you
probably want to use something like "mips:micromips".
tanks I did not understand the syntax but it did still not work out. the
lauterbach trace32 debug understands the code but objdump gets confused.
The `-M mips:micromips' option is only really there for binaries with no
symbol information available, so that you can manually choose the correct
disassembly mode, e.g. for the binary or SREC BFD. If the binary you
examine does have symbol information, then the ISA mode will be determined
on a function by function basis according to ISA annotation recorded with
individual symbols in the symbol table, ignoring any `-M mips:micromips'
(or `-M mips:16') override. So either your code is really made of regular
MIPS instructions or you have got symbol annotation wrong in your binary
-- which sometimes happens in handcoded assembly that hasn't been written
correctly (GCC is supposed to get it right for generated code).
If you think the binary has been or should have been annotated correctly
and believe this is a toolchain bug, then please provide us with a test
case and we will investigate.
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
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.
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.