* objdump of binary for micromips.
@ 2016-12-23 12:24 Kenneth Johansson
2016-12-23 17:57 ` Mike Frysinger
0 siblings, 1 reply; 6+ messages in thread
From: Kenneth Johansson @ 2016-12-23 12:24 UTC (permalink / raw)
To: binutils
So I have a binary for mips that I want to investigate but the code is
compiled with micromips ISA and I cant fogure out a way to have objdump
understand that.
objdump -b binary -D -EL -m mips BLOB
do assume mips32 ISA.
is there any way to do this ?
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: objdump of binary for micromips.
2016-12-23 12:24 objdump of binary for micromips Kenneth Johansson
@ 2016-12-23 17:57 ` Mike Frysinger
2016-12-27 14:30 ` Kenneth Johansson
0 siblings, 1 reply; 6+ messages in thread
From: Mike Frysinger @ 2016-12-23 17:57 UTC (permalink / raw)
To: Kenneth Johansson; +Cc: binutils
[-- Attachment #1: Type: text/plain, Size: 491 bytes --]
On 23 Dec 2016 13:24, Kenneth Johansson wrote:
> So I have a binary for mips that I want to investigate but the code is
> compiled with micromips ISA and I cant fogure out a way to have objdump
> understand that.
>
> objdump -b binary -D -EL -m mips BLOB
>
> do assume mips32 ISA.
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".
-mike
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: objdump of binary for micromips.
2016-12-23 17:57 ` Mike Frysinger
@ 2016-12-27 14:30 ` Kenneth Johansson
2017-01-11 18:56 ` Maciej W. Rozycki
0 siblings, 1 reply; 6+ messages in thread
From: Kenneth Johansson @ 2016-12-27 14:30 UTC (permalink / raw)
To: binutils
On 2016-12-23 18:57, Mike Frysinger wrote:
> On 23 Dec 2016 13:24, Kenneth Johansson wrote:
>> So I have a binary for mips that I want to investigate but the code is
>> compiled with micromips ISA and I cant fogure out a way to have objdump
>> understand that.
>>
>> objdump -b binary -D -EL -m mips BLOB
>>
>> do assume mips32 ISA.
> 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".
> -mike
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: objdump of binary for micromips.
2016-12-27 14:30 ` Kenneth Johansson
@ 2017-01-11 18:56 ` Maciej W. Rozycki
2017-01-11 19:22 ` Kenneth Johansson
0 siblings, 1 reply; 6+ messages in thread
From: Maciej W. Rozycki @ 2017-01-11 18:56 UTC (permalink / raw)
To: Kenneth Johansson; +Cc: binutils
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".
> > -mike
>
> 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.
HTH,
Maciej
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: objdump of binary for micromips.
2017-01-11 18:56 ` Maciej W. Rozycki
@ 2017-01-11 19:22 ` Kenneth Johansson
2017-01-11 20:37 ` Maciej W. Rozycki
0 siblings, 1 reply; 6+ messages in thread
From: Kenneth Johansson @ 2017-01-11 19:22 UTC (permalink / raw)
To: Maciej W. Rozycki; +Cc: binutils
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".
>>> -mike
>> 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
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.
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: objdump of binary for micromips.
2017-01-11 19:22 ` Kenneth Johansson
@ 2017-01-11 20:37 ` Maciej W. Rozycki
0 siblings, 0 replies; 6+ messages in thread
From: Maciej W. Rozycki @ 2017-01-11 20:37 UTC (permalink / raw)
To: Kenneth Johansson; +Cc: binutils
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-01-11 20:37 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-12-23 12:24 objdump of binary for micromips Kenneth Johansson
2016-12-23 17:57 ` Mike Frysinger
2016-12-27 14:30 ` Kenneth Johansson
2017-01-11 18:56 ` Maciej W. Rozycki
2017-01-11 19:22 ` Kenneth Johansson
2017-01-11 20:37 ` Maciej W. Rozycki
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).