See section 6.1.3 "Auto-AND predicates" in the "Qualcomm Hexagon V66 Programmer’s Reference Manual"

If multiple compare instructions in a packet write to the same predicate register, the result is the logical AND of the individual compare results.

This is not handled in HexagonPcodeEmitPacked, and will silently result in only the last assignment to P3:0 being used in a subsequent compare

…ates

Consider the following (valid) hexagon code:

  { if (!P0.new) r0 = #41
    P0 = cmp.eq(R18,#0x0); if (P0.new) jump:nt 1f  }
  { r0 = #0
    jumpr r31 }
1:
  { r0 = #1
    jumpr r31 }

P0.new precedes the store to P0. We handle this case by deferring dot-new predicates and new-compare jumps till after the rest of the instructions have been processed

Massively refactors HexagonPcodeEmitPacket to accommodate

Adds a test for the above code

Adds a test including endloop01 (the only instruction which contains more than one branch)

Fixes #7 Fixes #4

See "Encoding 32-bit address operands in load/stores" in section 10.9 of "Qualcomm Hexagon V66 Programmer's Reference Manual"

For unconditional load/stores, the GP-relative load/store instruction is used. [...] In this case the 32-bit value encoded must be a plain address, and the value stored in the GP register is ignored.

binja-hexagon correctly disassembles some code as

{ immext(<blah>)
  R3 = memw(0+<extended>) }

But ghidra-plugin-hexagon shows a GP-relative address instead

Here's a weird code sample that's valid hexagon code

  { if (!P0.new) r0 = #41
    P0 = cmp.eq(R18,#0x0); if (P0.new) jump:nt 1f  }
  { r0 = #0
    jumpr r31 }
1:
  { r0 = #1
    jumpr r31 }

Even though P0.new is referenced before P0 is set, hexagon still store-forwards the write value in this case.

This will require a major refactor to HexagonPcodeEmitPacked to reorder some instructions (and split up newcmp jumps) just like in qemu

This also needs to be compatible with auto-and predicates #4, yeesh

For instructions which read C11 aka the gp register, such as L2_loadrubgp, gp should only be consulted if an immext was not applied.

For example, immext is applied below so the memref is not gp-rel:

{ immext(##0x123440)
  R0 = memw(#0+##0x123450)
  jumpr R31 }

But this is gp-rel:

{ R0 = memw(GP+##0x10)
  jumpr R31 }

Fixes this issue by adding a "gp" sleigh constructor that's conditional on the immext context reg, and adds C11 or 0 as an operand based on the above

Fixes #5

…onLanguageHelper

Previously BasicBlockModel and SimpleBlockModel might terminate a block in the middle of an instruction group

Now BasicBlockModel and SimpleBlockModel respect instruction group boundaries

Adds getFlowType to ParallelInstructionLanguageHelper and implements it in HexagonParallelInstructionLanguageHelper

Reverts formatting on ParallelInstructionLanguageHelper for a cleaner diff off of master

Adds tests, HexagonPacketTestCodeBlock

As of this commit, the function graph also respects instruction group boundaries, so there are no longer awkward flows in between packets. For example:

{  SL2_jumpr31
   SA1_seti  R0 0x2 }

Previously appeared as

SL2_jumpr31 -> SA1_seti R0 0x2

In the function graph view. These are now displayed as one basic block.

See below

ca 4b 00 5a  {  J2_call                             assert_fail
    -- Flow Override: CALL_RETURN (CALL_TERMINATOR)

All instructions after the call are undefined. Also notice that the J2_call is not the end of its own packet. This occasionally breaks decompilation as well

Previously we would emit pcode for instructions in the order they appear in the listing (order of increasing address). This assumption is incorrect for DUPLEX instructions.

DUPLEX instructions appear in the listing in swapped order: the slot 0 instruction appears earlier in memory, followed by the slot 1 instruction. But execution order follows the opposite ordering: order of decreasing slots (so slot 3, 2, 1, 0)

As a result, we would emit incorrect pcode for the following assembly:

{ R3 = memw(R2+#0x0); memw(R2+#0x0) = #0x0 }

As written, the load comes before the store, but since they are DUPLEX the store would appear before the load, causing the load to be const-propped. This commit fixes the issue.

Fixes #10

The plugin emits incorrect pcode for the following snippet:

{ R3 = memw(R2+#0x0); memw(R2+#0x0) = #0x0 }

The store should occur after the load, as written. The problem causing the incorrect pcode is that these instructions form a DUPLEX; and in a DUPLEX the slot 0 instruction comes first in program memory, but the slot 1 instruction must always be executed after.

A standard InstructionIterator is insufficient

AddressSet addrSet = new AddressSet(minAddr, maxAddr);
program.getListing().getInstructions(addrSet, true)

Because DUPLEXes will be enumerated in the incorrect (execution) order

The current implementation of endloops has some issues. First, endloop01 has a subtle decompilation bug that doesn't seem to be an issue with pcode generation (see testHwLoop01). Also, the jumps themselves are indirect (goto [C0];) so the graph view doesn't display the loop edge

Consider replacing C0 and C2 with context registers, to replace the indirect branches with direct branches. This requires updating a few opcodes:

• J2_loop0r
• J2_loop1r
• J2_loop0i
• J2_loop1i
• J2_ploop1sr
• J2_ploop1si
• J2_ploop2sr
• J2_ploop2si
• J2_ploop3sr
• J2_ploop3si
• J2_endloop0
• J2_endloop1
• J2_endloop01

According to Qualcomm Hexagon Application Binary Interface

For [variadic] functions, we pass the named (and typed) parameters in the same manner as for fixed argument list functions. The remainder of the arguments are passed on the stack.]

I do not know how to achieve the desired behavior in the cspec