This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: objdump command to disassemble raw MIPS binary
- From: "A.W.C. via binutils" <binutils at sourceware dot org>
- To: "A.W.C." <bluestream at ymail dot com>, Nick Clifton <nickc at redhat dot com>
- Cc: <binutils at sourceware dot org>
- Date: Mon, 6 Aug 2018 11:23:25 +0000 (UTC)
- Subject: Re: objdump command to disassemble raw MIPS binary
- References: <236020270.2578979.1533554605574.ref@mail.yahoo.com>
- Reply-to: "A.W.C." <bluestream at ymail dot com>
- Reply-to: "A.W.C." <bluestream at ymail dot com>
Hi,
It turns out the problem is that files I have are not ELF binaries. The files are contents of memory regions of SPI Flash (in hex form), converted to binary form (.bin) use xxd -r. There is no .text section, only .data section. The 'file' command determines the file type of file.bin as 'data' file type.
Because it does not contain executable code; rather, it contains 'data'. As a result, when this data is treated as code and disassembled, this did not produce meaningful results.
So, question is how to convert the binary data file into a valid ELF executable?
Regards,
Alex
--------------------------------------------
On Mon, 8/6/18, Nick Clifton <nickc@redhat.com> wrote:
Subject: Re: objdump command to disassemble raw MIPS binary
To: "A.W.C." <bluestream@ymail.com>
Cc: binutils@sourceware.org
Date: Monday, August 6, 2018, 12:33 PM
Hi Alex,
> What additional switches can be used to
get disassembled output with more detalization?
> (for example, more easily to determine
memory location of a specific local variable)
Determining the location of a
local variable is actually quite hard as it could
live in several different locations (on the
stack, in a register, somewhere else
in
memory).
You could use the
disassembler to display the instructions involved and then
work
out for yourself where the variable
lives. Alternatively you could look at the
dwarf debug information which probably includes
details on the variable (although
it can be
rather hard to find). Or you could use gdb, which should
be able to
show you the contents, and
probably the location, of any variable you choose.
You might also find the
disassembler's --source option helpful. This
displays
the source code intermixed with the
disassembly, which can help you narrow down
where a variable is actually used.
Cheers
Nick