Also correctly handling ImageName (the passed image name
in SymLoadModule) and LoadedImageName, which is only set when
debug info have been loaded (and is always an absolute path,
contrary to ImageName which can be relative).
Signed-off-by: Eric Pouech <epouech@codeweavers.com>
Module names appear in three spots in dbghelp:
A) SymGetModuleInfo() .ModuleName
B) module enumeration (as parameter in callback)
C) in symbol/type research in module!name form
Tests show that:
- A) and B) always use only the derivation of the image
name, whatever the passed module name in SymLoadModule().
- C) can use either the form derived from image name
{as A) and B)}, but also the passed module name in
SymLoadModule().
Note: B) is limited to 64 characters, while A) is limited to 32
characters (not tested here).
Signed-off-by: Eric Pouech <epouech@codeweavers.com>
Change from: dll.so > PE image > ELF/Mach-O images
into PE image > dll.so > ELF/Mach-O images
Main goal is in SymLoadModule*(), to not resynchronize the system
modules list when requesting loading of a PE image.
This can gain quite some time in some situations.
Signed-off-by: Eric Pouech <epouech@codeweavers.com>
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>
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>
- 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>
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>
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>
Expose the real path of a loaded module (potentially read from
WINEDLLDIR or WINEBUILDDIR or overriden load order or ...). This
improves gdb integration by passing the real path to the loaded
modules (instead of the paths in c:\windows\ system subdirectories).
Introduce new Wine only dbghelp's extended option to enable the
feature.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54250
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
Basically:
- extending symt_function to enable storage of multiple address ranges
- symt_function and sym_inlinesite now share the same fields, so
get rid to the later.
Note that only the first range of a top level function is actually
stored and used (even if the structure allows for more).
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
Change strategy for resetting local scope when unloading a module.
Old strategy was keeping the local scoped symbol alive on some code path when
unloading a module.
This caused some bad behavior as we kept a pointer to a deleted object.
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
- make SymSetContext() generate this information
- let SymEnumSymboli() (when dealing with local symbols) use this
information instead of the stack frame
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
A DWZ file contains additional Dwarf debug information, and can be shared
across several debug info files.
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Split in two different (and disjoint) the functions for checking that
an alternate debug file matches the expected one
- the first based on crc
- the second based on GNU build-id
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
