[prev in list] [next in list] [prev in thread] [next in thread] 

List:       bcel-user
Subject:    Re: How to replace a complete instruction in J2ME Bytecode
From:       "Klaus Teller" <klaus.teller () gmx ! net>
Date:       2009-02-16 4:53:08
Message-ID: 20090216045308.65880 () gmx ! net
[Download RAW message or body]

Hi Arin,

I would like to follow up on this problem. Right now, i can indeed replace the method \
following your instruction. The method i'm replacing is Connector.open. I can replace \
it with another MyConnector.open. 

The only problem i have now is that in my custom open method, if i'm not able to call \
methods from other objects. The following error message is produced:

Approximate bytecode offset 3: Inconsistent or missing stackmap at target

Any idea how i can address this?

Thanks,

Klaus.


 
-------- Original-Nachricht --------
> Datum: Tue, 10 Feb 2009 16:27:08 +1100
> Von: Arrin Daley <arrin.daley@anu.edu.au>
> An: BCEL Users List <bcel-user@jakarta.apache.org>
> Betreff: Re: How to replace a complete instruction in J2ME Bytecode

> Hi Klaus
> 
> I've primarily only used JavaClass but should've probably used ClassGen.
> 
> Do you do a MethodGen.getMethod()? this returns a Method object which 
> you should then make part of the JavaClass (via JavaClass.setMethods()) 
> or ClassGen (via setMethods() or setMethodAt()) which you got the method 
> from. Your supposed to do a setMaxStack() and setMaxLocals() before a 
> call to getMethod() but your changes shouldn't change the stack or local 
> variables, but it's probably good practice.
> 
> You will also have to get a ConstantPool via 
> ConstantPoolGen.getFinalConstantPool() and make this part of your 
> JavaClass, I don't think it's required for ClassGen as I think it 
> happens when you ask for a JavaClass, not sure though, you might need to 
> check.
> Note: sorry I remembered constant pools being associated with methods 
> but they're associated with the class.
> 
> Basically you need to make sure your changes take effect in the 
> JavaClass before you dump it, so ConstantPoolGen needs to create a new 
> ConstantPool, MethodGen needs to create a new Method, and ClassGen (if 
> you use it) needs to create a new JavaClass, otherwise the JavaClass 
> will continue to have the old state and that's what will be dumped.
> ClassGen may take care of some of this for you via getJavaClass().
> 
> Hope it helps,
> 
> Bye Arrin
> 
> 
> Klaus Teller wrote:
> > Hi Arin,
> > 
> > Thanks for your feedback; very insightful. I went through all the steps,
> identified the right invokestatic, added it into the constant pool, and
> updated the index of the invokestatic. 
> > 
> > Right now, the only issue i'm having is that the dump doesn't include my
> changes, which might indicate that something is missing.
> > 
> > Any idea?
> > 
> > If you wish, i can send you the code offline.
> > 
> > Thanks again,
> > 
> > Klaus.
> > 
> > 
> > -------- Original-Nachricht --------
> > 
> > > Datum: Tue, 10 Feb 2009 12:32:16 +1100
> > > Von: Arrin Daley <arrin.daley@anu.edu.au>
> > > An: BCEL Users List <bcel-user@jakarta.apache.org>
> > > Betreff: Re: How to replace a complete instruction in J2ME Bytecode
> > > 
> > 
> > 
> > > Hi Klaus
> > > 
> > > You'll need to find the INVOKESTATIC instruction first, if you have an 
> > > idea which methods and classes the call(s) exist in this will help, 
> > > InstructionFinder is about finding a pattern of instructions you could 
> > > use it to find INVOKESTATIC instructions but that would probably be 
> > > overkill, you could just use an iterator or something similar.
> > > 
> > > Once you have found the INVOKESTATIC instructions you could then test
> to 
> > > see which one(s) match your function call, you could do this by looking
> > > at the classname and method name and possibly arguments the other way 
> > > would be to look up the index for the method in the constant pool (if
> it 
> > > exists in the constant pool, don't put it in if it doesn't) and compare
> > > this index to that of the INVOKESTATIC instruction which you have
> found. 
> > > If the static method doesn't exist in the constant pool then there
> isn't 
> > > a call to that static method in the code your currently looking at so 
> > > you could move on to the next method to search.
> > > 
> > > Once you find an INVOKESTATIC that matches you need to put your new 
> > > static method in the constant pool via a ConstantPoolGen, this will 
> > > return an index which you can then use with the setIndex method on the 
> > > INVOKESTATIC instruction. You can use the setIndex because you are just
> > > changing the target of INVOKESTATIC instructions, otherwise you would 
> > > have to replace the instruction itself.
> > > 
> > > I'm not sure what other finalising things you will need to do, the 
> > > ConstantPool, ConstantPoolGen  will have changed so will need to 
> > > finalise that, and you will have to get a Method from the MethodGen 
> > > object you previously had but I think that's about all...
> > > 
> > > Another way might be to define an InstructionVisitor overriding the 
> > > visit method for INVOKESTATIC to find and edit the appropriate
> > > instructions.
> > > 
> > > Hope it helps
> > > 
> > > Bye Arrin
> > > 
> > > Klaus Teller wrote:
> > > 
> > > > Hi Folks,
> > > > 
> > > > I have a J2ME Library that contains the following instruction:
> > > > 
> > > > invokestatic
> > > > 
> > > 
> javax/microedition/io/Connector/open(Ljava/lang/String;IZ)Ljavax/microedition/io/Connection;
> 
> > > 
> > > > I would like to replace it with:
> > > > 
> > > > invokestatic
> > > > 
> > > 
> mypackage/AlphaConnector/open(Ljava/lang/String;IZ)Ljavax/microedition/io/Connection;
> 
> > > 
> > > > What do i need to do?
> > > > 
> > > > I couldn't find a way to search instruction based on the operand (that
> > > > 
> > > is the second part of the instruction). I tried IntructionFinder; but
> it
> > > couldn't help me. 
> > > 
> > > > I would very much appreciate any input.
> > > > 
> > > > Thanks,
> > > > Klaus.
> > > > 
> > > > 
> > > > 
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: bcel-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: bcel-user-help@jakarta.apache.org
> > > 
> > 
> > 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: bcel-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: bcel-user-help@jakarta.apache.org

-- 
Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: \
http://www.gmx.net/de/go/multimessenger01

---------------------------------------------------------------------
To unsubscribe, e-mail: bcel-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: bcel-user-help@jakarta.apache.org


[prev in list] [next in list] [prev in thread] [next in thread]