AArch64 `dsb` instruction doesn't always parse

[Super-Pizza]

Describe the bug
The dsb DataSynchronizationBarrier instruction doesn't properly parse most of the time, being parsed as unknown MSR calls.

To Reproduce
The following bytes fail to properly parse in LE: 9f 3f 03 d5 (dsb SY)

Expected behavior
...

Screenshots
Not really necessary

Attachments
...

Environment (please complete the following information):

• OS: Linux
• Java Version: 21
• Ghidra Version: 11.0.3
• Ghidra Origin: distro

Additional context

Fix:

diff --git a/Ghidra/Processors/AARCH64/data/languages/AARCH64base.sinc b/Ghidra/Processors/AARCH64/data/languages/AARCH64base.sinc
index 5370387..1219d65 100644
--- a/Ghidra/Processors/AARCH64/data/languages/AARCH64base.sinc 
+++ b/Ghidra/Processors/AARCH64/data/languages/AARCH64base.sinc 
@@ -2270,10 +2270,10 @@ is b_2431=0xd5 & b_2223=0 & l=0 & Op0=0 & Op1=3 & CRn=0x3 & CRm_dbarrier_op & CR
 # AUNIT --inst xd503309f/mask=xfffff0ff --status nodest
 
 :dsb CRm_dbarrier_op
-is b_2431=0xd5 & b_2223=0 & l=0 & Op0=0 & Op1=3 & CRn=0x3 & CRm_dbarrier_op & CRm_32 & CRm_10=2 & Op2=4 & Rt=0x1f
+is b_2431=0xd5 & b_2223=0 & l=0 & Op0=0 & Op1=3 & CRn=0x3 & CRm_dbarrier_op & CRm_32 & Op2=4 & Rt=0x1f
 {
        types:1 = 0x3; #MBReqTypes_All
-       domain:1 = CRm_32;
+       domain:1 = CRm_dbarrier_op;
        DataSynchronizationBarrier(domain, types);
 }

Should I make a PR?

[GhidorahRex]

Wow, this instruction is all kinds of wrong. The fix isn't exactly right either. There's another variant below it that should be removed, and the nXS variant needs to be tweaked a bit. Here's the fix I have, if you want to see if that looks better:

# C6.2.116 DSB page C6-1464 line 87160 MATCH xd503309f/mask=xfffff0ff
# C6.2.252 PSSBB page C6-1727 line 101951 MATCH xd503349f/mask=xffffffff
# C6.2.290 SSBB page C6-1810 line 106930 MATCH xd503309f/mask=xffffffff
# CONSTRUCT xd503309f/mask=xfffff3ff MATCHED 3 DOCUMENTED OPCODES
# AUNIT --inst xd503309f/mask=xfffff3ff --status nodest

:dsb CRm_dbarrier_op
is b_2431=0xd5 & b_2223=0 & l=0 & Op0=0 & Op1=3 & CRn=0x3 & CRm_dbarrier_op & CRm_32 & CRm_10 & Op2=4 & Rt=0x1f
{
	types:1 = CRm_10;
	domain:1 = CRm_32;
	nXS:1 = 0;
	DataSynchronizationBarrier(domain, types, nXS);
}

:ssbb
is b_2431=0xd5 & b_2223=0 & l=0 & Op0=0 & Op1=3 & CRn=0x3 & CRm_CRx=0 & CRm_32 & CRm_10 & Op2=4 & Rt=0x1f
{
	types:1 = CRm_10;
	domain:1 = CRm_32;
	nXS:1 = 0;
	DataSynchronizationBarrier(domain, types, nXS);
}

:pssbb
is b_2431=0xd5 & b_2223=0 & l=0 & Op0=0 & Op1=3 & CRn=0x3 & CRm_CRx=4 & CRm_32 & CRm_10 & Op2=4 & Rt=0x1f
{
	types:1 = CRm_10;
	domain:1 = CRm_32;
	nXS:1 = 0;
	DataSynchronizationBarrier(domain, types, nXS);
}

# C6.2.116 DSB page C6-1464 line 87160 MATCH xd503323f/mask=xfffff3ff
# CONSTRUCT xd503323f/mask=xfffff3ff MATCHED 1 DOCUMENTED OPCODES
# xd503323f/mask=xfffff3ff NOT MATCHED BY ANY CONSTRUCTOR
# b_0031=11010101000000110011..1000111111

:dsb CRm_32
is b_2431=0xd5 & b_2223=0 & l=0 & Op0=0 & Op1=3 & CRn=0x3 & CRm_32 & CRm_10=2 & Op2=1 & Rt=0x1f
{
	types:1 = 0x3; # MBReqTypes_All
	domain:1 = CRm_32;
	nXS:1 = 1;
	DataSynchronizationBarrier(domain, types, nXS);
}

[Super-Pizza]

Yeah, I used my version as a temporary workaround, but yes, yours seems more complete.