jakarta-bcel-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Huw Evans <...@dcs.gla.ac.uk>
Subject Re: Instrumenting a constructor
Date Tue, 01 Oct 2002 17:22:29 GMT

> > I think you only have to identify the return statements
> (and the end of the 
> > constructor) and do an insert of the call to your
> method (taking care about 
> > pushing any necessary parameters).
> Don't all returns have to be explicit in bytecode?

Yes they do have to be, but I was just making the point you needed to go all
the way to the end of the bytecode for the method to be sure to see them all.
A small point.

> Just to make sure I understand, you're saying that BCEL
> will do any jump patching for me, as long I use
> InstructionList.insert*, and then I won't have to do any
> manually patching at all? (I was actually looking for an
> insert method before, but managed to miss it all this
> time <sigh>).

Let's distinguish two things.  The bytecode before you insert anything into it 
and the new bytecode with the new bytecode inserted into it.

Once you have inserted something into the list, you have a mix of bytecode, 
old stuff and the new stuff that was inserted.  I believe that for the old 
bytecode that was in the list before, the branches will be worked out for you. 
You will have to handle any branches for the new stuff.  For example, if your 
new stuff needs to be branced to from other new code, you will have to handle 
this.  If your new stuff replaces some old stuff (by doing an insert and then 
a delete) I *believe* the system will handle this for you.

I would like Markus to confirm this please.

This is why I suggested the simple version to try things out on, to get this
kind of fundamental thing sorted out early.

> IIUC, that applies to any local variable that I need to
> get a hold of.

I see what you mean.  If compilers do treat slot 0 like this, then your point 
is true.

The point I was making was the fact that aload_0 pushed 'this' onto the stack
and then called java.lang.Object() constructor, rather than pushing something 
on to the stack which indicated 'super', rather than 'this'.  However, Java 
always dispatches a method from the 'this' level up, so there is no need to do 


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

View raw message