Finding variable uses to fix wonky function signatures

[yrp604]

I have a function with a signature that doesn't make a lot of sense:

uint64_t sub_4014d0(int64_t* arg1, int64_t* arg2, int64_t arg3 @ x11)

004014e8  void* x0_1
004014e8  if (*(arg1 + 0x20) == 0)
00401544      x0_1 = *(arg1 + 0x38)
004014ec  else
004014ec      x0_1 = arg1 + 0x38
004014f4  int64_t* x1_1
004014f4  if (*(arg2 + 0x20) == 0)
0040153c      x1_1 = *(arg2 + 0x38)
004014f8  else
004014f8      x1_1 = arg2 + 0x38
004014fc  uint64_t x0_2 = strcmp(x0_1, x1_1, arg3)
00401500  if (x0_2.d == 0)
0040150c      x0_2 = strcmp(*arg1, *arg2, arg3)
00401510      if (x0_2.d == 0)
0040151c          x0_2 = strcmp(*(arg1 + 0x10), *(arg2 + 0x10), arg3)
00401520          if (x0_2.d == 0)
0040152c              x0_2 = zx.q(*(arg1 + 8) - *(arg2 + 8))
00401538  return x0_2

This is a relatively normal linux binary, so I'm pretty confident that it doesn't have a weird one-off calling convention. Looking at the body of the function, Im pretty sure strcmp does not take 3 arguments. Instead, what I suspect has happened here is that strcmp has something broken (probably unlifted instructions) which break dataflow, and this type propagates up to this function.

Looking at strcmp confirms this, as the function contains an instruction which would initialize x11: 00414fc0 unimplemented {clz x11, x6}. Because this value is read later, it gets added to the function signature and it propagates upwards. This behavior all makes sense and I'm good with. While this particular instance is easy to see, this type propagation can span huge callgraphs.

From the initial function where I can see the suspected brokenness (sub_4014d0), how can I find the use site for the variable I think is wrong. Said another way: from where I can see the symptom of a problem, how do I quickly navigate to its cause?

[plafosse]

So I think the answer here is Variable Cross references #234 Generally you're going to follow use sites until you find the one that is going to be live.

[yrp604]

So a combination of variable cross references and Andrew lifting everything under the sun made this a non-issue for me, so while the proposed solution does help, it doesn't seem complete to me. The core question I'm trying to answer is "what are the unlifted instructions that are actually screwing up analysis across this database", and what you're suggesting is manual process to fix specific instances.

That said, I also recognized that the provided solution is good enough in the practical case and this is probably low priority compared to other stuff, so good enough. Thanks for the reply and feature!