How do I make ghidra fix pointers that can be computed?

[Martmists-GH]

for example, it gives *param_1 = PTR_DAT_7103cd0280 + 0x50, but PTR_DAT_7103cd0280 holds a pointer to DAT_71039e56d0, so wouldn't ghidra be able to rewrite this as *param_1 = PTR_FUN_71039e5720 (which should be its vtable)?

I tried running a bunch of analysis tasks already but that didnt fix it, and I couldn't find a script to fix this.

[Wall-AF]

Need much more context here!

[Martmists-GH]

There are currently no data structures (the one in the C code below is an auto-struct). The asm is

      71006efd2c 08 41 41 f9     ldr          x8,[x8, #offset PTR_DAT_7103cd0280]                                      = 71039e56d0
      71006efd30 81 06 40 f9     ldr          x1,[x20, #0x8]
      71006efd34 09 41 00 91     add          x9,x8,#0x10
      71006efd38 08 41 01 91     add          x8,x8,#0x50
      71006efd3c 89 02 00 f9     str          x9=>PTR_FUN_71039e56e0,[x20]                                             = 7100d04a30
      71006efd40 88 12 00 f9     str          x8=>PTR_FUN_71039e5720,[x20, #0x20]                                      = 7100d04a34

and the C code is:

  puVar1 = PTR_DAT_7103cd0280 + 0x50;
  *(undefined **)param_1 = PTR_DAT_7103cd0280 + 0x10;
  *(undefined **)&param_1->field_0x20 = puVar1;

It looks like the asm is correct, but it's not correctly reflected in the C code for some reason.

[Wall-AF]

That's your problem. You need to create appropriate data structures when none of the default ones are appropriate. That's one of the facets of performing reverse engineering! Good luck.

[Martmists-GH]

That's not the problem. The problem is that the C code shows PTR_DAT_7103cd0280 + 0x10 instead of PTR_FUN_71039e56e0.

[Wall-AF]

After looking at the definition for ldr the register x8 should be set prior to the code shown and the #offset ... is relative to that. I'm getting out of my depth now as I'm into x86. Sorry.

[dt-12345]

Is the section that the data in marked as read-only? Ghidra can't optimize away the pointer dereference if it's pointing to non-const data.
I've experienced this with some Nintendo Switch binaries that are also AArch64 - many newer binaries moved some previously read-only data into new, non-read-only sections which caused this kind of decompilation which can be resolved by marking those sections as read-only.