AT ENTRY rules adjust named parameter offsets from 0 to end of injected code

When Byteman injects code AT ENTRY it inserts the injected code before processing any of the labels in the bytecode stream which precede the first instruction. This is necessary because it avoids any problem when the label stream includes the target of a backwards jump belonging to a while loop – injecting after the label was visited would mean that the code was executed every time round the loop rather than before entering the loop.

Unfortunately, the label stream may also include start labels for local (parameter) variables found in the local variable table. I the original byte code these all have start offset 0. Injecting before these labels are visited means that their start offset is changed to the end of the injected AT ENTRY code. This misrepresents the situation in the output bytecode because it no longer appears as if the parameter variables are in scope from start of method.

This does not stop the parameters being referenced from an AT ENTRY rule which first introduces any such offset. When processing such a rule Byteman already knows which parameters are in scope and so can resolve references by name to $this, $myArg etc). However, this can cause problems when multiple AT ENTRY rules are injected into the same method. A second injected rule will no longer see a named parameter like $this, $myArg etc as being in scope from offset 0. Similar problems may arise when Byteman is used in conjunction with other bytecode transformers which expect parameters to be in scope from the start of the method.

This can be fixed very as follows:

insert marker labels before and after any initial injected code
if a local variable is notiifed whose start position equal to the end marker
then forward the local variable notification using the begin marker as start