Hi,
While running your changed tests, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check?
Full results can be found at: https://testbot.winehq.org/JobDetails.pl?Key=77913
Your paranoid android.
=== debiant (32 bit report) ===
ntdll: threadpool.c:1904: Test failed: WaitForSingleObject returned 258
On 9/2/20 09:11, Biswapriyo Nath wrote:
-void * WINAPI RtlLocateLegacyContext( CONTEXT_EX *context_ex, ULONG *length ) +CONTEXT * WINAPI RtlLocateLegacyContext( CONTEXT_EX *context_ex, ULONG *length ) {
Did you find a definition of this function in some version of SDK (I could not)?
The thing is, RtlLocateLegacyContext does not really return a 'CONTEXT *'. CONTEXT structure definition is arch specific, while Rtl context function work for x86 and x64 contexts on any of these archs. E. g., you can call RtlLocateLegacyContext() for x86 context on x64 then the return structure will be x86 version of context which is different from what you have defined as 'CONTEXT' in x64 build. So 'void *' looks more appropriate unless there is an evidence that Windows SDk defines it another way.
I have done some tests with that function in Windows 10.
1. Call RtlGetExtendedContextLength, allocate a buffer with the returned length. 2. Pass that buffer as CONTEXT_EX to RtlInitializeExtendedContext which also returns CONTEXT in the first parameter. 3. Use that CONTEXT_EX buffer to RtlLocateLegacyContext. Now check the returned CONTEXT structure pointer with the 2nd step one.
Also there is a hint in the function name "RtlLocateLegacyContext" itself. CONTEXT_EX holds the offsets of "Legacy" context (in wdm.h). And by doing the pointer arithmetic "context_ex + context_ex->Legacy.Offset", RtlLocateLegacyContext should return a CONTEXT pointer.
I agreed with your logic and it's true. But if one wants to get the WoW-ed CONTEXT, he/she already has to set the appropriate CONTEXT pointer structure type as return value.It depends on the flag in RtlGetExtendedContextLength function.
On 9/2/20 16:40, Biswapriyo Nath wrote:
I have done some tests with that function in Windows 10.
- Call RtlGetExtendedContextLength, allocate a buffer with the
returned length. 2. Pass that buffer as CONTEXT_EX to RtlInitializeExtendedContext which also returns CONTEXT in the first parameter.
Not necessarily, the actual context data location maybe ahead of the first parameter buffer to provide alignment (there is a test for that in dlls/ntdll/exception.c:test_extended_context()).
- Use that CONTEXT_EX buffer to RtlLocateLegacyContext. Now check the
returned CONTEXT structure pointer with the 2nd step one.
Yes, sure, and there is also the test for that. But I am not sure how all that can give any clue how RtlLocateLegacyContext is defined somewhere. The patch that you introduce should not result in binary difference in the compiled code. It is not possible to test what pointer type the (undocumented) function returns, only to look that up if the function prototype is publicly available.
Also there is a hint in the function name "RtlLocateLegacyContext" itself. CONTEXT_EX holds the offsets of "Legacy" context (in wdm.h). And by doing the pointer arithmetic "context_ex + context_ex->Legacy.Offset", RtlLocateLegacyContext should return a CONTEXT pointer.
You can't guess declared pointer type from test, only test the values. That information is simply not there in the machine code and thus not testable.
I agreed with your logic and it's true. But if one wants to get the WoW-ed CONTEXT, he/she already has to set the appropriate CONTEXT pointer structure type as return value.It depends on the flag in RtlGetExtendedContextLength function.
Or that program willing to use this sort of function is a debugger and simply got that structure from somewhere. The debugger might be x64, while the debugged program might be x86 and that context has nothing to do with 'CONTEXT' defined in the headers for debugger.
I think if there is an intention to use this context management API it is strictly preferable to use kernel32 functions (like InitContext, LocateXStateFeature etc.) instead of these undocumented ntdll functions.
OK, as you wish.
-
Biswapriyo Nath -
Marvin -
Paul Gofman