I've changed it to:
instruction.Operand = ((sbyte) il.ReadByte ()) + il.position;
and it seems to have solved my problem.
On May 21, 4:39 pm, Alix <[email protected]> wrote:
> Hi.
> I've think I've found a bug with the operands of branch instructions
> in short form (br_s, leave_s, etc). Here's a code snippet of
> MethodBodyReader.ReadOperand(Instruction instruction):
>
> void ReadOperand (Instruction instruction)
> {
> switch (instruction.OpCode.OperandType) {
> ...
> case OperandType.ShortInlineBrTarget:
> instruction.Operand = (sbyte) (il.ReadByte () + il.position);
> break;
> ...
>
> }
>
> The ECMA specification states that the operand of a branch instruction
> represents the offset from the beginning of the next instruction. I
> see that you store the absolute offset, starting from 0, which is fine
> by me, but then you shouldn't cast to sbyte, should you? This would
> mean you cannot have a short jump between instructions that have a
> high offset. For example:
>
> L_00da: leave.s L_0138
> L_00dc: ...
>
> is valid because it's jumping from 0x00DA (218) to 0x0138 (312).
> They're 94 bytes apart, which fits into an int8 and makes this a valid
> instruction. However, if you add the offset of the next instruction to
> 0x0138 you get 0x0214 (532) which does not fit into an sbyte and
> results in an overflow.
>
> Am I getting this wrong? Thanks.
>
> --
> --
> mono-cecil
--
--
mono-cecil
