Q: Why does the Ghidra error dialog hide the '<' character and show different text than the stack trace?

In Ghidra 9.1, the expandable error dialog renders plain-text messages as HTML without escaping them first. `ErrLogExpandableDialog.getHTML()` inserts the dialog message and each `Throwable.getMessage()` through `addHTMLContent()`, while `addBR()` only converts newlines to ` `. Therefore, text such as ` = 1 and `: ```java private static String escapePlainText(String s) { return s.replace("&", "&") .replace(" ", ">"); } ``` Apply this to both the main message and `Throwable.getMessage()` in `ErrLogExpandableDialog.getHTML()`, rebuild Ghidra, or use a build that includes the fix titled "Escape plain-text messages in the expandable error dialog".

Question 1

How to fix Ghidra showing `MOV AX, DS` instead of `MOV DS, AX` for opcode `8E D8`?

Accepted Answer

This is a regression in Ghidra 12.1.3 and 12.1.4 caused by commit GP-7018. The x86 SLEIGH specification displays the segment register and general-purpose register in the wrong order for `MOV` opcode `0x8e`.

To fix it locally, edit `Ghidra/Processors/x86/data/languages/ia.sinc` and change the affected constructor names from:

```
:MOV Rmr16,Sreg ... { Sreg = Rmr16; }
:MOV Rmr32,Sreg ... { Sreg = Rmr32(0); }
:MOV Rmr64,Sreg ... { Sreg = Rmr64(0); }
```

to:

```
:MOV Sreg,Rmr16 ... { Sreg = Rmr16; }
:MOV Sreg,Rmr32 ... { Sreg = Rmr32(0); }
:MOV Sreg,Rmr64 ... { Sreg = Rmr64(0); }
```

Only the displayed operand order changes; the semantic action must remain `Sreg = ...`.

Then rebuild the x86 SLEIGH binaries from the Ghidra installation root:

```
support/sleigh -a Ghidra/Processors/x86
```

Restart Ghidra and reopen the program. The instruction for bytes `8e d8` should then disassemble correctly as `MOV DS,AX`. The fix was submitted in PR #9637, so upgrading to a release containing that fix is the permanent solution.

Question 2

How to fix the Sleigh decompiler error "Index 8 out of bounds for length 8" when an instruction has more than 8 operands?

Accepted Answer

Upgrade to Ghidra 11.0 or newer. This release includes commit `0e9c36b513c4d744fe6c6f7559c049ce1d65266f`, which extends the maximum number of Sleigh/Pcode operands beyond the previous limit of 8. If you must use an older Ghidra version, reduce the pseudo-opcode definition to at most 8 operands as a workaround.

Question 3

How do I fix Ghidra decompiler error "Low-level Error: Forced merge caused intersection" for a 16-byte RDX:RAX return?

Accepted Answer

This occurs in Ghidra 12.1.2 when a callee has the default `void` signature but actually returns a 16-byte value in `RDX:RAX`, and the caller stores that value into an address-tied stack slot on only one conditional path. The decompiler reuses the stack slot as the call output and conflicts with the existing INDIRECT varnode.

Permanent fix: upgrade to a build containing GP-7136 (commit `bb33bad196`, fixed on `master`). The fix was not present in 12.1.2–12.1.4 or the 12.2 branch when the issue was reported.

Workaround in affected versions:
1. Open the callee function, such as `ret_pair`.
2. Edit its function signature/return type.
3. Define and assign a locked 16-byte struct return type, for example:
   ```c
   struct Pair16 {
       undefined8 a;
       undefined8 b;
   };
   ```
4. Set the calling convention to `__stdcall` and apply the signature.
5. Reopen the caller in the Decompiler.

If the return value is not needed, changing the callee's return type to `void` also avoids the crash. A call-site-only "Override Signature" to `void(void)` is not sufficient.

Question 4

How to fix Ghidra decompiler incorrectly removing reachable code with 'Removing unreachable block' on big-endian targets like 6809 or H8/300H?

Accepted Answer

This is a Ghidra 12.1.2 big-endian `splitflow` bug. When a register is split into independently used halves, such as 6809 `D` (`A`/`B`), the decompiler can swap the pieces' consume masks. The live piece is then treated as unused, replaced with zero, its branch is folded, and reachable code is deleted.

Temporary workaround: disable the decompiler's `splitflow` simplification rule and re-decompile. The warning should disappear and the live register half/conditional code should be restored.

Permanent fix: apply the PR "Preserve consume masks for big-endian register splits." In `TransformVar::createReplacement()`, keep using the converted big-endian storage offset only when constructing the replacement varnode address, but pass the original logical/significance offset to `transferVarnodeProperties()`. Then rebuild the native decompiler, or upgrade to a Ghidra release containing that fix.

Verify the result by confirming that the live half remains a variable, the data-dependent branch is retained, and code such as the post-loop `STA` store is no longer reported as unreachable.

Question 5

Why does the Ghidra error dialog hide the '<' character and show different text than the stack trace?

Accepted Answer

In Ghidra 9.1, the expandable error dialog renders plain-text messages as HTML without escaping them first. `ErrLogExpandableDialog.getHTML()` inserts the dialog message and each `Throwable.getMessage()` through `addHTMLContent()`, while `addBR()` only converts newlines to `
`. Therefore, text such as `<= 64` can be interpreted as an HTML tag and disappear from the rendered dialog. The underlying message is still correct in the stack trace or log: `Bit length must be >= 1 and <= 64`. Workaround: copy or read the full stack trace/log instead of relying on the rendered dialog message. Permanent fix: HTML-escape every plain-text message before inserting it into the dialog, then convert newlines to `
`: ```java private static String escapePlainText(String s) { return s.replace("&", "&") .replace("<", "<") .replace(">", ">"); } ``` Apply this to both the main message and `Throwable.getMessage()` in `ErrLogExpandableDialog.getHTML()`, rebuild Ghidra, or use a build that includes the fix titled "Escape plain-text messages in the expandable error dialog".

ghidra

Overview

README Preview

FAQ (5)

同类型项目

tensorflow

superpowers

everything-claude-code

flutter