MIPS decompiler struggles with different alignment field access

[DualTachyon]

Describe the bug

It is common for some MIPS compilers to access a field in a structure with a different type alignment.
For example, when I specify that a specific field is a byte or a 1 byte enum (e.g. a bit mask), and Ghidra finds an access as 32bit, the decompiler will cast the access as 32bit and show some less than readable code. In my case, it makes the use of enums less useful.

I have seen this problem in different operations: testing a bit (very common), changing a bit (very common), and even addition in one case in the top 16 bits where there was a "ushort" (only one occurence in the database I'm using).

To Reproduce

1. Load the a.o attached (or build from attached source if preferred, source assumes Little Endian)
2. Create a structure of 8 bytes in size with: struct { byte a; byte b; undefined; undefined; uint c; } test_t;
3. Change the type of param1 to " test_t * ".
4. Observe the code as in my screenshot

If you find my sample code strange, it is a representation of real code generated by GCC in some platforms.

Expected behavior

I would expect Ghidra to detect that "param1->b" is being tested (if Ghidra knows it's a bit operation, if that matters) and produce the source as "if (param1->b & 1)".

Screenshots

Attachments

field.zip

Environment (please complete the following information):

• OS: Windows 10
• Java Version: 11.0
• Ghidra Version: 10.1.3
• Ghidra Origin: Official release

Additional context

I'm not sure if this should be a bug report or a feature request. I haven't seen this kind of problem in other platforms (e.g. ARM/X86/X64). I feel also that handling this for anything but bit operations would possibly be difficult / bug prone, so I'm not expecting that such operations (add/sub/etc) would be supported.

[IvanDSM]

I believe the offseted pointer support that was recently added to master might solve this issue - will build the latest commit and check.

[IvanDSM]

Analyzing the a.o in the field.zip file you provided with a build based off of 3b09371 results in a similar decompilation error:

It's worth noting however that the same issue I had with offseted pointers happens here: the decompiler isn't aware of the fact that the if condition references param_1->a, but the program listing seems to be. Note that the lw instruction that loads a into v0 references param_1->a properly:

I feel like this is a failure of the offseted pointer feature, and might be related to #4224. I will add a comment there to show my similar problem with the program listing being aware of this type of reference, but not the decompiler.