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

[GOAL] taking the address of a stack spilled variable #471

Closed
water111 opened this issue May 12, 2021 · 3 comments
Closed

[GOAL] taking the address of a stack spilled variable #471

water111 opened this issue May 12, 2021 · 3 comments
Labels
blocking-decomp Decompiler fails completely, blocking progress

Comments

@water111
Copy link
Collaborator

I was wrong - it turns out you can take the address of a variable spilled to the stack. It's done in (method 0 fact-info).

This seems like it won't be so bad to support in the decompiler. We can upgrade the stack-vars file to support this. Also should clear up "stack structure" vs. "stack variable".

In OpenGOAL we don't have any support for this yet. I think there are two parts to this:

  • Have a way to tell the compiler that a variable should be spilled onto the stack.
  • Allow taking the address of one of these.
@ManDude
Copy link
Member

ManDude commented May 28, 2021

Also in (method 18 res-lump) and (method 21 res-lump)

@water111 water111 added the blocking-decomp Decompiler fails completely, blocking progress label May 30, 2021
@xTVaser
Copy link
Member

xTVaser commented Jun 2, 2021

occurs when calling one of res-lump's methods in entity-actor-lookup in actor-link-h

@water111
Copy link
Collaborator Author

water111 commented Jun 7, 2021

This was added in #554 and seems to work pretty well.

@water111 water111 closed this as completed Jun 7, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
blocking-decomp Decompiler fails completely, blocking progress
Projects
None yet
Development

No branches or pull requests

3 participants