Major Description
The VMTT tool appears to generate bad bytecode when the lookupswitch instruction starts at instruction (4n-1). According to the spec, this code:
0: nop
1: nop
2: iload_1
3: lookupswitch
should generate this output:
// 0: nop
x00
// 1: nop
x00
// 2: iload_1
x1B
/* lookupswitch size is:
1: lookupswitch
0: padding
4: default address
4: npairs
4: case 1 match (1)
4: case 1 value
4: case 2 match (4)
4: case 2 value
4: case 3 match (9)
4: case 3 value
4: case 4 match (16)
4: case 4 value
Total: 41
*/
// 3: lookupswitch
xAB // lookupswitch
// no padding
x00 x00 x00 x36 // default: 3+54=57
x00 x00 x00 x04 // npairs: 4
x00 x00 x00 x01 // match: 1
x00 x00 x00 x29 // offset 3+41=44
x00 x00 x00 x04 // match: 4
x00 x00 x00 x2C // offset 3+44=47
x00 x00 x00 x09 // match: 9
x00 x00 x00 x30 // offset 3+48=51
x00 x00 x00 x10 // match: 16
x00 x00 x00 x32 // offset 3+50=53
Instead, it generates this output:
// 0: nop
x00
// 1: nop
x00
// 2: iload_1
x1B
/* lookupswitch size is:
1: lookupswitch
4: padding - looks like VMTT is giving us 4 bytes?!?
4: default address
4: npairs
4: case 1 match (1)
4: case 1 value
4: case 2 match (4)
4: case 2 value
4: case 3 match (9)
4: case 3 value
4: case 4 match (16)
4: case 4 value
Total: 41
*/
// 3: lookupswitch
xAB // lookupswitch
x00 x00 x00 x00 // 4 bytes of padding?
x00 x00 x00 x36 // default: 3+54=57
x00 x00 x00 x04 // npairs: 4
x00 x00 x00 x01 // match: 1
x00 x00 x00 x29 // offset 3+41=44
x00 x00 x00 x04 // match: 4
x00 x00 x00 x2C // offset 3+44=47
x00 x00 x00 x09 // match: 9
x00 x00 x00 x30 // offset 3+48=51
x00 x00 x00 x10 // match: 16
x00 x00 x00 x32 // offset 3+50=53
In other words, it's emitting 4 bytes of padding instead of 0 bytes of padding after the xAB lookupswitch instruction. This is 4-aligned, but not what most VMs expect.