[PATCH] ntdll/exception: Change return type to CONTEXT* of RtlLocateLegacyContext.

[Marvin]

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

[Paul Gofman]

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.

[Biswapriyo Nath]

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.

[Paul Gofman]

On 9/2/20 16:40, Biswapriyo Nath wrote:
> 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.

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()).
> 3. 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.

[Biswapriyo Nath]

OK, as you wish.