Re: Help on disassembler/decompilers

hankd@dynamo.ecn.purdue.edu (Hank Dietz)
Sun, 9 Sep 90 17:38:57 -0500

          From comp.compilers

Related articles
Help on disassembler/decompilers wwho@ucdavis.edu (1990-09-06)
Re: Help on disassembler/decompilers hrubin@l.cc.purdue.edu (1990-09-07)
Re: Help on disassembler/decompilers pardo@cs.washington.edu (1990-09-07)
Re: Help on disassembler/decompilers raul@sdnp1.ucsd.edu (1990-09-07)
Re: Help on disassembler/decompilers seanf@sco.COM (1990-09-09)
Re: Help on disassembler/decompilers rwallace@vax1.tcd.ie (1990-09-09)
Re: Help on disassembler/decompilers vu0310@bingvaxu.cc.binghamton.edu.cc.binghamton.ed (1990-09-10)
Re: Help on disassembler/decompilers hankd@dynamo.ecn.purdue.edu (1990-09-09)
Re: Help on disassembler/decompilers Chuck.Phillips@FtCollins.NCR.COM (1990-09-10)
Re: Help on disassembler/decompilers adamsf@turing.cs.rpi.edu (1990-09-10)
Re: Help on disassembler/decompilers harrison@necssd.NEC.COM (1990-09-11)
Re: Help on disassembler/decompilers freek@fwi.uva.nl (1990-09-12)
Re: Help on disassembler/decompilers dik@cwi.nl (1990-09-10)
Re: Help on disassembler/decompilers markh@csd4.csd.uwm.edu (Mark William Hopkins) (1990-09-10)
[15 later articles]
| List of all articles for this month |

Newsgroups: comp.compilers,comp.lang.c,comp.unix.wizards
From: hankd@dynamo.ecn.purdue.edu (Hank Dietz)
In-Reply-To: <HOW.90Sep5173755@sundrops.ucdavis.edu>
Keywords: assembler, debug
Organization: Purdue University Engineering Computer Network
Date: Sun, 9 Sep 90 17:38:57 -0500

In article <HOW.90Sep5173755@sundrops.ucdavis.edu> you write:
> I am looking for any information related to disassembling
>object code into assembly langauge or even higher-level language such
>as C. Would someone please give me pointers to program sources,
>documentation or papers related to this?


Basic disassembly is trivial, particularly if you have an object
module with a name list. The interesting problems are:


[1] Determining which portions of a raw memory image are
code and which are data. Typically, this is done by
providing a set of code entry points and having the
disassembler trace program flow marking each word with
type information as each flow path is followed.


[2] Dealing with self-modifying code. At least the
technique of [1] can detect when this might happen....
I don't know of any reasonable way to deal with it.


Notice that indirect jump tables are particularly difficult to flow
trace (see [1]), as are techniques which use a Call instruction but
follow the instruction with the argument values (raw data) and tweak
the return address appropriately (as in some threaded interpreters).
Notice that knowing that the code image came from a particular
compiler can make these problems much easier to deal with, since you
can simply recognize the compiler's code generation idiom.


-hankd@ecn.purdue.edu


PS: Back around 1981-2 I did a flow analyzing disassembler for several
        then-popular microprocessors (e.g., 8080). I still have it, but
        it really isn't very impressive... especially when it hits some of
        those problem cases noted above (e.g., PCHL).
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.