ghidra.program.database.code.InstructionDB does not return complete/correct/consistent operand data for ARM:LE:32:v8 add instruction

[mike-hunhoff]

Describe the bug
ghidra.program.database.code.InstructionDB does not return complete/correct/consistent operand data for ARM:LE:32:v8 add instruction e.g.

>>> insn = getInstructionAt(currentAddress)
>>> print(insn.getAddress(), insn)
(000157c4, add r2,sp,#0x10)
>>> for i in range(insn.getNumOperands()):
... 	print(i, insn.getOpObjects(i))
... 
(0, array(java.lang.Object, [r2]))
(1, array(java.lang.Object, [sp]))
(2, array(java.lang.Object, [0x10]))
>>>
>>>
>>>
>>> insn = getInstructionAt(currentAddress)
>>> print(insn.getAddress(), insn)
(00011f36, add r7,sp,#0xc)
>>> for i in range(insn.getNumOperands()):
... 	print(i, insn.getOpObjects(i))
... 
(0, array(java.lang.Object, [r7]))
(1, array(java.lang.Object, [sp, 0xc]))

To Reproduce

1. Load and analyze https://www.virustotal.com/gui/file/ec834074b81a536a44f903619a1fcae76c3cf35309d6a394d9fbb5d4479b6ba0
2. Execute code shown above for listed instructions:

• (000157c4, add r2,sp,#0x10)
• (00011f36, add r7,sp,#0xc)

Expected behavior
I'd expect ghidra.program.database.code.InstructionDB to behave the same for both instructions, specifically, in the case of the former example where the number of operands equals three, resulting in:

>>> insn = getInstructionAt(currentAddress)
>>> print(insn.getAddress(), insn)
(000157c4, add r2,sp,#0x10)
>>> for i in range(insn.getNumOperands()):
... 	print(i, insn.getOpObjects(i))
... 
(0, array(java.lang.Object, [r2]))
(1, array(java.lang.Object, [sp]))
(2, array(java.lang.Object, [0x10]))
>>>
>>>
>>>
>>> insn = getInstructionAt(currentAddress)
>>> print(insn.getAddress(), insn)
(00011f36, add r7,sp,#0xc)
>>> for i in range(insn.getNumOperands()):
... 	print(i, insn.getOpObjects(i))
... 
(0, array(java.lang.Object, [r7]))
(1, array(java.lang.Object, [sp]))
(2, array(java.lang.Object, [0xc]))

Environment:

• OS: Ubuntu 24
• Java Version: 17
• Ghidra Version: 11.1
• Ghidra Origin: GitHub distro

[ghidra1]

The operand list is based entirely on the slaspec constructor and subcontractor breakdown of instruction print-pieces. For x86 the enclosed group within brackets constitutes a single operand which may consist of multiple op-objects. Using the instruction info display you can see how a selected instruction breaks down to specific subconstructors within the slaspec. What you are observing is not a biug.

[ghidra1]

You may want to consider examining the default representation list which will give access to those registers, scalars and addresses visible in the instruction rendering. The opObject lists that you are using can return anything used by pcode fragments for a specific operand index. Issues with this approach include unpredictable operand numbering based on sleigh instruction breakdown, and inclusion of opObjects not shown in rendering. Representation list are more about what you see.