[Soot-list] How to reuse CFG framework without low-level byte
code.
Chris Pickett
chris.pickett at mail.mcgill.ca
Sat Jul 9 21:26:15 EDT 2005
Hi Pavel,
Maybe you should consider trying to convert from your AST to Soot's
representation of Java classes, with method bodies written in the Jimple
intermediate representation (IR). From there, Soot will generate
bytecode for you.
You don't need to go through bytecode to create Jimple... it's just that
when Soot is analysing *existing* classfiles, it must parse the bytecode
somehow to create a Jimple representation that is suitable for analysis.
The Soot tutorials should also clear some things up:
http://www.sable.mcgill.ca/soot/tutorial
in particular, "Creating a Class File from Scratch."
If your language is C-like, you might have an easier time generating
Java source code directly. If your language is bytecode-like, you might
have an easier time generating bytecode directly. In both cases, Soot
can still be used to analyse your classfiles.
Cheers,
Chris
emujrock wrote:
> I am working on code tool for some legacy system. The purpose of the
> tool is to convert programs in proprietary legacy language to Java. The
> language has goto and I need some goto removal framework. It looks like
> soot can do exactly what I need.
>
> I start from AST tree of legacy program, not from java bytecode. My
> direct attempt to use soot goto removal algorithm failed because it
> relies upon low level packages baf.* and jimple.*. I do not understand
> how to build “Body”, “Unit” and “Block” instances directly without going
> through bytecode. From what I see in the code it looks like it may be
> impossible to do. If I am wrong could somebody point me to the right
> direction? If it can not be done now:
>
>
> Do you have any plans to separate high level CFG algorithms from
> the rest of the code? If you need volunteers to do this I am ready to
> contribute.
>
> Sincerely,
> Pavel
>
>
>
>
>
>
More information about the Soot-list
mailing list