This is my first post and I don't know if it will end up in the correct forum, but is there any chance that FASMARM will ever support disassembly ?

Thanks

fasmarm is an assembler. A disassembler would be a different program.

I was just hoping...

I have written assemblers for several 8 bit processors and the Data General Nova 2 minicomputer and made them all capable of disassembling an executeable. It was only about 10% more effort. In fact, I normally started with disassembly.

I'm about 80% thru writing an ARMv7 disassembler and ready to blow my brains out.
The 32 bit thumb extensions are a nightmare. (IMO) To preserve my sanity I'm now looking for an ARM Assembly/Disassembly pair that doesn't require me to reconfigure my life around Nix. Or use Windows. The problems of an old fart...

Thanks anyway and serious best regards, what you have done is awesome.

Hello caverage, nice to see you at FASMARM forum.

I have encountered a problem with disassembling a Motorola 68's binary.

How is your disassembler going to recognize whether information is data or 16 or 32 bit instruction?

If you use the DWARF format there are records that specify which mode each code section was assembled with. Debuggers and disassemblers can use this to display the correct code. There are four identifiers:

Hello malpolud, my disassemblers are simple, multi-pass, get the job done the fastest way with human intervention between passes.
The first pass assumes the first word (or byte) encountered is code unless told otherwise. Subsequent passes allow you to specify data and/or blank sections after viewing the initial output and making some guesses. Everything I have done so far has been for single address buss architectures. (Von Neumann or Princeton)
I'm going to cross the Harvard bridge when (and if) I get to it.
Re: 16 or 32 bit code, that information is in the code if you read it like the target processor reads it.

Which "68"? xx or 000?

What do you mean by this? Using a VM to follow execution? You would need to enumerate all possible input states and internal states to ensure you touch each piece of code. It would be an NP class problem and probably unsolvable in the general sense. There are many code constructs to switch modes that an automated process could easily miss or make errors. Without any other information (like the DWARF records) I think the human intervention would still be the most reliable.

The target processor needs (and has) no clues from DWARF records to decide what is code and what is data, all it needs is a properly constructed binary loaded in the proper location(s).
Life can be simpler for the user of one particular processor than it is for the author of a general tool...

Well, maybe I was a bit too quick. I agree that eventually human intervention may be required unless the disassembler tracks every possible path, around every obscure construct that a compiler may make, and that is NOT likely to happen with a simple disassembler.
So in reality, with something like ARMv7, disassembly would probably proceed a very short distance before emitting nonsense.

I actually don't remember what kind of processor was that.

Disassembling is quite a hard issue. If you try to disassemble an object file with debug information than the case seems to be easy.

But it only does seem. Following instructions with a VM is a good idea, but some pieces of code can't be analyzed that way so easy. For example some exception handling code. You don't have information about the processor state during code execution - some pieces of the code require many different conditions to be met, so they could be executed properly. If some of the instructions won't be executed by the VM, will the disassembler assume that these instructions are data? If some data will seem to be identical as some opcodes will the disassembler assume that these are instructions?

Disassembling a raw binary is even harder: First of all, you need an exact information about the target processor architecture. Secondly some data regions like uninitialized variables can be not attached to the binary file. The disassembler would have to assume data tables on the basis of addresses used in code. Some structural data types like unions could cause some difficulties not to mention unaligned data.

These are some problems I encountered while trying to disassemble.
Having a good disassembler for ARM would be a great thing - hope you can make it.

call it the way you like, VM disassembler or so, what we need is a different
layout of the whole. the VM may fail too if the format is not recognized
as being those from above in revolution's post.

i am still doing homeworks, but here is what it seems to me,
essntially too much layouts!

1) i start openOCD. it connects to te devboard and serves something back
2) GDB started a well known local executable and connect remotely to OpenOCD.
3) flash/download/debug start

now, i find generally ok the remote connection layout.
what i dislike is:

a) openOCD must be started locally (to the devboard)
b) GDB must be compiled for that CPU (arm-none-eabi) in every case
c) GDB connects remotely to A) and flashes/debug etc


the "arm commands" on openOCD and the "disas" on GDB
are the counterproof of some general design redundancy (but not
on account of the single software layout) we should face now.

personally i would like to have a remote server as it is already with openOCD.
this server is but a debugger too; because if i connect it to a devboard, it means
i know that devboard already!! also it acts alike a VM will do.

i compile locally using fasmarm/asmarm,
i start/flash/activate debugging locally using a telnet.
this avoids one stage, whether i develop it or i debug it.
well, i wonder whether doable or not.

i dont know what you are just using for debugger/disassembler now, but
i am sure of those points:

1) i will not learn C/C++ for that.
2) all of software in this list http://www.onarm.com/tool/debugger/ are commercial
or worst than all with GDB inside (+eclipse bleahhh !!!)
i will not use none of them !!!

disassembly is trivial, because it applies to a well know ISA.
considering the AMv7 ISA a particular application of the "Unknown",
the old dear song loops again one more time.

debugging is another matter. and it is worth concentrating on it,imho.
starting from a well known pluggable-ISA for that CPU, just as you
will do by openOCD when attaching using a board/interface option.

this would be a lot of work,i know.
but continuing that way developing has something masochistic in it,
isnt it ?

Cheers,

Disassembly of pure ARM-only code is mostly easy. You might get some data spat out as code, or code spat out as data, but the alignment will likely not be an issue.

Disassembly of pure THUMB-only code can be tricky. Occasional misaligned disassembly is possible.

Disassembly of mixed ARM/THUMB code is hard. Without the code type records to help you then lots of things can go wrong. If your code uses a regular and predictable style to change modes back and forth then it might be possible to make a special disassembler that can detect the transitions automatically.

simple debugging clip+musik using SWD on STM32F4 homework discovery,
i have built a little flasher for it to familiarize with the hardware.
enjoy it at HD quality !

Cheers,
and Happy new Year


http://www.youtube.com/watch?v=oJMX1maAPmk

hallo,
i deleted my last post because i was doing things more
difficoult as they are. i set now again the interesting link i provided in that post about the I/D cache of Cached-ARM processors
http://blogs.arm.com/software-enablement/141-caches-and-self-modifying-code/
(this should be perfectly doable on my Cortex-M4 on STM32F4discovery too)
it may be of some interest for others too.

ok, the ARMv7 macrocells and trace units are very clear
and straightforward. i am totally fascinated from their
power and linearity.
any debugger should be capable to manage all those hw-units to achieve
a full features-capability (as described in the ARMv7 manual).

in the clip+musik that follows i have encoded manually a patch
to allow the pushablinky application run.

note that i use OpenOCD but i have avoide GDB !!!

on the other side, i was right about OpenOCD and its main
connection concept (i work actually only on the USB stack
without serving telnet connections).
if you read here,
http://sourceforge.net/p/openocd/code/ci/928289773cc3399a8024bc83c7a6ba330676761c/tree/src/target/arm_disassembler.c

they may have had some reasons to make OpenOCD "dirty"...
...by interfacing it with the GDB features.

because GDB is for people uncapable to read assembly
also, you can delete GDB and start learning ARM.
because ARMv7 is a machine. it's hardware.stop.

i like OpenOcd! and that code above is a very good starting
point to ARM debugging/disassembling.

note: the music is very solar and fascinating.it recalls me
my old dear college times when i was there with a couple of famous hackers
of this world all night long to assist them...
and i was a baby and i couldn ever have thought that one day i would have been there hacking hardware ARM...

enjoy it at HD quality...
http://www.youtube.com/watch?v=jzGWfs1MSVg

Cheers,