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

Suggestion: "auto PROTECT" #5

Open
StanHash opened this issue Aug 8, 2018 · 2 comments
Open

Suggestion: "auto PROTECT" #5

StanHash opened this issue Aug 8, 2018 · 2 comments

Comments

@StanHash
Copy link
Member

StanHash commented Aug 8, 2018

something like

PROTECT_AUTO

ORG $BEEF
    SHORT $2000 $0001 // mov r0, #0; mov r1, r0

PROTECT_AUTO_OFF

ORG $BEEF
    // This should through an error, as a previous write to this area was auto protected
    SHORT $2042 $2100 // mov r0, #0x42; mov r1, #0

Everything written between PROTECT_AUTO and PROTECT_AUTO_OFF would be "auto-protected" (as if PROTECT was used for each region of data that was written).

The benefit of such feature would be to make protecting sequences of many "hooks" (ORG p; xyz) more easily feasible. The benefit of doing that would be to ease finding conflicts between modules (hacks) that hook into the original binary (ROM).

I guess we could also get that benefit from doing that on a global scale (maybe through a command-line option that would disallow multiple writes to the same area?).

Of course regular PROTECT needs to be fixed first.

@StanHash
Copy link
Member Author

StanHash commented Aug 9, 2018

Some clarifications/notes on the current """solutions""" we have to the problem:

{
label:

PUSH
    ORG x
        stuff

    ORG y
        stuff
POP

PROTECT label CURRENTOFFSET
}

Doesn't solve the problem (doesn't do anything meaningful at all even).

PUSH
    ORG x { label:
        stuff
        PROTECT label CURRENTOFFSET
    }

    ORG y { label:
        stuff
        PROTECT label CURRENTOFFSET
    }
POP

Would work but:

  • Becomes unnecessarily tedious very quickly (even if using hypothetical Protected(stuff) macros imo, which can't be used with stuff like #incbins anyway (unless ColorzCore changed that in which case disregard this last bit I guess)).
  • Doesn't work for existing hacks without potentially many (again, tedious) edits, and with the possibility of forgetting something.
  • Doesn't allow putting labels in unless you remove the scope (and if you do, you end up potentially polluting the global namespace more, as well as making it harder to encapsulate the logic into macros).

What I'm trying to allow is just doing something like this:

PROTECT_AUTO
#include "Item Effect Revamp/EA Main Installer.txt"
PROTECT_AUTO_OFF

(While installing this hack before most of everything else). This would be to make sure the installed hack (especially hooks) doesn't conflict with anything else.

@Crazycolorz5
Copy link
Member

This is kinda the next low-hanging fruit I'll tackle when I hack on ColorzCore again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants