Track instruction packet membership in more detail

[Rot127]

Hexagon instructions can belong to instruction packets. To mark those packet the assembly gets prefixed (with /,\,|) like that:

; two instruction packets.
/ immext(##0x1c00)
| R11 = ##loc.start_pc
| immext(##0x1c00)
\ R12 = ##loc.start_sp
/ R15 = asl(R15,R2)
\ memw(R13+R2<<#0x2) = R5

Here is how the plugin assigns the correct packet prefix to the assembly:

• The last instruction in a packet has certain bits set. (See reference manual v67 Chapter 10.5).
  • Prefix it with \, set new_pkt_starts = true
• A new packet starts (because the previous instruction was the last instruction in its packet.)
  • The next instruction is prefixed with a /
• Each following instruction is prefixed wit a |, if it is not the last instr. nor the first one.

The logic is implemented in hex_set_pkt_info().

Unfortunately this causes some problems.
Assume the correctly disassembled instruction packet:

> s 0x00005170
> pi 4
0x00005170      /     immext(##0x1c00)    ;  #1 in packet
0x00005174      |     R11 = ##loc.start_  ;  #2 in packet
0x00005178      |     immext(##0x1c00)    ;  #3 in packet
0x0000517c      \     R12 = ##loc.start_  ;  #4 in packet

now do:

> s 0x00005174
> pi 1
/     R11 = ##loc.start_  // Is marked as #1, but is #2 in packet

Bug: R11 = ##loc.start_ should be prefixed with a | but has a / because the last disassembled instruction (R12 = ##loc.start_ at 0x0000517c) was marked as the last packet in the packet.

To solve this the plugin somehow needs to peek into the previous instruction in memory. This way it could check, whether it is indeed the first one.

[Rot127]

Also consider #17 when fixing this.