[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