asar
asar copied to clipboard
RPGHacker
Option for retrieving read byte offsets
Similar in spirit to #364, it can be useful to know for build systems which bytes were read during the application of a patch in order to "reject" the possibility that re-applying it would yield a different result.
For example, imagine a patch A checks some bytes that are written to by a patch B, say for compatibility reasons. If we reapply or remove B and we're being conservative and don't know what A read, then we must always re-apply A, because in theory A could have read any location written to by B and changed its behavior based on those read bytes. In contrast, if we did have access to the bytes read by A, then if those bytes remain unchanged after the removal/reapplication of B, we know for a fact we do not have to re-apply A and can simply skip it.
Imagine this as a natural counterpart to writtenblocks, I guess. Probably more niche than what I proposed in the other issue, but could help improve accuracy/speed in my build system and others in the future.
for your imaginary scenario, you also need to check that A and B don't overwrite each others' bytes, otherwise you need to get the bytes of whichever is applied last. doing this stuff correctly in general feels like it could get quite gnarly, but if you think you can wrangle it, feel free to try.
would you want this stuff tracked for all touched files, or just the main rom? doing it for everything feels like it might add noticeable overhead to patching.
...though i suppose it could have overhead anyways, so we would probably add a patchparams flag to enable it, so you wouldn't get it unless you asked for it.
also i just realized using the freespace finder in any capacity would "read" most of the bytes of the rom. not sure what exactly to do about that.
would having patches manually declare their dependencies be too much effort?
for your imaginary scenario, you also need to check that A and B don't overwrite each others' bytes, otherwise you need to get the bytes of whichever is applied last
I'm already doing that anyway, tools/patches overwriting each other's bytes is something I currently can already detect cause it's easy to tell just from inspecting the ROM before and after insertion.
would you want this stuff tracked for all touched files, or just the main rom? doing it for everything feels like it might add noticeable overhead to patching.
I just had the ROM in mind.
also i just realized using the freespace finder in any capacity would "read" most of the bytes of the rom. not sure what exactly to do about that.
I was mostly just thinking about the read() family of functions, since that's the only mechanism I'm really aware of patches using to read ROM bytes to alter their own insertion. Are there even others that could be used by resources to do this?
would having patches manually declare their dependencies be too much effort?
The issue is that that's not a formal process. First patch authors would have to actually declare their dependencies, already a tall ask, then users would have to translate those verbally stated dependencies into actual configuration of the build system, maybe even less likely to happen.
I'm not saying this is super important for me, not nearly as important as the other issue would be anyway, but it would still be useful, at least potentially, so I thought I'd bring it up just in case.