Add infrastructure to generate fake .PDB files.
Only done in DS format.
I'm not sure we care about JG anymore, DS format has been introduced
by MS in early 2000 to supersede JG, and is still mainstream today).
For the record, LLVM in its PDB handling doesn't support JG format.
Signed-off-by: Eric Pouech <epouech@codeweavers.com>
Note: the 32bit tests in new wow mode are still marked
todo as the ELF debug header is located above the 4G limit
and "default" module management in dbghelp compiled in 32bit
is (mostly) done with 32 bit addresses.
The correct fix should be to always consider ELF (and macho-O)
modules with 64bit addresses (which means likely to move all
modules handling to 64bit even in 32bit compilations).
But that goes far beyond this patch.
This limitation will only impact debuggers compiled in 32bit,
using 32bit builtin dbghelp on a 32bit debuggee.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=55058
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=55096
Signed-off-by: Eric Pouech <epouech@codeweavers.com>
Tests on PE image (header part, no debug directory).
Add infrastructure to generate PE image (derived from
kernel32/tests/loader.c).
Signed-off-by: Eric Pouech <epouech@codeweavers.com>
- correctly taking into accoung SYMOPT_INCLUDE_32BIT_MODULES option
- converting, for 32bit modules requested from a 64bit module,
the system32 paths into syswow64
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
This fixes some crashes especially when dealing with very long C++ names
(like template classes).
Fortunately, dwarf internals don't require type lookup by name (eg.
on forward declaration), so the impact of thrashing some names is limited.
It's very likely native doesn't store directly these very long names
(it could either store the qualified mangled name - which can be way shorter
for template classes - or use the names in lexical hierarchy: both boil down
to storing less information, and recompute it (unmangle or class hierarchy
walk) upon request).
But this would need a proper C++ support in dbghelp. Not for today.
Signed-off-by: Eric Pouech <epouech@codeweavers.com>
Currently, dbghelp returns the source file either:
- in DOS format when native module option isn't enabled
- as stored in debug info format otherwise
This used to work for PE modules inside ELF shared libraries but is broken
since evolution to REAL modules. This generates several issues:
- winedbg does not always set the native module option when calling dbghelp
for source file related functions, leading to heterogenous output to user
- some dbghelp function rely on matching source paths, hence leading to
errors in winedbg when mixing the two formats for the same source file.
Introduce a new Wine only dbghelp option to return the source paths as they
are stored inside debug information format, and activate it unconditionaly
inside winedbg.
This fixes some failure cases of command 'break <NN>' in winedbg.
Signed-off-by: Eric Pouech <epouech@codeweavers.com>
Under Windows 11, notepad.exe has been migrated into the UWP framework,
and can no longer be launched as a 32bit process:
- even if c:\windows\syswow64\notepad.exe is still a 32 bit PE file
- the process created from c:\windows\syswow64\notepad.exe is not a
wow64 process.
So use msinfo32.exe instead. Like notepad.exe, it's a gui application,
present on Wine and all test-bot:ed windows platforms. But unlike
notepad.exe, it's not an UWP app on Windows 11.
(May not fully fix all the bugs below, but will get rid of a bunch
of errors).
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54535
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54536
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54537
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
- should have been fixed when libwine.so has been removed
- code was broken anyway
- enhanced protect against error when reading debuggee's memory
Introducing helper to correctly read pointer's from debuggee
(and other integral values).
vdso is now listed in ELF's module list (except if Wine's preloader
removes it from auxilary vector)
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
For dbghelp in 32-bit, when accessing a live debuggee in multi-arch
configuration, Wine's ELF loader is likely mapped above 4G, hence
not accessible with 32bit Windows APIs.
So don't try to expose the ELF libraries in that case.
Introducing a new loader operation class to support live targets, for
which system operations are not accessible, but pretending they are
successful.
Note:
- when Wine's loader ELF module isn't registered by dbghelp,
any other ELF module will not be registered by dbghelp.
- further work may be needed for winedbg in auto mode (launched with
AeDebug key on process exception) as in that mode winedbg
doesn't relaunch itself in 64bit, so won't be able to access
(64bit) ELF information (in multi-arch configuration).
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
Since this API sporadically fails with STATUS_INFO_LENGTH_MISMATCH
as GetLastError() (sic!) on Windows 11, retrying the call let us get
the relevant output.
No clear explanation of the cause of the failure, it's maybe generated
when modules are still loaded into child process and it detects
modification of the modules' list while enumerating all modules.
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
Even is MSDN states that it enumerates modules' name, the first parameter
to the callback is the fullpath to the image.
So
- fix EnumerateLoadedModules() to pass the image name for the
considered module
- fix all callbacks in Wine code to EnumerateLoadedModules to
handle the image name instead of module name
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
Note: from now on, winedbg will 'see' the ELF 64 bit modules (not yet
the PE ones) in multi-arch wow64 use case.
Modules can be displayed in 'info wow share' command and their debug
information is loaded.
Stack manipulation and backtracking are not available.
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
