RFC: Optional Language Provider Factory for Non-Sleigh Processor Languages

[Mr-wolf-is-me]

RFC: Optional Language Provider Factory for Non-Sleigh Processor Languages

Type: Design Proposal / RFC
Scope: Documentation only – no implementation included

---

Motivation / Problem Statement

Ghidra processor support is currently centered around SLEIGH (.slaspec) definitions.
While SLEIGH is powerful, it can be cumbersome or impractical for certain non-standard or highly irregular architectures, such as Qualcomm Hexagon, where instruction decoding and semantics are more naturally expressed in custom code.

At present, developers who wish to integrate such architectures are effectively constrained to:

• Force-fitting the ISA into SLEIGH, or
• Bypassing core language infrastructure, leading to poor integration with existing Ghidra analysis pipelines.

This RFC proposes a minimal and backward-compatible extension point that allows processor developers to supply their own Language implementation—while remaining fully integrated with Ghidra’s language loading, analysis, and decompiler architecture.

---

Goals

• Allow processor developers to provide a custom Language implementation without forking or replacing core Ghidra logic
• Preserve full compatibility with existing SLEIGH-based languages
• Require minimal changes to existing Ghidra code
• Reuse existing concepts (Language, LanguageProvider, .ldefs)

Non-Goals

• This proposal does not replace SLEIGH
• This proposal does not introduce a new language definition format
• This proposal does not change existing .slaspec behavior

---

High-Level Design

Key Idea

Allow a processor developer to supply their own Language implementation by:

1. Subclassing SleighLanguage
2. Providing a custom LanguageProvider
3. Declaring a language provider factory in the .ldefs file

This enables SleighLanguage.parse() to return a developer-defined InstructionPrototype, fully integrated into the existing Ghidra pipeline.

---

Proposed .ldefs Extension

Introduce an optional language provider factory declaration in the .ldefs file.

Example (conceptual)

<language
    id="Hexagon:LE:32:default"
    processor="Hexagon"
    endian="little"
    size="32"
    version="1.0"
    language_provider_factory="com.example.hexagon.HexagonLanguageProviderFactory">
</language>

Semantics

• The attribute is optional
• If absent, behavior is unchanged
• If present, Ghidra attempts to load the specified factory class

---

Language Provider Factory Contract

The factory class must:

• Be available on the classpath
• Implement a public static method:

public static LanguageProvider getProvider();

Responsibilities

• The factory returns a developer-supplied LanguageProvider
• That provider returns a developer-supplied Language
• The Language must extend SleighLanguage

---

Custom Language Behavior

The custom Language implementation:

• Inherits from SleighLanguage
• May override parsing logic so that:
  • SleighLanguage.parse() returns a custom InstructionPrototype
• Integrates seamlessly with:
  • Disassembly
  • Analysis
  • Decompiler pipelines (to the extent supported)

This allows instruction decoding and semantic modeling to be implemented directly in Java where SLEIGH is impractical.

---

Integration Point in Ghidra

The proposed integration point is intentionally small and localized.

Affected Method

SleighLanguageProvider.read(
    XmlPullParser parser,
    ResourceFile parentDirectory,
    String ldefs
)

Proposed Change

• Detect the optional language_provider_factory attribute
• If present:
  • Load the factory class
  • Invoke getProvider()
  • Use the returned LanguageProvider
• If absent:
  • Preserve current behavior exactly

---

Backward Compatibility

• Existing .ldefs files are unaffected
• Existing SLEIGH languages load exactly as before
• No changes required for existing processor modules
• The feature is opt-in only

---

Security and Stability Considerations

• Factory loading is explicit and developer-controlled
• No reflective scanning or automatic discovery is introduced
• Failure to load the factory should produce a clear diagnostic and fallback behavior

---

Use Case: Qualcomm Hexagon

Qualcomm Hexagon is an example of an architecture where:

• Instruction formats are highly irregular
• Semantics are difficult to express in SLEIGH
• A Java-based decoding and semantic model is more maintainable

This proposal allows such architectures to be supported without weakening or bypassing Ghidra’s existing abstractions.

---

Proposed Development Plan

1. Phase 1 — Design review and maintainer feedback (this RFC)
2. Phase 2 — Minimal core integration
3. Phase 3 — Reference implementation for a non-standard architecture

---

Open Questions for Maintainers

1. Is declaring a provider factory via .ldefs acceptable?
2. Should the declaration be an attribute or a nested XML element?
3. Is SleighLanguageProvider.read(...) the preferred integration point?
4. Are there concerns regarding class loading or module boundaries?

---

Summary

This RFC proposes a minimal, optional, and backward-compatible mechanism for supporting non-standard processor languages by allowing developers to supply their own Language implementations, while remaining fully integrated with Ghidra’s architecture.

Feedback from maintainers is requested before submitting an implementation.

[fmagin]

Would it be possible to just add a new variant of LanguageProvider and Language? Both are implemented by SleighLanguageProvider and SleighLanguage, so clearly Ghidra doesn't assume that all languages must come from SLEIGH, but I'm not sure if and how well Ghidra supports multiple co-existing LanguageProviders

[Mr-wolf-is-me]

Can you please elaborate on your suggestion? The flow of creating a Language strats from LanguageProvider.
BTW - I have tried my suggestion and it worked perfectly😎

[fmagin]

Is your code available somewhere? I'm not quite following what you have in mind based on just your proposal

[Mr-wolf-is-me]

I am waiting for approval for the proposal before I put some "clean" solution.

[thixotropist]

Ghidra's C++ decompiler code might be a more natural place to handle processor-specific instruction decoding and semantics. It's a little harder to extend than the Java code you reference, but the greater access to inferred block structure and dependency/heritage linkages might make up for that.

Your path forward might be:

• Generate a minimal SLEIGH implementation in which the Hexagon VLIW instructions get translated into user PCode function forms. The decompiler will see these as CALLOTHER varadic function calls with multiple inputs and a single output
• Add new decompiler Rules and Actions to trigger on CALLOTHER PCodeOps, then invoke PCode transforms with much more expressive power than SLEIGH's semantic section allows.
• Develop test cases derived from the LLVM Hexagon test suite. Those examples should cover much of the instruction patterns you find in the wild. Don't worry too much over pathological instruction sequences for which the semantics are unknown until runtime.

The RISC-V vector instructions handle some of the same inference-engine tasks that the Hexagon seems to be built for. The SLEIGH file does the simple/local decoding, generating about 1300 user pcode ops with very simple-minded semantics definition. Vector instruction semantics can be heavily dependent on context, especially 'upstream' vector configuration instructions. That means generating correct semantic PCode can't be done until after a lot of control flow and dependency/heritage/Phi Node/Multiequal analysis is complete. The decompiler's iterative design works pretty well at handling the circular dependencies here.

[Mr-wolf-is-me]

The proposal above does not generate hexagon (syntax) assembly code. This is crucial in my case. So "PCode function forms" and CALLOTHER, only good for the "decompiler" representation.