Adds a context callback function that is invoked before the detour itself.
Only supports x86 and x64, as that is all I had in the source of the port.
Is this acceptable? It should fail when attempted on another architecture in this PR; does it need to work on all supported architectures?
The additional bytes required for every trampoline are likely to be viewed as a problem. Because of that, I made it a conditional compilation feature. The interface remains the same, but if one attempts to pass in a callback without having compiled in support, the detour attach fails.
Other issues that @jaykrell pointed out, but don't seem to be necessary for the shipping use case:
The "trampoline" only preserves the integer fastcall registers, not the floating point registers. Since the shipping use case is to call TlsSetValue, this doesn't end up being an issue.
No pdata/xdata equivalents are created (presumably via RtlAddFunctionTable) for the "trampoline". This doesn't appear to be an issue for the shipping use case, but I agree that it is undesirable for general use.
Adds a context callback function that is invoked before the detour itself.
Only supports x86 and x64, as that is all I had in the source of the port. Is this acceptable? It should fail when attempted on another architecture in this PR; does it need to work on all supported architectures?
The additional bytes required for every trampoline are likely to be viewed as a problem. Because of that, I made it a conditional compilation feature. The interface remains the same, but if one attempts to pass in a callback without having compiled in support, the detour attach fails.
Other issues that @jaykrell pointed out, but don't seem to be necessary for the shipping use case:
TlsSetValue, this doesn't end up being an issue.RtlAddFunctionTable) for the "trampoline". This doesn't appear to be an issue for the shipping use case, but I agree that it is undesirable for general use.Microsoft Reviewers: Open in CodeFlow