Skip to content

Conversation

@ab9rf
Copy link
Member

@ab9rf ab9rf commented Feb 21, 2025

This adds code to flush cache after applying a hotpatch. While it's unlikely that a patched location will be in cache at the time we apply a patch, it is better to be safe than sorry

Also fixed the spelling error in setPermissions while I was here

No changelog; this is a fix to existing functionality to avoid a potential future bug instead of fixing a known existing one

This adds code to flush cache after applying a hotpatch. While it's unlikely that a patched location will be in cache at the time we apply a patch, it is better to be safe than sorry

Also fixed the spelling error in `setPermissions` while I was here
@ab9rf
Copy link
Member Author

ab9rf commented Feb 21, 2025

side comment: i did not implement this for MacOS

@myk002
Copy link
Member

myk002 commented Feb 21, 2025

sys/cachectl.h: No such file or directory
35 | #include <sys/cachectl.h>
| ^~~~~~~~~~~~~~~~

@ab9rf
Copy link
Member Author

ab9rf commented Feb 21, 2025

sys/cachectl.h: No such file or directory 35 | #include <sys/cachectl.h> | ^~~~~~~~~~~~~~~~

any idea what it should be? that's what the documentation for cacheflush indicates is the correct header

nvm, found it (i think)

apparently the documentation i found was... incomplete
{
return cacheflush(target, count, BCACHE);
__builtin___clear_cache((char*)target, (char*)target + count - 1);
return false; /* assume always succeeds, as the builtin has no return type */
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just verifying, you return false for success?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, following the unix standard of 0 (false) for success and non-zero for failure. this is used elsewhere in DFHack for OS API calls (see, e.g. PlugLoad)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

let me be clear that i don't have a problem with returning true for success :)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems to me that returning 0 for success makes sense when the return value is an int, but if it's a bool, then it should return true for success. If this matches the semantics of the surrounding functions and is consistent across the different implementations in Process-linux and Process-windows, though, I'm fine with it.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

switched, since tbh i prefer returning true on success as well

@github-project-automation github-project-automation bot moved this from Todo to Review In Progress in 51.06-r2 Feb 28, 2025
@myk002 myk002 merged commit 203896c into DFHack:develop Feb 28, 2025
14 checks passed
@github-project-automation github-project-automation bot moved this from Review In Progress to Done in 51.06-r2 Feb 28, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

No open projects
Status: Done

Development

Successfully merging this pull request may close these issues.

MemoryPatcher does not flush instruction cache after commiting a code change

2 participants