Re: Invokation and return statement analysis with BCEL

Hi Mac

1.
What type are you trying to find out from ARETURN? All the type(s) that 
could be returned? or a superclass of all the types that could be returned?

If you are trying to track down all of the types that might be returned 
(the subclasses) then I'm guessing you will need to do stack simulation

There are some classes in BCEL's verifer project that will help you out 
by doing stack simulation this will let you access the types on the 
stack. Have a look at the org.apache.bcel.verifier.structurals 
<http://djvm/internal/bcel-5.2/apidocs/org/apache/bcel/verifier/structurals/package-frame.html> 
package in BCEL. It's real purpose is verification but we have used it 
to find the types returned from AALOAD operations so finding the types 
returned from ARETURN should be no harder.

Your problem if your goal is to capture all types that could be returned 
the current stack simulation does a merge where it finds the superclass 
of the two or more subclasses found. If you extend the current 
ExecutionVisitor you could modify this behaviour and record all types.
The other thing that is a little annoying is that the ExecutionVisitor 
uses a InstConstraintVisitor, it seems that the JustIICE verifier has a 
more strict notion of what is valid code than the original java virtual 
machine so when you modify ExecutionVisitor make it so that it doesn't 
use a InstConstraint visitor, otherwise you will get JustICE telling you 
about errors in code the JVM passes.

2.
I'm not sure what your after here, if you find an InvokeInstruction the 
arguments passed to it may have been from the stack and never had any 
identifiers (that I can see, I might be wrong here) you could find out 
the argument names by loading and looking up the associated method, is 
this what you mean?
Looking at the LocalVariableTable might look tempting but the 
LocalVariableTable is a optional debugging structure so you can't count 
on it, more importantly I'm not sure it is always correct if it is 
present, for instance I can edit a Method in BCEL and never effect the 
contents of the LocalVariableTable.

I hope this helps, letme know if I can help some more.

Bye Arrin



Nicholson, Jonathan O H wrote:

>Heya guys,
>
>I'm doing a research project in formal methods, and I'm looking into
>BCEl to be able to provide me with certain information about a given
>class (there are benefits, from our point of view, to class inspection
>over source code inspection that I need not go into).
>
>I have managed to program a vast majority of the features we require
>pretty quickly, and I am more than glad to see the programs dependency
>on CFParse disappear. The method that does the analysis is in this
>format:
>
>foreach(JavaClass c : somearray)
>{
>  // Inspect the class
>  InstructionList list = c.getInstructionList();
>  foreach(Instruction i : list.getInstructions())
>  {
>    switch(i.getOpcode())
>    {
>      // do something when certain instructions are found
>    }
>  }
>}
>
>There is no modification of the classes as they are processed, and
>information is basically dumped into a database (currently to the screen
>while debugging) as its found
>
>Problems:
>1) When a ARETURN instruction is found, I need to know the identifier
>and type of the object being returned. Return type is not enough, and
>from what I can see all methods in Java bytecode return
>java.lang.Object, so using getType() on the ARETURN instruction doesn't
>help either.
>2) When an InvokeInstruction is found, I need to know the identifiers of
>each of the objects used as arguments for the invoked method.
>
>I understand the Java VM is stack based, so at first I thought it would
>be logical to maintain a stack of variables so by knowing how many
>things are removed from the stack (for example 1 in the case of
>ARETURN... I think...) I can find out what idents/types are being used.
>
>However I just cant get it to work. I'm not familiar enough with every
>bytecode instruction to be able to do it. I have been looking at the
>CodeHTML class to see how it works, but right now I can't get my head
>around the logic.
>
>If someone could help, give me example/pseudo code if you've done
>something similar, direct me to a package/library that can provide me
>with this information, etc, I would be very grateful.
>
>Thanks all
>Regards
>
>Mac
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [email protected]
>For additional commands, e-mail: [email protected]
>
>  
>

-- 
Conventional wisdom says to know your limits. To know your limits you 
need to find them first. Finding you limits generally involves getting
in over your head and hoping you live long enough to benefit from the 
experience. That's the fun part.