On Thu Oct 5 19:35:47 2023 +0000, Alexandre Julliard wrote:
That's not very nice. Do we really need to export that info in the first place? And if so, do we really need to abuse an existing API structure?
we are already abusing this structure in many ways:
* decorate module name to advertize if the module is an host (elf/mach-o) module (vs PE module) * override meaning of some fields (eg dwarf info) * exposing real unix path of loaded image (needed to pass it to gdb in proxy mode)
most of these behaviors are only activated when setting some wine specific dbghelp's options (which are defined in dbghelp.h), but still have some limitation:
* module name decoration shortens the effective module name, with potential name clash * dwarf information is not protected by wine only option (but that's simple to change) * some of the override above shadow some information ; luckily as of today, the context of the call in winedbg decides whether to ask for the overridden value
but the core of the question is:
* do we reimplement on winedbg side a good part of what already exists in dbghelp (for example, list of loaded modules on winedbg side has been added to keep track of TLS debug directory information from PE image) * exposing native/builtin nature of PE images (IMO interesting for user report perspectives to detect module overrides): this can be done on winedbg side, but requires actual path to loaded module (cf gdbproxy) + query:ing image ; this could be simply exposed from dbghelp
so the more we stick to a pure dbghelp definition, the more we reimplement on the winedbg side
as an example, the real unix path of a module (which is gotten from the file handle passed in load dll debug event) could be only stored in winedbg but this would require rewriting a couple of winedbg functions using the internal winedbg module list rather than calling dbghelp for loaded modules
or the system vs PE image nature can also be obtained on winedbg side
I was more tempted not to replicate code and concentrate at most in dbghelp at the expense of twisting some API's output ; but I'm fine with the other way too