32th-System
commented
4 years ago Yes this is prone to human error but the problem is: this would calculate a number that would most of the time be the same anyways which you may as well just specify right there in the breakpoint parameters
One idea for that I did have is to have a cavesize cache. Basically thcrap would calculate the checksum of all the patch js files that have breakpoints and a cavesize js file is generated that contains the calculated cavesizes and the checksum. If a file's checksum doesn't match the previously calculated checksum anymore, the cavesize cache for that file is regenerated.
In the end what I think would help with this issue is a debugger/disassembler feature shown in the image attached. This would make cavesizes less prone to human error while still only specifying the numerical constant that would get calculated anyways
Manually specifying the code cave size in every breakpoint is prone to human error and quickly leads to crashes if a breakpoint is pushed out untested, as seen in thpatch/thcrap-tsa@96570a1be623b4248d4de72cd1bb121e4bf8de4d. This could be avoided if we had an instruction decoder that can then automatically determine the required size of the code cave based on the code at the breakpoint location.