Here is assembly:

  mov     rdi, [r13+rax*8+0]
  sub     rdi, rcx
  cvtsi2sd xmm0, rdi
  movsd   qword ptr [r11+rax*8], xmm0
  cvtsi2sd xmm0, qword ptr [r14+rax*8]
  movsd   qword ptr [rsi+rax*8], xmm0
  add     rax, 1

And here is an output from Hexrays decompiler

      v32[v34] = (double)(LODWORD(v11[v34]) - (int)var1);
      v33[v34] = (double)(int)v10[v34];

issue: v10, v11 and var1 are declared as __int64* and __int64. Any ideas why decompiler converts them to 32 bit integers? I see those being moved to 64 bit registers. This is an ELF64 executable

  • Can you show how rcx was initialized? It could make sense if it's by movsxd rcx, ... – wisk Jan 26 at 4:24
  • IDA has never been great with floating point numbers, and even if it were -- there are some really crazy programming tricks (often used in graphics and gaming) that rely on treating floats as integers (and back). That said, IDA can usually be bought into line if all the variables in question are defined as floats (or arrays of floats -- vectors), and/or some structures (e.g. struct vec4 { float f[4]}; }) sprinkled around the place. I would (for example) try defining v32, v33 and v11 as vec4 and see what it shows. – Orwellophile Mar 1 at 11:01

Hard to say without the binary or at least the full function but possibly it happens because of cvtsi2sd.

According to the documentation, the instruction treats the input as “signed doubleword integer”. (Doubleword is 32-bit on Intel)

  • Makes sense, the only problem is with LODWORD which converts it to UNSIGNED integer. I tried replacing LODWORD with (int) and recompiled coded behaves just like the the original binary. But with LODWORD results are incorrect – pete71 Jan 27 at 0:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.