* Decompilation
[not found] <3DE6AFF4.3010703@jguk.org>
@ 2002-12-02 10:27 ` Doug Evans
2002-12-04 16:12 ` Decompilation J. Grant
0 siblings, 1 reply; 3+ messages in thread
From: Doug Evans @ 2002-12-02 10:27 UTC (permalink / raw)
To: J. Grant; +Cc: binutils, cgen
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
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: Decompilation
2002-12-02 10:27 ` Decompilation Doug Evans
@ 2002-12-04 16:12 ` J. Grant
2002-12-04 16:27 ` Decompilation Ben Elliston
0 siblings, 1 reply; 3+ messages in thread
From: J. Grant @ 2002-12-04 16:12 UTC (permalink / raw)
To: Doug Evans; +Cc: binutils, cgen
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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2002-12-05 0:27 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <3DE6AFF4.3010703@jguk.org>
2002-12-02 10:27 ` Decompilation Doug Evans
2002-12-04 16:12 ` Decompilation J. Grant
2002-12-04 16:27 ` Decompilation Ben Elliston
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).