From: "J. Grant" <jg-lists@jguk.org>
To: Doug Evans <dje@transmeta.com>
Cc: binutils <binutils@sources.redhat.com>, cgen@sources.redhat.com
Subject: Re: Decompilation
Date: Wed, 04 Dec 2002 16:12:00 -0000 [thread overview]
Message-ID: <3DEE9A45.5020709@jguk.org> (raw)
In-Reply-To: <15851.42465.790262.369771@casey.transmeta.com>
Doug Evans wrote:
> 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.
Thank you for the reply.
Having just checked cgen, I think it might be useful to use for this
purpose. It is a very interesting project.
Is the CPU description language complete? I have been working with
C--(http://cminusminus.org/) and modifying objdump currently. C-- seems
more of an intermediate code language than the cgen one (from reading
the docs). I am not sure of the exact organisation of GCC and binutils.
I notice the use of Scheme as the implementation language, I have been
leaning towards C for my research so far. Certainly for the first phase
it seems suitable IMO. I have not started on phase 2 or 3 yet (beyond
considerations of techniques).
> (*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.
Is there cgen Scheme source in binutils currently? I have not seen any
as part of the opcodes dir or other areas. Is it only available
separatly from the home page currently?
> (*2): pedantic: insert all the usual caveats of determining what's code
> and what's data.
This should be feasible on architectures that separate data & code in
different sections. Targets such as SH that I believe place const data
inline in .text would have to use some heuristics based on access of the
data I expect.
Comments or sugestions welcome
JG
next prev parent reply other threads:[~2002-12-05 0:12 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 ` Decompilation Doug Evans
2002-12-04 16:12 ` J. Grant [this message]
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=3DEE9A45.5020709@jguk.org \
--to=jg-lists@jguk.org \
--cc=binutils@sources.redhat.com \
--cc=cgen@sources.redhat.com \
--cc=dje@transmeta.com \
/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).