Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Structs losing context of where they are after calls to void returning function? #7867

Open
f-raZ0R opened this issue Feb 27, 2025 · 3 comments
Assignees
Labels
Feature: Decompiler Status: Triage Information is being gathered

Comments

@f-raZ0R
Copy link

f-raZ0R commented Feb 27, 2025

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
Screenshot (2044)

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 *.

Originally posted by @astrelsky in #7864 (reply in thread)

Not sure what exactly is causing this, but it's really annoying and requires me to constantly make pointer offset overrides

@astrelsky
Copy link
Contributor

astrelsky commented Feb 28, 2025

I've known something wasn't quite right for a long time now, but this has got to be the clearest and simplest example.

Basically what seems to be happening is the type propagation system is considering r0 to be the type of the pointer to the field and is no longer considering it to be any pointer into the original struct. The information of what it is pointing into should be preserved when not killed by call.

This problem most likely occurs when the value is preserved by the caller on the stack too.

@f-raZ0R
Copy link
Author

f-raZ0R commented Feb 28, 2025

how do i upload a portion of the code for this to be reviewed again? I've seen that done elsewhere but i'm not sure what would need to be copied

@astrelsky
Copy link
Contributor

how do i upload a portion of the code for this to be reviewed again? I've seen that done elsewhere but i'm not sure what would need to be copied

It might be better to wait until requested. The information already provided might be sufficient. A trivial test case would probably be created for a test case in the decompiler anyway.

I'm probably just talking nonsense at this point though

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature: Decompiler Status: Triage Information is being gathered
Projects
None yet
Development

No branches or pull requests

4 participants