[PATCH 3/3] dbghelp: fix failing SymInitialize for a live 32bit target from a 64bit caller in WOW64

[Eric Pouech]

Le 31/08/2021 à 15:32, Alexandre Julliard a écrit :
> Eric Pouech <eric.pouech at orange.fr> writes:
>
>>> Offsetting by 0x1000 is fine.
>>>
>>> But I'd say that the ELF data should be stored in the 64-bit PEB. Also
>>> note that once the new Wow64 architecture is enabled, all ELF data
>>> inside 32-bit processes is going to be 64-bit.
>>>
>> ok I'll resend the serie with just offsetting for now.
>>
>> is there a way to test the new WoW64 arch before it's enabled?
> You can try the patch below. Note that you need to apply the
> ntdll-NtAlertThreadByThreadId series from wine-staging first.
>
thanks


didn't run into anything dramatic ;-)

no specific issues on dbghelp testing on my side


as I understand the new DLL scheme (for a WOW64 DLL on 64bit cpu)

- wine loader will always be a 64bit ELF

- all ELF required libs will be loaded as 64bit ELF into that process

- PE module will be 32bit PE but with thunks to 64bit code for 
interaction with ELF DLLs

one of the current interest of winedbg was the ability to show both the 
PE modules and the ELF modules and debug both

this will open a nice can of worms as it would require multiple CPUs 
support for the same process :-(


MS debugger has the ability to switch back and forth between the two 
worlds (ie set CPU), but requires specific command to display a combined 
(mutli CPU) backtrace


note: your patch doesn't apply cleanly on top of 
wine-staging/ntdll-NtAlertThreadByThreadId

(some stuff in common on the wine-staging series and the patch ; I hope 
I got the conflict resolution right)


A+


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20210901/b761672d/attachment-0001.htm>