On top of being closer to native behavior, this helps some
games where:
- they use dbghelp to gather information of where they generate exceptions,
- they generate exception in the game play,
- and refresh their list of loaded modules in dbghelp.
This can generate some delays (~2ms per module), which affects
game play (freeze, slugginess...).
Credit to Paul Gofman for triaging this.
Signed-off-by: Eric Pouech <epouech@codeweavers.com>
Basically, showing specific behavior when calling SymLoadModule()
with a non-null base address, and that address is already
the exact base address of a loaded module.
Signed-off-by: Eric Pouech <epouech@codeweavers.com>
On MacOs, starting with Big Sur 11.0.1, the system dynamic
libraries are no longer directly accessible on disk.
They are still available through dlopen and friends. For getting
access to the images (and their debug symbol), Apple provides,
in the developper kit, the tools to extract the files. Note that
this is handled as a database of all system libraries, where ASLR
is in place such that segments of a given library are no longer
contiguous in memory (dbghelp doesn't currently handle this).
Apart from not having image information nor debug information,
another side effect is that dbghelp tries every time it refreshes the
mach-o module list to reload any library for which it didn't have
an image file. This can be lengthy (esp when a typical process has
more than 300 modules loaded).
This patch forces the creation of the dbghelp module even if the
image file isn't found.
This patch cuts startup time of 'winedbg notepad' from 9.9 to 7.4s.
YMMV.
Signed-off-by: Eric Pouech <epouech@codeweavers.com>
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>
