https://bugs.winehq.org/show_bug.cgi?id=54250
Bug ID: 54250 Summary: winedbg loads wrong debug symbols for builtin dlls Product: Wine Version: 7.2 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winedbg Assignee: wine-bugs@winehq.org Reporter: ake.rehnman@gmail.com Distribution: ---
Created attachment 73804 --> https://bugs.winehq.org/attachment.cgi?id=73804 Patched winedbg attempt
Winedbg loads the wrong debugging info for dlls where a native dll exists in the prefix and the native dll is replaced with the built-in version.
For instance the lpImageName in the DEBUG_EVENT struct contains the path to the C:\Windows\System32\somedll.dll but it is replaced with the built-in version from the build directory (in my case) that is actually mapped in to memory. So in this case winedbg loads the debug symbols from from the system directory and not the one that is in the build directory.
However it looks like if calling NtQueryInformationFile with the file handle we get the correct name to the loaded dll. See the attached patch how I solved the issue.
https://bugs.winehq.org/show_bug.cgi?id=54250
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch
https://bugs.winehq.org/show_bug.cgi?id=54250
Eric Pouech eric.pouech@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Assignee|wine-bugs@winehq.org |eric.pouech@gmail.com Status|UNCONFIRMED |ASSIGNED CC| |eric.pouech@gmail.com
--- Comment #1 from Eric Pouech eric.pouech@gmail.com --- Created attachment 73816 --> https://bugs.winehq.org/attachment.cgi?id=73816 alternative patch
Hi,
thanks for the feedback. Yes sometimes winedbg (in fact dbghelp DLL) have slightly different image lookup implementation. Does the attached patch work?
https://bugs.winehq.org/show_bug.cgi?id=54250
--- Comment #2 from ake.rehnman@gmail.com --- Hi,
unfortunately the alternative patch does not work.
https://bugs.winehq.org/show_bug.cgi?id=54250
--- Comment #3 from ake.rehnman@gmail.com --- It does seem it is loading the correct symbol table with the alternate patch but it is still wrong somehow...
https://bugs.winehq.org/show_bug.cgi?id=54250
--- Comment #4 from Eric Pouech eric.pouech@gmail.com --- I'm not sure to get fully your situation: what I understand is: - you use wine from the build tree (compilation by yourself, wine not installed) - you run wine from the build tree - in that case the system dlls from c:\windows\system in the prefix are copied from the build tree, so it shouldn't change using one or the other
would you mind describing: - how things are invoked (if different from above) - what let you think you get the wrong debug info?
TIA
https://bugs.winehq.org/show_bug.cgi?id=54250
--- Comment #5 from ake.rehnman@gmail.com --- (In reply to Eric Pouech from comment #4)
I'm not sure to get fully your situation: what I understand is:
- you use wine from the build tree (compilation by yourself, wine not
installed)
- you run wine from the build tree
- in that case the system dlls from c:\windows\system in the prefix are
copied from the build tree, so it shouldn't change using one or the other
would you mind describing:
- how things are invoked (if different from above)
- what let you think you get the wrong debug info?
TIA
It is correct, I am running from the build tree. How ever if there is a *native* windows dll in the prefix it is by default overridden by the builtin version in the build tree. But when winedbg tries to load the symbol table for the builtin dll it was loading the debug symbols (or at least the exports) from the native windows dll.
With the "alternate patch" it looks like it is loading the debug symbols from the dll in the build tree. But the debug symbols still points to the wrong addresses.
I am going to dig a little more to see where it goes wrong...
https://bugs.winehq.org/show_bug.cgi?id=54250
--- Comment #6 from Eric Pouech eric.pouech@gmail.com --- 1) I assume you're using WINEDLLOVERRIDES to force loading of native (in prefix) instead of wine's builtin (in tree) 2) can you post the WINEDEBUG=+dbghelp trace
https://bugs.winehq.org/show_bug.cgi?id=54250
--- Comment #7 from ake.rehnman@gmail.com --- (In reply to Eric Pouech from comment #6)
- I assume you're using WINEDLLOVERRIDES to force loading of native (in
prefix) instead of wine's builtin (in tree)
Actually it is the other way around. There are a number of native dlls in the System32 directory but those are replaced with the built-in in my build tree.
- can you post the WINEDEBUG=+dbghelp trace
Good news! Wine-dbg actually loads the correct symbols with the alternate patch. So this is working. BUT I am usually running Winedbg as a gdb-server and THEN the symols gets screwed up.
So when I use Wine-dbg interactively I can set breakpoints on the functions in the built-in dlls and everything works. But when I switch to gdb and run Wine-dbg as gdbserver I get the symbols for the NATIVE dlls. Weird...
https://bugs.winehq.org/show_bug.cgi?id=54250
--- Comment #8 from ake.rehnman@gmail.com --- Created attachment 73823 --> https://bugs.winehq.org/attachment.cgi?id=73823 alternative patch 2
https://bugs.winehq.org/show_bug.cgi?id=54250
--- Comment #9 from ake.rehnman@gmail.com --- gdb also needs the path to built-in ddls
https://bugs.winehq.org/show_bug.cgi?id=54250
--- Comment #10 from Eric Pouech eric.pouech@gmail.com --- hi
your addition looks correct since Wine's currently is in code freeze (only bug fixes allowed), I'm a bit worried by the changes: at least the one I proposed <g>. As it changes the code path for every PE loaded, it may uncover some other bugs. (Like not updating LoadedImageName accordingly).
Even if its the right thing to do (using the hFile from the load DLL debug event, hence passed by the system), I'm a bit reluctant to create a merge request from it.
Question: I wonder if your change alone (without passing hFile) produces the same right effects (at least on gdb-proxy mode)?
A+
https://bugs.winehq.org/show_bug.cgi?id=54250
--- Comment #11 from ake.rehnman@gmail.com --- (In reply to Eric Pouech from comment #10)
Question: I wonder if your change alone (without passing hFile) produces the same right effects (at least on gdb-proxy mode)?
It does not work without hFile, not in wine-dbg nor gdb.
https://bugs.winehq.org/show_bug.cgi?id=54250
Eric Pouech eric.pouech@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #73816|0 |1 is obsolete| |
--- Comment #12 from Eric Pouech eric.pouech@gmail.com --- Created attachment 73827 --> https://bugs.winehq.org/attachment.cgi?id=73827 proposed patch
thinking a bit more about the fix, there are still a couple of things to iron out: - the first issue stems from the load dll debug event passing the filename as c:\windows\system while hFile is opened on the overridden DLL in the build tree - this is done to hide from regular applications the wine internal redirections (like buildtree) - so we shouldn't expose that redirected filename to regular app (so I changed the patch to only retrieve the redirected path when some wine extensions are enabled instead of always exposing the redirected filename) - also, if we have a valid hFile from the DLL load event, we shouldn't look for redirection (especially since it's passed by the system, hence ensuring that it's opened on the loaded module...). so I changed the patch to get the redirected filename from the file handle (inserting back your first patch, yet modified)
so the attached patch should be cleaner IMO
https://bugs.winehq.org/show_bug.cgi?id=54250
--- Comment #13 from ake.rehnman@gmail.com --- Something is broken with the "proposed patch" ...
(gdb) target remote localhost:38453 Remote debugging using localhost:38453 warning: remote target does not support file transfer, attempting to access files from local filesystem. Reading symbols from /home/are/project/xwinetest/rectangle.exe... warning: while parsing target library list: not well-formed (invalid token) 0x000000017006d755 in ?? ()
https://bugs.winehq.org/show_bug.cgi?id=54250
Eric Pouech eric.pouech@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #73827|0 |1 is obsolete| |
--- Comment #14 from Eric Pouech eric.pouech@gmail.com --- Created attachment 73829 --> https://bugs.winehq.org/attachment.cgi?id=73829 proposed patch
silly me and last minute change <g> should be better by now ;-)
thanks for baring with me
https://bugs.winehq.org/show_bug.cgi?id=54250
--- Comment #15 from ake.rehnman@gmail.com --- Something is not right. The path we get from NtQueryInformationFile does not contain the prefix or drive for things in the C:\Windows\System32 dir...
Ex 0020:0024:fixme:dbghelp:pe_load_native_module LoadedImageName=L"C:\windows\system32\USP10.dll" name=L"C:\windows\system32\USP10.dll" real_path=L"\Windows\System32\usp10.dll"
https://bugs.winehq.org/show_bug.cgi?id=54250
Eric Pouech eric.pouech@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #73829|0 |1 is obsolete| |
--- Comment #16 from Eric Pouech eric.pouech@gmail.com --- Created attachment 73835 --> https://bugs.winehq.org/attachment.cgi?id=73835 proposed patch
another try <g>
I also splitted the patch in pieces for creating the merge request. Let me know if: - your name is correct - you agree for submission for your derived code
https://bugs.winehq.org/show_bug.cgi?id=54250
--- Comment #17 from ake.rehnman@gmail.com --- (In reply to Eric Pouech from comment #16)
Created attachment 73835 [details] proposed patch
another try <g>
Seem to work :-) I don't think the stripping of the nt object prefix "\??\" is necessary. I tried without it and it works. wine_get_unix_file_name() strips it anyways.
I also splitted the patch in pieces for creating the merge request. Let me know if:
- your name is correct
YES
- you agree for submission for your derived code
AGREE
https://bugs.winehq.org/show_bug.cgi?id=54250
--- Comment #18 from Eric Pouech eric.pouech@gmail.com --- (In reply to ake.rehnman from comment #17)
(In reply to Eric Pouech from comment #16)
Created attachment 73835 [details] proposed patch
another try <g>
Seem to work :-)
at least <g>!
I don't think the stripping of the nt object prefix "\??\" is necessary. I tried without it and it works. wine_get_unix_file_name() strips it anyways.
agreed
I also splitted the patch in pieces for creating the merge request. Let me know if:
- your name is correct
YES
- you agree for submission for your derived code
AGREE
merge request posted: https://gitlab.winehq.org/wine/wine/-/merge_requests/1913
thanks for your time & support
https://bugs.winehq.org/show_bug.cgi?id=54250
--- Comment #19 from Eric Pouech eric.pouech@gmail.com --- proposed fixed committed as 168c7a475d43cb7688636f0eb13b3892322333c0 and 3 following commits for inclusion in wine 8.1
https://bugs.winehq.org/show_bug.cgi?id=54250
temp82@luukku.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ake.rehnman@gmail.com, | |temp82@luukku.com
https://bugs.winehq.org/show_bug.cgi?id=54250
Michael Stefaniuc mstefani@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mstefani@winehq.org
--- Comment #20 from Michael Stefaniuc mstefani@winehq.org --- Is this bug fixed? I see https://gitlab.winehq.org/wine/wine/-/merge_requests/1913 was merged.
https://bugs.winehq.org/show_bug.cgi?id=54250
--- Comment #21 from Eric Pouech eric.pouech@gmail.com --- (In reply to Michael Stefaniuc from comment #20)
Is this bug fixed? I see https://gitlab.winehq.org/wine/wine/-/merge_requests/1913 was merged.
In regular process; it's up to the reported to acknowledge the bug has been fixed.
Here, Ake tested it before the merge & confirmed it worked. So unsure if process can be twisted that way.
https://bugs.winehq.org/show_bug.cgi?id=54250
ake.rehnman@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|ASSIGNED |RESOLVED
--- Comment #22 from ake.rehnman@gmail.com --- Fixed with https://gitlab.winehq.org/wine/wine/-/merge_requests/1913
https://bugs.winehq.org/show_bug.cgi?id=54250
Zeb Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |a89975f731b5cfe822bd7f8d33d | |a0a9481b1c151
https://bugs.winehq.org/show_bug.cgi?id=54250
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #23 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 8.8.