SuperH: some reference issues with mov Rn, @(R0, Rm) and mov R0, @(#imm8, gbr)

[fenugrec]

Describe the bug
There are two symptoms, probably very related, for certain occurences of these two opcodes:

mov Rn, @(R0, Rm)

mov R0, @(#imm8, gbr)

To Reproduce
Steps to reproduce the behavior:

1. Load the attached dump with mostly default options. Language is SuperH SH-2A
2. analyze
3. go to address 45ec2 or 12b04

Screenshots

First, at 45ec2 : r2 = 0x040C, but that's just used as an offset, not a full address to a function that happens to exist at 040C :

00045ebe 02 dd           mov.w      @(r0,r13),r2=>DAT_ffff2cb2                       = ??
00045ec0 90 4a           mov.w      @(DAT_00045f58,pc),r0                            = 040Ch
00045ec2 0d 25           mov.w      r2,@(r0=>FUN_0000040c,r13=>DAT_ffff2cc4)         = ??

The compiler shows a much saner line :

DAT_ffff2cc4 = DAT_ffff2cb2;

Next, at 12b04 : the disasm shows the correct ref to DAT_ffff821c, since gbr was set to ffff8000 just earlier.

00012b04 c2 87 mov.l r0,@(0x21c,gbr=>DAT_ffff821c) = ??

But in the decompiler hasn't deduced DAT_ffff821c as the destination :

iVar2 = -0x8000;   // duh, that's ffff8000
...
...
*(undefined4 *)(iVar2 + 0x21c) = 0x3;

Expected behavior
Probably something like
00045ec2 0d 25 mov.w r2,@(r0,r13=>DAT_ffff2cc4)

and
DAT_ffff821c = 0x3;

Attachments
6Z68A.zip

Environment (please complete the following information):

• OS: linux
• Java Version: 18.0.1
• Ghidra Version: 10.1.4
• Ghidra Origin: archlinux build

[emteere]

This has been mostly fixed in 10.3, although if the analysis steps were done as below (function, read-only memory) it would be producing what you expect. There were some issues in the listing with constant propagation, that I believe is addressed mostly.

Make sure you make a function at the beginning of the this particular routine.
I believe the multiple value references occurred because there wasn't a function defined for that code when constant evaluation occurred.

There is also a bug that if you clear a section of code that is not in a function and you re-disassemble it, the references are computed starting at the cleared code, which can result in some bad references in some cases. If code is cleared that isn't in a function, the analysis should find the start of the function and compute constants from there. There wasn't enough time to fix this in 10.3.

Also the decompiler will not trust the values coming out of memory if it is writable. If all of you code section is read-only, you can remove the writable flag in the memory map. Otherwise you can create data at key locations and set the constant flag on the data type. This will get the references you expect in the code browser.

Be careful setting memory as read-only, if it really isn't. Initialized values like 0xDEADBEEF can show up in memory and the decompiler and analysis will use them as constants.

[fenugrec]

I regret to report that 10.3 still behaves the same in both cases.