Skip to content

decomp: Implement CALLOTHER#130

Draft
kyle-elliott-tob wants to merge 2 commits intomainfrom
impl-other-pcode-calls
Draft

decomp: Implement CALLOTHER#130
kyle-elliott-tob wants to merge 2 commits intomainfrom
impl-other-pcode-calls

Conversation

@kyle-elliott-tob
Copy link
Collaborator

Marked as draft as this needs to be reviewed for implications and side affects before being finalized.

Add a resolveUseropName() method to centralize userop name resolution
across three categories:
- SLEIGH-defined userops (indices 0 to ~100)
- Synthetic ops (DECLARE_*, ADDRESS_OF at 0x100000+)
- Decompiler built-ins (stringdata, volatile_read/write, memcpy,
  strncpy, wcsncpy at 0x10000000+)

This enables proper handling of CALLOTHER operations that use
decompiler-injected built-in intrinsics.
CALLOTHER is a fallback pcode op for various intrinsics in high
p-code, ranging from architecture specfic intrinsics to inserted
decompiler intrinsics (like memcpy, strcpy, etc.).

Unfortunately, Ghidra's decompiler has a limitation on all arch
specific intrinsics, only allowing the Java API to access the name
'stringdata', so we need a fallback intrinsic named
'__patchestry_missing_<name>', where '<name>' is the unrecognized
intrinsic name.
public static final int ADDRESS_OF = MIN_CALLOTHER + 3;

// Ghidra decompiler built-in userop indices (from userop.cc)
public static final int BUILTIN_STRINGDATA = 0x10000000;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this list sufficient for user operations?

@kumarak
Copy link
Collaborator

kumarak commented Jan 29, 2026

@kyle-elliott-tob can you add unit test for CALLOTHER with calls to one of the userop or unknown intrinsic?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants