DO NOT REPLY [Bug 49278] New: Branch target offset too large for short

[bu...@apache.org]

https://issues.apache.org/bugzilla/show_bug.cgi?id=49278

           Summary: Branch target offset too large for short
           Product: BCEL
           Version: unspecified
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Main
        AssignedTo: notifications@jakarta.apache.org
        ReportedBy: cfeldmann@rogers.com


Created an attachment (id=25432)
 --> (https://issues.apache.org/bugzilla/attachment.cgi?id=25432)
Fix to avoid "Branch target offset too large for short" exception.

When BCEL encounters a BranchInstruction offset that is >= 32767, it throws the
following exception:

com.sitraka.pas.sandbox.org.apache.bcel.generic.ClassGenException: Branch
target offset too large for short
at
com.sitraka.pas.sandbox.org.apache.bcel.generic.BranchInstruction.dump(BranchInstruction.java:99)
at
com.sitraka.pas.sandbox.org.apache.bcel.generic.InstructionList.getByteCode(InstructionList.java:993)
at
com.sitraka.pas.sandbox.org.apache.bcel.generic.MethodGen.getMethod(MethodGen.java:616)
..........

Bug 35405 was previously filed about this exception and closed because the
class that was causing the error and the suggested solution were both violating
the rules of the language. My situation is a little different, so I am filing a
new bug. 

I am inserting bytecodes into a method that is large, but within the limits
defined by the language. Due to the size of the method, a number of the branch
targets are large, but still small enough to fit in a short. After I insert
bytecodes, the method size is still smaller than the method size limit but the
large branch targets increase enough so that they no longer fit in a short and
the exception occurs. 

I have solved the problem and am including a patch. My solution is to check the
InstructionList for any branch targets that are too large to fit in a short and
append a goto and a goto_w after every such instruction. I set the goto's
target to the instruction that followed the branch instruction before I did my
append so that the default behaviour is to maintain the original path of
execution and jump over the goto_w. I set the goto_w's target to the branch
instruction's target, then I set the branch instruction's target to the goto_w.
I am doing this only for IfInstructions because JSRs, GOTOs and Selects seem to
handle large branch targets in their implementations of updatePosition. This
works and is within the rules defined by the language as far as I can tell.

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

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