Is your feature request related to a problem?
When reversing low-level code, I often come across code that interacts with ARM32 system registers. Quite a number of these system registers are actually bitfields (for example: SCTLR_EL1), and individual bits in these registers are set / cleared / flipped using a (sometimes complex) combination of bitwise operators. However, even if I manage to (mentally) decode the sequence of operations to something like "bit 5 of register X is being set", I still have to cross-reference with a reference manual to figure out what "bit 5 of register X" does.
The reference manual defines names for the fields inside such system registers, and with the support of bitfields in the decompiler, it'd be really nice to define bitfields for system registers, corresponding to the definitions in the manual. This way, I don't have to switch between the reference manual and Ghidra as often, and I don't have to do mental gymnastics to translate the bitwise operations into the system register fields that are accessed.
Describe the solution you'd like
I'd like Ghidra to know about the bitfields as defined by the reference manual, and automatically break up accesses to system registers as accesses to those fields.
Describe alternatives you've considered
Manually creating a data type for all system registers, and then applying the correct type as much as possible. The downside to this is that it doesn't translate easily to another program, and you have to manually type the variables that end up containing the system register values. This is labor-intensive and error-prone. Sometimes this is infeasible, because you can't actually change the type of the system registers themselves, so you can't fix an expression such as SCTLR_EL1 &= 0xFFFFFFFE.
Additional context
I imagine this feature would improve the decompilation result for more architectures, but I only mentioned ARM because that's what I'm most familiar with.
The example SCTLR_EL1 &= 0xFFFFFFFE would ideally be decompiled to SCTLR_EL1.M = 0. You could argue that you still need to check the reference manual for what the M field does exactly, but at least you should now be able to get away with just searching for M instead of also having to decode the bitwise expression. Additionally, it's easier to recognise SCTLR_EL1.M = 0 as turning off the MMU than SCTLR_EL1 &= 0xFFFFFFFE as doing the same.
I think the best solution is to specify these bitfields in sleigh, but I think that is not possible currently.
Is your feature request related to a problem?
When reversing low-level code, I often come across code that interacts with ARM32 system registers. Quite a number of these system registers are actually bitfields (for example: SCTLR_EL1), and individual bits in these registers are set / cleared / flipped using a (sometimes complex) combination of bitwise operators. However, even if I manage to (mentally) decode the sequence of operations to something like "bit 5 of register X is being set", I still have to cross-reference with a reference manual to figure out what "bit 5 of register X" does.
The reference manual defines names for the fields inside such system registers, and with the support of bitfields in the decompiler, it'd be really nice to define bitfields for system registers, corresponding to the definitions in the manual. This way, I don't have to switch between the reference manual and Ghidra as often, and I don't have to do mental gymnastics to translate the bitwise operations into the system register fields that are accessed.
Describe the solution you'd like
I'd like Ghidra to know about the bitfields as defined by the reference manual, and automatically break up accesses to system registers as accesses to those fields.
Describe alternatives you've considered
Manually creating a data type for all system registers, and then applying the correct type as much as possible. The downside to this is that it doesn't translate easily to another program, and you have to manually type the variables that end up containing the system register values. This is labor-intensive and error-prone. Sometimes this is infeasible, because you can't actually change the type of the system registers themselves, so you can't fix an expression such as
SCTLR_EL1 &= 0xFFFFFFFE.Additional context
I imagine this feature would improve the decompilation result for more architectures, but I only mentioned ARM because that's what I'm most familiar with.
The example
SCTLR_EL1 &= 0xFFFFFFFEwould ideally be decompiled toSCTLR_EL1.M = 0. You could argue that you still need to check the reference manual for what theMfield does exactly, but at least you should now be able to get away with just searching forMinstead of also having to decode the bitwise expression. Additionally, it's easier to recogniseSCTLR_EL1.M = 0as turning off the MMU thanSCTLR_EL1 &= 0xFFFFFFFEas doing the same.I think the best solution is to specify these bitfields in sleigh, but I think that is not possible currently.