Pretty sure this function needs to be defined in some special way, not sure how to do so [ARMv6]

[f-raZ0R]

Okay, so there's this function, and a couple others like this, which definitely don't seem to be using standard calling conventions, but I'm not sure what to change it to, to get things decompiling correctly.

This seems to be for some sort of memory thing? It pops up to reset variables inside of classes in vtable functions and the like, however it's "output" is just... wrong. "iVar2" is just.. also param1 at an offset of 0x3c. So for example, the second call of the "trash" function takes param1->0x34, and the third call takes param1->0x30. I can get the correct behavior here, by manually creating pointer offsets at every time this function is called, but that... really sucks for both readability, and because I have to keep doing it every single time. Since it should just be spitting out a pointer offset of "whatever it takes in", what do I even define it as? Marking it as no-return just breaks things, making it return a different register doesn't fix the problem either, etc.
here's the bytecode of where the function is being called as well, for reference.

What do I do to this function to get things decompiling correctly?

[f-raZ0R]

If its relevant, param_1 is a class, that I am representing as a struct due to ghidra's current inability to represent classes. TrashTStringInstancePlus**? seems to only ever be called on Classes.

[astrelsky]

It's hard to tell what register param_1 is, but it looks like it should not be "killed by call". It should be thiscall.

If the register is r0, I suspect you would only see this for functions that don't return anything, otherwise r0 would be "killed" by the return value.

[f-raZ0R]

yeah, param_1 is the r0 register. Issue is that changing the calling convention to __thiscall ends up with r0 just being forced to be void*, and changing TrashTStringInstancePlus to be a noreturn ends up ending all functions that call it early, due to it being a flow override. This is... extremely not ideal. Changing TrashTStringInstancePlus to return void just results in.. this, which isn't ideal either

How do I make r0 not killed by the call?

[astrelsky]

yeah, param_1 is the r0 register. Issue is that changing the calling convention to __thiscall ends up with r0 just being forced to be void*, and changing TrashTStringInstancePlus to be a noreturn ends up ending all functions that call it early, due to it being a flow override. This is... extremely not ideal. Changing TrashTStringInstancePlus to return void just results in.. this, which isn't ideal either

How do I make r0 not killed by the call?

This picture is technically correct but really stupid. I would consider this to be a decompiler bug as it seems like it is losing the context of where it was in the struct.

Setting it to thiscall without a class namespace will just get you a void *.