Adjust code generation for the function pointer type.

[mari-mari]

Proposal

Binary Ninja knows that arg3 is a function pointer, and correctly types it in the signature of _start:

 int64_t _start(int64_t arg1, int64_t arg2, void (* arg3)())

I think we get this information but produce incorrect signature (void()):

long _start(long arg1, long arg2, void() * arg3) {
    void var_2;
    long var_3;
    var_3 = var_0;
    __libc_start_main(main, var_1, /* envp) */ &var_2, __libc_csu_init, /* ubp_av */ __libc_csu_fini, /* init)() */ arg3, /* fini)() */ &var_3);
}

Approach

Correct typing of the function pointers in the function arguments. Without digging into the code, I assume it is just the issue with the way we generate code for the function pointer types.

If this is not the case, we should examine how we lift the function pointer type (and change the title of the issue).

[mari-mari]

FYI @martinclauss

[NeoQuix]

Type is correct, the problem is how the code generator handles string generation. In your case you would have a variable with a type Pointer(FunctionTypeDef) which is used for function pointers with a string representation of void() *.

The code generator will use the type and the name to generate a string, like this: f"{var.type} {var.name} which will result in void() * name.

Because the type does not know the name of the variable in which it's used in, the f string does not work.

[NeoQuix]

After looking a bit more into the code:

• a check for that type will be the easiest and ugliest way
• a better way would have been to use the __str__ representation of Variable for the code generator, like it's done for types, but that is not possible anymore

Wasn't there a suggestion to rewrite the backend?

[rihi]

/cib

[github-actions[bot]]

Branch issue-322-Adjust_code_generation_for_the_function_pointer_type created!