Path: utzoo!utgpu!watserv1!watmath!att!ima!esegue!compilers-sender From: seanf@sco.COM (Sean Fagan) Newsgroups: comp.compilers Subject: Re: Help on disassembler/decompilers Keywords: code, assembler, debug Message-ID: <1990Sep9.010032.23235@sco.COM> Date: 9 Sep 90 05:00:32 GMT References: <2900@network.ucsd.edu> Sender: compilers-sender@esegue.segue.boston.ma.us Reply-To: seanf@sco.COM (Sean Fagan) Organization: The Santa Cruz Operation, Inc. Lines: 30 Approved: compilers@esegue.segue.boston.ma.us In article <2900@network.ucsd.edu> raul@sdnp1.ucsd.edu (Raul Rathmann) writes: >Getting it from assembly to C was pretty difficult and was >mostly an intuitive operation. To make a program that automatically did >this would probably be a major undertaking and even then I don't think it >would be able to figure out certain things. As I've pointed out before, someone once wrote a decompiler for the VAX, which I've played with. It *knew* how PCC generated code, so, after "disassembling" (internal use only, generally; it didn't try to decompile assembly text, in other words), so it would structure the code generated from that. It's really not that difficult thing to do, if you don't have to deal with esoteric instructions and a smart compiler. Oh, yeah: it didn't use the symbol table, and the code it generated certainly had some, uhm, quirks. Variable names such as 'r0' through 'r15', for example (except for global variables, that is). Structure members were considered different variables (I once tried decompiling fork.o, for example; something like three quarters of the variables were offsets into the user structure, and I came up with a little chart that had the offsets (and sizes) of all the elements). Etc. But it did work. Thus borneth BSD Empire. -- Sean Eric Fagan, seanf@sco.COM, uunet!sco!seanf, (408) 458-1422 -- Send compilers articles to compilers@esegue.segue.boston.ma.us {ima | spdcc | world}!esegue. Meta-mail to compilers-request@esegue.