Function Prototype Correction

[3pidemix]

I'm noticing several functions in a Thumb2 binary that I'm working with have function prototypes that aren't correct. It's simple enough to change the type of the function accordingly, but this does not change the calling code to reflect the new prototype. In many cases different call sites show different prototypes as well. Here's one example:

debounce_rd:
int32_t r0 = [debounce].d
int32_t r2 = [data_20000e54].d
int32_t r0_1 = r0 | r2
int32_t r2_1 = [data_20000e58].d
int32_t r2_2 = r2_1 | r0_1
int32_t r0_2 = [data_20000e5c].d
int32_t r0_3 = r0_2 | r2_2
return r0_3

This function clearly takes no arguments, but for its two call sites, we have:

r0_2 = debounce_rd(r0_1, r1_4, r2_4, r3_5, __saved_r3)

and

r0_11, r1_5 = debounce_rd(r0_11, r1_5, r2_4)

This is after setting the prototype to int32_t debounce_rd(void). I would expect that explicitly setting this (which does of course trigger an analysis update) would fix the call site as well. As it stands now, it breaks some def-use/use-def analysis that I'm doing, which isn't ideal.

1. Why don't the call sites update?
2. What causes a relatively simple function like this to be mistyped? May be related to Function Parameter Propagation Issues #1456
3. What can I do to fix it? I have yet to find any analysis settings that make a difference.

[psifertex]

How did you change the prototype? Just select the function name and press y? That /should/ be the right way to do it. There's an alternative method of right-clicking and choosing override call type that is meant to only change the call at a specific location, so I just want to make sure that's not the method you're using.

[3pidemix]

Yes - that's how I'm changing the prototype (with y), which does change the prototype as expected, but has no effect on the call sites. In many cases, the actual prototype for the function is correct, it's just incorrectly displayed at the call locations. Override Call Type does correct it at the calling location(s). I'd write a script that goes through and overrides the call locations with the actual function prototype, which would fix a lot of places, but I'm not finding an API call that performs whatever override does.

Something related is the multiple return registers. In the simple example above, r1 isn't even used, and per the calling convention object it's the high_int_return_reg. However, r1_5 curiously winds up as an argument to another function that isn't showing the correct call. Manually overriding all of these functions to the default value that shows up in the resulting dialog box corrects all of them appropriately as the function analysis gets updated.

[psifertex]

The API you want is: https://api.binary.ninja/binaryninja.function-module.html#binaryninja.function.Function.set_call_type_adjustment but you definitely shouldn't have to do that. Can you share the binary?

[3pidemix]

Thanks! Slack'd it to you.

[3pidemix]

I picked this back up today, and tried a small snippet on the database to force the call type at each site, which appears to do the trick:

for func in bv.functions:
	for ref in bv.get_code_refs(func.start):
                caller_func = bv.get_functions_containing(ref.address)[0]
		caller_func.set_call_type_adjustment(ref.address, func.function_type)

But yes, it would be great if this wasn't a preprocessing step that I have to do - it seems like it should be set correctly out-of-the-gate.

[psifertex]

In summary: this looks like a bug, I've filed it as #1748 since it needs to be tracked as an issue.