Latest available version: IDA and decompilers v8.4.240527sp2 see all releases
Hex-Rays logo State-of-the-art binary code analysis tools
email icon

In some cases, especially for indirect calls, the decompiler cannot correctly detect call arguments. For a call like

        push something
        mov  eax, [ecx]
        call [eax+8]

it is very difficult to determine where are the input arguments. For example, it is unclear if ECX is used by the call or not.

However, the number of arguments and their types can become available at later stages of decompilation. For example, the decompiler may determine that ECX points to a class with a table of virtual functions. If the user specifies the vtable layout, the output may become similar to

        ((int (*__stdcall)(DWORD))ptr->vftable->somefunc)(v1);

If the user declares somefunc as a pointer to a function like this:

        int __thiscall (*somefunc)(myclass *obj, int arg);

then the code is incorrect. The decompiler detected only one argument and missed the one in ECX.

The 'force call type' command instructs the decompiler not to perform the call argument analysis but just use the type of the call object. For the above example, the call will be transformed into something like

        ptr->vftable->somefunc(obj, v1);  // obj is in ECX

In other words, this command copies the call type from the call object to the call instruction. The call object may be any expression, the only requirement is that it must be a pointer to a function.

There is a more general command Set call type that allows the user to set any type for a call instruction.

NOTE: Behind the scenes the 'force call' command copies the desired type to the operand of the call instruction. To revert the effects of 'force call' or to fine tune the forced type please use the Edit, Operand type, Set operand type in the disassembly view while staying on the call instruction.

See also: interactive operation