Different Variables in Source Code are Merged into a Single Variable in Decompiled Code

[hackhaye]

Recently, I met an decompilation problem in Ghidra 11.3.1 (The same issue exists in 11.2.1 too).
in unstripped binary with symbol, the code is shown as below. return value is iVar7, and first argument of array_insert_value is paVar9, which are different variables.

int config_set_defaults(server *srv)
{
  ...
  int iVar7;
  int iVar8;
  array *paVar9;
  ...
  
   iVar7 = -1;
  if (0 < iVar6) {
     ...
      paVar9 = (srv->srvconf).upload_tempdirs;
      sVar10 = strlen(__s);
      array_insert_value(paVar9,__s,(uint32_t)sVar10);
     ...
      }
	...
  return iVar7;
}

But when it comes to stripped version, the code becomes:

undefined8 config_set_defaults(long param_1)
{

  undefined8 uVar10;
  ...
  uVar10 = 0xffffffff;
  if (0 < iVar6) {
     ... 
      uVar10 = *(undefined8 *)(param_1 + 0xb0);
      sVar7 = strlen(__s);
      array_insert_value(uVar10,__s,sVar7 & 0xffffffff);
    }
   ...
  return uVar10;
}

the first argument and return value are both uVar10 .
I'm very curious about what problem has caused this issue. How to solve it through ghidra script?

[f-raZ0R]

Is there also a return inside of the if statement?
Seems like the return uVar10 will never happen while it's already been set to upload_tempdirs, and the two values are in the same stack pointer, so ghidra is just going "well, seems like they're the same variable to me!"

[ReversingWithMe]

If you wanted specific resolution to this still, you’d need to post the disasm, but it’s very normal for the compiler to reuse and optimize for variable storage. Depending on instructions they possibly could be stored in the same place, and you’d need to tell ghidra to split the variable in the GUI.