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.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
