From: Doug Evans <dje@transmeta.com>
To: "J. Grant" <jg-lists@jguk.org>
Cc: binutils <binutils@sources.redhat.com>, cgen@sources.redhat.com
Subject: Decompilation
Date: Mon, 02 Dec 2002 10:27:00 -0000 [thread overview]
Message-ID: <15851.42465.790262.369771@casey.transmeta.com> (raw)
In-Reply-To: <3DE6AFF4.3010703@jguk.org>
J. Grant writes:
> I am currently working on some decompilation methods/ideas. I have been
> looking at the suitability of implementing using the GNU tools as a
> base. I realise this is a very complex process, so would like to ask
> peoples opinions before diving in and coding in all the wrong places.
>
> I would like to achive something similar to the way that gcc is the
> front end for compiling. For each of the stages below I would welcome
> sugested areas of binutils/GCC that I should focus my work on. I have
> been modifying objdump to produce the intermediate code. Clearly a lot
> of new code needs to be written to complete this work. If anyone has
> sugestions for the direction I should take this is welcome.
>
> Stage 1: Front end
> Input machine code binary
> Disassemble
> Abstract intermediate code generation
> Intermediate code output
What if you used cgen for stage 1?
I've always wanted to add the rtl to the opcodes files of cgen (*1),
but haven't had a reason or impetus to.
With that (and some suitable cover/utility fns) I believe you could easily
go from binary to intermediate code (*2). Only for the targets that cgen
supports of course.
(*1): At some point I've been expecting binutils to want to boot cgen
out of libopcodes. I dunno. But I've always wanted to create libcgen too.
There's a lot more ISA utilities that can be provided with cgen and should
be made available in the form of a library, but whether they belong in
libopcodes and shipped with binutils is certainly debatable.
(*2): pedantic: insert all the usual caveats of determining what's code
and what's data.
> Stage 2: Universal decompilation machine (UDM)
> CFG generation
> CFG analysis
> Data Format analysis
>
> Stage 3: Backend HLL target
> HLL constructs identified
> HLL output
next parent reply other threads:[~2002-12-02 18:27 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <3DE6AFF4.3010703@jguk.org>
2002-12-02 10:27 ` Doug Evans [this message]
2002-12-04 16:12 ` Decompilation J. Grant
2002-12-04 16:27 ` Decompilation Ben Elliston
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=15851.42465.790262.369771@casey.transmeta.com \
--to=dje@transmeta.com \
--cc=binutils@sources.redhat.com \
--cc=cgen@sources.redhat.com \
--cc=jg-lists@jguk.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).