Re: Help on disassembler/decompilers

Chuck.Phillips@FtCollins.NCR.COM (Chuck.Phillips)
10 Sep 90 13:04:01 GMT

          From comp.compilers

Related articles
[2 earlier articles]
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)
Re: Help on disassembler/decompilers Jonathan.Bowen@prg.oxford.ac.uk (Jonathan Bowen) (1990-09-13)
[14 later articles]
| List of all articles for this month |

Newsgroups: comp.compilers
From: Chuck.Phillips@FtCollins.NCR.COM (Chuck.Phillips)
Keywords: assembler, debug
Organization: NCR Microelectronics, Ft. Collins, CO
References: <HOW.90Sep5173755@sundrops.ucdavis.edu> <6839.26ea3b0e@vax1.tcd.ie>
Date: 10 Sep 90 13:04:01 GMT

>>>>> On 9 Sep 90 12:52:29 GMT, rwallace@vax1.tcd.ie said:
> There's no unique mapping from machine code to HLL and hence
> (unlike machine code to assembler) no simple algorithm (your
> algorithm might recognize something it thinks is a loop but is it
> a for loop, a while loop or just something hacked together with
> gotos?


Very true, but it doesn't matter whether it uses "for" or "while" loops or
a combination based on heuristics. (Turning a mess of "goto"s into "for"
or "while" loops sounds particularly attractive!) Recreating the original
code _exactly_ is overkill; it's the _algorithms_ one generally wants to
see. The more the decompiler is able to abstract "goto"s into "while"s,
"for"s, "do...while"s, etc. the better, even if it doesn't match the
original. Further heuristics could be used for combining conditionals to
avoid 3 "if"s when a single one would do, finding candidates for "switch"
statements, etc.


Best of all: Combined with an optimizing compiler, you get a kluge source
code optimizer, and at least open the possibility of porting optimizations
to a platform with a less effective optimizer. In some cases, it may even
make obvious new optimizations of the underlying algorithm. (Just the tool
to have around when optimizing highly time critical subroutines. ;-)


Structure offsets and stack variable names do present a particular problem,
which may be _partially_ overcome by reading the symbol table (if it
exists) and annotating accordingly. Patching your compiler to include
additional information in the object file or a side file can further the
possible abstraction.


In the the very worst case, you get to read cryptic C instead of cryptic
assembler.


Cheers,
--
Chuck Phillips MS440
NCR Microelectronics Chuck.Phillips%FtCollins.NCR.com
2001 Danfield Ct.
Ft. Collins, CO. 80525 uunet!ncrlnk!ncr-mpd!bach!chuckp
--


Post a followup to this message

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