How to handle nested delay slot instructions?

[gardenofnumbers]

Since release 6 (see: 1486) nested delay slot instructions are treated as an error (Reserve Instruction Exception).

I am developing SLEIGH definitions for a language which allows nested delay slots, so long as both branches can never be taken at once. This is used extensively in programs on this language to implement jumptables.

I imagine it might be reasonably low effort - though I've no idea where to start - to patch ghidra to allow nested delay slot instructions. In this particular case, if both branches are taken it results in a CPU exception - the disassembler and decompiler can essentially ignore the delayslot for branch instructions where the next instruction is also a branch.

As for a pure sleigh solution, I'm not sure how to handle this without lookahead. from 4390 it looks like lookahead is not supported. I could store off the branch target in a context register and only emit the branch pcode while processing the next instruction, but that runs into issues if a delay instruction is ever a branch target as well

I would appreciate any advice or ideas

[ghidra1]

Sleigh cannot support this recursive delay slot condition as it can lead to very bad conditions. There are generally other solutions which can be employed to avoid this. What processor are you modeling? This situation can arise with parallel instruction pipelines.

[gardenofnumbers]

I can't specify exactly the architecture I'm working on as it is proprietary. However, I've reconstructed the issue in a standalone slaspec I can share here with examples of what I'm running into. slaspec.zip

Unfortunately, it's not a parallel instruction pipeline. It's a fairly standard RISC architecture, with a delay slot, and the added wrinkle of allowing multiple consecutive jump instructions as long as only one branch is actually taken.

I've developed a workaround using context variables to simulate delay slot behavior, but it's pretty fragile and janky, and requires significant duplication of instruction definitions. It also breaks under certain flow conditions, e.g. if an instruction is both in a delayslot (it comes immediately after a branch) and also the target of a branch, ghidra emits something like:

Error | Bad Instruction | Multiple flows produced inconsistent instruction prototype at 0006 - possibly due to inconsistent context (flow from 0005) | 0006 | LAB_0006 | inst r0 0x0 0x0

I'd welcome any more elegant suggestions.

Thanks!

[ghidra1]

I would discourage the use of such a large context if it can be avoided. Why are your context field so large (e.g., delay_depth is defined as 32-bits when 2-bits would seem to suffice)?

I am having a tough time decipering the true instruction specification from your sample slaspec and how the processors instruction pipeline would operate. Which instruction dictates the existence of a required delayslot? Is it simply every jump instruction has one delayslot - which in your case may be another jump instruction?

[gardenofnumbers]

Every branching instruction has an unconditional delay slot, and that slot may contain another branch, so long as only one of the chained branches is taken. In the case where multiple branches would be taken (e.g. an unconditional jump with an unconditional jump in it's delay slot) a hardware exception is raised.

Besides optimization issues, the main difficulty I've been running into is that sometimes an instruction in a delay slot is also the target of a branch from elsewhere, which messes up the computed control flow. The instruction in the delay-slot always has the pcode to handle the delayed branch...

[ghidra1]

You may also like to examine the PA-RISC processor implementation within Ghidra which was unable to use delayslots to address its needs which may be similar. It too allows a branch instruction within the previous branch instruction's delay slot. (see page 4-10 of PA-RISC 1.1 Architecture)

[gardenofnumbers]

Thank you! This looks very similar to my use-case! I'm looking through the PA-RISC spec now

I would discourage the use of such a large context if it can be avoided. Why are your context field so large (e.g., delay_depth is defined as 32-bits when 2-bits would seem to suffice)?

Sorry, this is the first SLASPEC I've tried to put together so there's probably lots of little optimization issues and mistakes like that.

I'll update this thread again if I run into any more trouble, tyvm for the help

[gardenofnumbers]

Ah, it looks like the PA-RISC implementation suffers from the same issue I've been running into, link to code

# If there is a branch into the delay slot of a different branch,
# then the branch logic will still be present from the preceding instruction
# and the control flow will branch to that destination.
# This case should result in a red bookmark due to the disassembly context difference

I'll at least be able to significantly clean up my implementation with the caret based branch instruction builders, it's much simpler than whatever hack workaround I managed to put together (EDIT: yep, went from 1500 LoC to 500 and it's much cleaner now, thanks for the pointer!), but the code I'm trying to decompile does this fairly often (I think it's a compiler optimization for certain loops) and this leads to wildly incorrect flow analysis / decompilation... Any idea if this can be worked around?

I think perhaps I could have another context flag which gets set when processing a branch destination and jumps over the emitted pcode for the delayed branch, gonna tinker with that for now
EDIT: That idea doesn't seem to work, like at all