[PATCH 0/1] MR112: Revert "dbghelp: Don't bother trying to initialize loader backend if we can't...

[Jinoh Kang (@iamahuman)]

On Mon May 23 12:04:35 2022 +0000, eric pouech wrote:
> > of Unix modules.  Specifically, dbghelp attempts to fetch it from the
> > WoW64 PEB although it actually resides in the native PEB.
> Actually, getting back to the correct 'base address' should be taken
> care of in previous lines of check_live_target
> So I'd say we'd better fix the reason for not getting to the base
> address (if needed).
> can you describe further:
> - are you trying to debug an active process (or not)?
> - is debuggee 32bit or 64bit?
> - is dbghelp 32 or 64bit?
> Notes:
> - 32bit dbghelp will not be able to handle 64bit processes, so I hope
> it's not what you're trying to do
> - 64bit dbgjelp is able to load 32bit process only if
> SYMOPT_INCLUDE_32BIT_MODULES is set in options before loading the
> relevant modules (so before SymInitialize when fInvade is TRUE)
> > However, this shouldn't be a reason to give up initializing dbghelp
> > entirely.  We do not expect a "user-mode" debugger to be able to debug
> > Unix-side modules in a WoW64 process anyway.
> why wouldn't we (at least for the 64bit version of dbghelp)?
> are you trying to debug an active process (or not)?

Yes, I'm trying to debug an active process.

> is debuggee 32bit or 64bit?

32bit, Wow64 *proper*.  (Of course, this means that the bug cannot be triggered without modification to upstream code.)

> is dbghelp 32 or 64bit?

64bit.

-- 
https://gitlab.winehq.org/wine/wine/-/merge_requests/112#note_1098