[valgrind] [Bug 211031] valgrind doesn't show symbols for programs compiled with mingw's gcc
https://bugs.kde.org/show_bug.cgi?id=211031 rber...@codeweavers.com changed: What|Removed |Added Attachment #133748|0 |1 is obsolete|| --- Comment #36 from rber...@codeweavers.com --- Created attachment 137430 --> https://bugs.kde.org/attachment.cgi?id=137430&action=edit DWARF in PE parsing support for Wine Patches rebased on top of 5e41080720e451cefc2265c64f82fb77a9f29151. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 211031] valgrind doesn't show symbols for programs compiled with mingw's gcc
https://bugs.kde.org/show_bug.cgi?id=211031 --- Comment #35 from rber...@codeweavers.com --- Talked too soon, it now doesn't build anymore, I'll update the patches. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 211031] valgrind doesn't show symbols for programs compiled with mingw's gcc
https://bugs.kde.org/show_bug.cgi?id=211031 --- Comment #34 from rber...@codeweavers.com --- Just a reminder that this is still broken and the patches attached should fix the missing symbols when Wine is built with MinGW and DWARF debug info (still requires some Wine-side fixes too). I believe the Valgrind patches still apply without conflict. The only remaining issue that I could see is that Wine munmaps its DLLs whenever they are unloaded, and that makes Valgrind drop all symbols in the range, making some later leak reports miss the symbols. But that's possibly an issue to be worked around on Wine side. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 211031] valgrind doesn't show symbols for programs compiled with mingw's gcc
https://bugs.kde.org/show_bug.cgi?id=211031 --- Comment #33 from Austin English --- To follow up, I misunderstood the scope of Remi's work. The patchset *does* work for DWARF symbols in PE binaries in modern wine (i.e., with wine having a mingw compiled ntdll). PDB support is a separate problem and should not stop the patches from going in. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 211031] valgrind doesn't show symbols for programs compiled with mingw's gcc
https://bugs.kde.org/show_bug.cgi?id=211031 --- Comment #32 from Austin English --- Hi Remi, Using both wine patches: https://source.winehq.org/patches/data/196764 https://source.winehq.org/patches/data/196765 and valgrind patches: https://sourceforge.net/p/valgrind/mailman/message/37164939/ https://sourceforge.net/p/valgrind/mailman/message/37164938/ https://sourceforge.net/p/valgrind/mailman/message/37164940/ on top of wine-6.0-rc2 and valgrind-VALGRIND_3_15_0-405-g41504d33d, with llvm-mingw, I don't get symbols: ==8917== 2,048 bytes in 1 blocks are possibly lost in loss record 86 of 92 ==8917==at 0x7BC23550: ??? (in /home/austin/wine-valgrind-pdb/dlls/ntdll/ntdll.dll) ==8917==by 0x7BC2F91F: ??? (in /home/austin/wine-valgrind-pdb/dlls/ntdll/ntdll.dll) ==8917==by 0x7BC29921: ??? (in /home/austin/wine-valgrind-pdb/dlls/ntdll/ntdll.dll) ==8917==by 0x7BC2E1F7: ??? (in /home/austin/wine-valgrind-pdb/dlls/ntdll/ntdll.dll) ==8917==by 0x7BC2DC01: ??? (in /home/austin/wine-valgrind-pdb/dlls/ntdll/ntdll.dll) ==8917==by 0x46E061E: start_main_thread (loader.c:1580) ==8917==by 0x46E061E: __wine_main (???:0) ==8917==by 0x7D001287: main (main.c:157) ==8917== compared to non pdb build: ==31534== 2,048 bytes in 1 blocks are possibly lost in loss record 100 of 108 ==31534==at 0x7BC51E61: RtlAllocateHeap (heap.c:261) ==31534==by 0x7BC625C3: init_load_order (loadorder.c:234) ==31534==by 0x7BC625C3: get_load_order (???:0) ==31534==by 0x7BC5DA27: load_dll (loader.c:2644) ==31534==by 0x7BC5FFD1: process_init (loader.c:4017) ==31534==by 0x7BC61D7B: __wine_set_unix_funcs (loader.c:4114) ==31534==by 0x46E061E: start_main_thread (loader.c:1580) ==31534==by 0x46E061E: __wine_main (???:0) ==31534==by 0x7D001287: main (main.c:157) ==31534== (that's dlls/avifil32/tests/api.c) -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 211031] valgrind doesn't show symbols for programs compiled with mingw's gcc
https://bugs.kde.org/show_bug.cgi?id=211031 rber...@codeweavers.com changed: What|Removed |Added CC||rber...@codeweavers.com --- Comment #31 from rber...@codeweavers.com --- Created attachment 133748 --> https://bugs.kde.org/attachment.cgi?id=133748&action=edit DWARF in PE parsing support for WIne Hi! I wasn't aware there was already some work in progress (TBF I didn't look for it), and I sent these patches to the valgrind-developers mailing list earlier today. They implement DWARF parsing from PE files in a similar way it is done for ELF files, to support the use case reported here. It's probably a bit redundant with some of the patches attached here, but I'm re-using the code from readpdb.c instead of duplicating the structure definitions. Also, because Wine mmap calls are a bit difficult to interpret from Valgrind side, I'm using the PDB hook to read PE files when no PDB are found. The first patch fixes the readpdb.c structures definitions, in the same way as some of the patches for https://bugs.kde.org/show_bug.cgi?id=253657 do. For some reason these fixes never landed. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 211031] valgrind doesn't show symbols for programs compiled with mingw's gcc
https://bugs.kde.org/show_bug.cgi?id=211031 --- Comment #30 from Austin English --- Created attachment 128946 --> https://bugs.kde.org/attachment.cgi?id=128946&action=edit compiled test/pdb (In reply to Jefferson Carpenter from comment #29) > (In reply to Austin English from comment #28) > > Created attachment 128170 [details] > > the impossible happened > > > > Upon manual review, it didn't assert, but the impossible happened: > > > > PUTI(136:8xI8)[t1,0] = 0x0:I8 > > > > > > > > vex: the `impossible' happened: > > > >stmt_is_guardable: unhandled stmt > > > > vex storage: T total 9579053828 bytes allocated > > > > vex storage: P total 496 bytes allocated > > > > > > > > valgrind: the 'impossible' happened: > > > >LibVEX called failure_exit(). > > > > > > > > in dlls/atl/tests/registrar.c > > I ran the same test (valgrind --trace-children=yes > ../../../../wine-source/tools/runtest -q -P ../../../loader/wine -T ../../.. > -M atl.dll -p atl_test.exe.so registrar), and the impossible didn't happen > on my machine. (My configure command included --without-mingw because > that's what causes the .exe.so files to be generated). Can you confirm that > the bug happens with my patch applied and not on master? It seems like some > spooky action at a distance if my patch caused new problems generating IR. After some more testing, it only occurs if: ./configure --with-mingw CROSSDEBUG=pdb is used for the build. I'm not sure why the other log shows .exe.so. Maybe a dirty tree, or maybe wine's build system changed.. I've attached the exe and pdb file, it should be enough to reproduce without having to get llvm-mingw/rebuild wine. $ export VALGRIND_OPTS="-q --trace-children=yes --track-origins=yes --gen-suppressions=all --suppressions=/home/austin/wine-valgrind/tools/valgrind/valgrind-suppressions-ignore --suppressions=/home/austin/wine-valgrind/tools/valgrind/valgrind-suppressions-external --suppressions=/home/austin/wine-valgrind/tools/valgrind/valgrind-suppressions-known-bugs --suppressions=/home/austin/wine-valgrind/tools/valgrind/valgrind-suppressions-gecko --leak-check=full --num-callers=20 --workaround-gcc296-bugs=yes --vex-iropt-register-updates=allregs-at-mem-access" # make sure to use the full path for wine: $ valgrind /usr/local/bin/wine avifil32_test.exe api preloader: Warning: failed to reserve range 0011-6800 preloader: Warning: failed to reserve range 7f00-8200 0140:err:heap:HEAP_GetPtr Invalid heap (nil)! size: 136926 ==31466== LOAD_PDB_DEBUGINFO: Find PDB file: /tmp/valgrind_petmp31466_1cb84028 is empty ==31466== Warning: Missing or un-stat-able /home/austin/.wine/drive_c/windows/system32/kernelbase.pdb size: 135558 ==31466== LOAD_PDB_DEBUGINFO: Find PDB file: /tmp/valgrind_petmp31466_1cb84028 is empty ==31466== Warning: Missing or un-stat-able /usr/local/lib64/wine/kernelbase.pdb symbol table size is 0. Not reading debug information for /tmp/tmp.emEgO3p387/bug-211031-avifil32-test/avifil32_test.exe valgrind: m_debuginfo/debuginfo.c:1672 (vgPlain_di_notify_pdb_debuginfo): Assertion 'di && !di->fsm.have_rx_map && !di->fsm.have_rw_map' failed. host stacktrace: ==31466==at 0x58041CF9: show_sched_status_wrk (m_libcassert.c:406) ==31466==by 0x58041E20: report_and_quit (m_libcassert.c:477) ==31466==by 0x58041F14: vgPlain_assert_fail (m_libcassert.c:543) ==31466==by 0x58076146: vgPlain_di_notify_pdb_debuginfo (debuginfo.c:1672) ==31466==by 0x580A252D: do_client_request (scheduler.c:2121) ==31466==by 0x580A252D: vgPlain_scheduler (scheduler.c:1516) ==31466==by 0x580F72C2: thread_wrapper (syswrap-linux.c:101) ==31466==by 0x580F72C2: run_a_thread_NORETURN (syswrap-linux.c:154) sched status: running_tid=1 Thread 1: status = VgTs_Runnable (lwpid 31466) ==31466==at 0x7BCD6494: map_image (virtual.c:1749) ==31466==by 0x7BCD6A71: virtual_map_section (virtual.c:1835) ==31466==by 0x7BC79293: open_dll_file (loader.c:2371) ==31466==by 0x7BC79D9E: find_dll_file (loader.c:3014) ==31466==by 0x7BC7FDAB: load_dll (loader.c:3044) ==31466==by 0x7BC84857: __wine_process_init (loader.c:4426) ==31466==by 0x7BC84F42: __wine_set_unix_funcs (loader.c:4488) ==31466==by 0x7C001341: main (main.c:285) client stack range: [0xFECB8000 0xFECBDFFF] client SP: 0xFECBA900 valgrind stack range: [0x881FD000 0x882FCFFF] top usage: 7372 of 1048576 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 211031] valgrind doesn't show symbols for programs compiled with mingw's gcc
https://bugs.kde.org/show_bug.cgi?id=211031 --- Comment #29 from Jefferson Carpenter --- (In reply to Austin English from comment #28) > Created attachment 128170 [details] > the impossible happened > > Upon manual review, it didn't assert, but the impossible happened: > > PUTI(136:8xI8)[t1,0] = 0x0:I8 > > > > vex: the `impossible' happened: > >stmt_is_guardable: unhandled stmt > > vex storage: T total 9579053828 bytes allocated > > vex storage: P total 496 bytes allocated > > > > valgrind: the 'impossible' happened: > >LibVEX called failure_exit(). > > > > in dlls/atl/tests/registrar.c I ran the same test (valgrind --trace-children=yes ../../../../wine-source/tools/runtest -q -P ../../../loader/wine -T ../../.. -M atl.dll -p atl_test.exe.so registrar), and the impossible didn't happen on my machine. (My configure command included --without-mingw because that's what causes the .exe.so files to be generated). Can you confirm that the bug happens with my patch applied and not on master? It seems like some spooky action at a distance if my patch caused new problems generating IR. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 211031] valgrind doesn't show symbols for programs compiled with mingw's gcc
https://bugs.kde.org/show_bug.cgi?id=211031 --- Comment #28 from Austin English --- Created attachment 128170 --> https://bugs.kde.org/attachment.cgi?id=128170&action=edit the impossible happened Upon manual review, it didn't assert, but the impossible happened: PUTI(136:8xI8)[t1,0] = 0x0:I8 vex: the `impossible' happened: stmt_is_guardable: unhandled stmt vex storage: T total 9579053828 bytes allocated vex storage: P total 496 bytes allocated valgrind: the 'impossible' happened: LibVEX called failure_exit(). in dlls/atl/tests/registrar.c -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 211031] valgrind doesn't show symbols for programs compiled with mingw's gcc
https://bugs.kde.org/show_bug.cgi?id=211031 --- Comment #27 from Austin English --- No assertions so far (running still, up to d3d8:visual). Stacktraces look good. Lots of (valid) warnings for missing symbols in wine: symbol table size is 0. Not reading debug information for /home/austin/.wine-valgrind/drive_c/windows/system32/winex11.drv ==14040== LOAD_PDB_DEBUGINFO: Find PDB file: /tmp/valgrind_petmp14040_6f021bc4 is empty ==14040== Warning: Missing or un-stat-able /home/austin/.wine-valgrind/drive_c/windows/system32/winex11.pdb The symbol table size warning should match current format, of course. I haven't checked, but it likely corresponds to the un-stat-able message, so is it really needed? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 211031] valgrind doesn't show symbols for programs compiled with mingw's gcc
https://bugs.kde.org/show_bug.cgi?id=211031 Jefferson Carpenter changed: What|Removed |Added Attachment #126950|0 |1 is obsolete|| Attachment #126977|0 |1 is obsolete|| --- Comment #26 from Jefferson Carpenter --- Created attachment 128132 --> https://bugs.kde.org/attachment.cgi?id=128132&action=edit Add read_pe_debug_info: v3 Apparently the attachment didn't attach. Attached it again. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 211031] valgrind doesn't show symbols for programs compiled with mingw's gcc
https://bugs.kde.org/show_bug.cgi?id=211031 --- Comment #25 from Jefferson Carpenter --- Removed the spurious output. Did not manually add a mapping, to fix the "DiCfsi invariant (1) verification failed" message. Also removed the dwarf3 code - the patch still seems to work for me, and native PE files will of course not have dwarf3 debug info. There are still some things I'm very unsure about whether this patch does correctly. 1: Latest version, I changed the search_all_symtabs logic to search for text sections using di->text_present and so on, instead of looking at di->fsm properties. It seems logical, but since I'm not very familiar with the Valgrind code it could be a breaking change. Someone would have to look at it. 2: The way read_pe_debug_info is called into is IMO a messy hack. I did add a function for detecting whether a binary is a PE object file, but I think passing a boolean argument into di_notify_ACHIEVE_ACCEPT_STATE is not the cleanest way to do it. The way PDB debug info is requested is through client requests, so maybe PE debug info should be requested the same way. 3: There's generally a little bit of code duplication. Some duplicate "if (!ML_(img_valid)(...))" statements I could try to combine or replace with a macro. Also the PE executable file format is modeled both in readpdb.c and readpe.c currently and should be factored out into a header. I just didn't bother to do that at this early stage. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 211031] valgrind doesn't show symbols for programs compiled with mingw's gcc
https://bugs.kde.org/show_bug.cgi?id=211031 --- Comment #24 from Austin English --- Getting a failed assertion in some tests: valgrind: m_debuginfo/debuginfo.c:694 (check_CFSI_related_invariants): Assertion '!ranges_overlap(map->avma, map->size, map2->avma, map2->size)' failed. valgrind: DiCfsi invariant (1) verification failed host stacktrace: ==6286==at 0x58041CF9: show_sched_status_wrk (m_libcassert.c:406) ==6286==by 0x58041E20: report_and_quit (m_libcassert.c:477) ==6286==by 0x58041F14: vgPlain_assert_fail (m_libcassert.c:543) ==6286==by 0x58075670: check_CFSI_related_invariants (debuginfo.c:692) ==6286==by 0x58075670: di_notify_ACHIEVE_ACCEPT_STATE (debuginfo.c:992) ==6286==by 0x58075670: vgPlain_di_notify_mmap (debuginfo.c:1326) ==6286==by 0x580A8D51: vgModuleLocal_generic_PRE_sys_mmap (syswrap-generic.c:2400) ==6286==by 0x580B5F25: vgSysWrap_x86_linux_sys_mmap2_before (syswrap-x86-linux.c:987) ==6286==by 0x580A45BE: vgPlain_client_syscall (syswrap-main.c:1914) ==6286==by 0x580A090C: handle_syscall (scheduler.c:1208) ==6286==by 0x580A246F: vgPlain_scheduler (scheduler.c:1526) ==6286==by 0x580F7312: thread_wrapper (syswrap-linux.c:101) ==6286==by 0x580F7312: run_a_thread_NORETURN (syswrap-linux.c:154) sched status: running_tid=1 Thread 1: status = VgTs_Runnable syscall 192 (lwpid 6286) ==6286==at 0x435A253: mmap64 (mmap64.c:56) ==6286==by 0x7BCAAFFE: map_pe_header (virtual.c:1491) ==6286==by 0x7BCAC3E6: map_image (virtual.c:1569) ==6286==by 0x7BCADA02: virtual_map_section (virtual.c:1838) ==6286==by 0x7BC68BFC: open_dll_file (loader.c:2515) ==6286==by 0x7BC68DA8: search_dll_file (loader.c:3074) ==6286==by 0x7BC6923F: find_dll_file (loader.c:3154) ==6286==by 0x7BC6CBF9: load_dll (loader.c:3186) ==6286==by 0x7BC6C0F8: import_dll (loader.c:801) ==6286==by 0x7BC6C64B: fixup_imports (loader.c:1165) ==6286==by 0x7BC6C8AF: load_native_dll (loader.c:2570) ==6286==by 0x7BC6CB26: load_builtin_dll (loader.c:2930) ==6286==by 0x7BC6CE08: load_dll (loader.c:3231) ==6286==by 0x7BC6C0F8: import_dll (loader.c:801) ==6286==by 0x7BC6C64B: fixup_imports (loader.c:1165) ==6286==by 0x7BC6E372: LdrInitializeThunk (loader.c:3987) ==6286==by 0x7BC99953: attach_thread (signal_i386.c:3050) ==6286==by 0x7BC9634F: ??? (in /home/austin/wine-valgrind/dlls/ntdll/ntdll.dll.so) client stack range: [0x4A62000 0x4B5] client SP: 0x4B5D22C valgrind stack range: [0x881D3000 0x882D2FFF] top usage: 7092 of 1048576 Note: see also the FAQ in the source distribution. It contains workarounds to several common problems. In particular, if Valgrind aborted or crashed after identifying problems in your program, there's a good chance that fixing those problems will prevent Valgrind aborting or crashing, especially if it happened in m_mallocfree.c. e.g., avifil32/tests/api.c -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 211031] valgrind doesn't show symbols for programs compiled with mingw's gcc
https://bugs.kde.org/show_bug.cgi?id=211031 --- Comment #23 from Austin English --- I usually use -p1, so not sure what was wrong..anyway, recently tried again, with a clean tree, and it applies fine, so yeah, it was something on my end. With the patch, I see an improvement using badfree.c from the original post: No patch: ==10542== Invalid free() / delete / delete[] / realloc() ==10542==at 0x7BC70261: notify_free (heap.c:268) ==10542==by 0x7BC70261: RtlFreeHeap.part.7 (???:0) ==10542==by 0x7BC72034: RtlFreeHeap (heap.c:1748) ==10542==by 0x516469D: msvcrt_heap_free (heap.c:114) ==10542==by 0x51651DF: MSVCRT_free (heap.c:414) ==10542==by 0x401599: ??? ==10542==by 0x401395: ??? ==10542==by 0x7B4504F1: ??? (in /usr/local/lib64/wine/kernel32.dll.so) ==10542==by 0x7B4508DF: start_process (process.c:153) ==10542==by 0x7B4504FD: ??? (in /usr/local/lib64/wine/kernel32.dll.so) ==10542== Address 0x87654321 is on thread 1's stack ==10542== Patch: ==8665== Invalid free() / delete / delete[] / realloc() ==8665==at 0x7BC70261: notify_free (heap.c:268) ==8665==by 0x7BC70261: RtlFreeHeap.part.7 (???:0) ==8665==by 0x7BC72034: RtlFreeHeap (heap.c:1748) ==8665==by 0x516469D: msvcrt_heap_free (heap.c:114) ==8665==by 0x51651DF: MSVCRT_free (heap.c:414) ==8665==by 0x401599: _main (badfree.c:12) ==8665==by 0x401395: ??? (crtexe.c:339) ==8665==by 0x7B4504F1: ??? (in /usr/local/lib64/wine/kernel32.dll.so) ==8665==by 0x7B4508DF: start_process (process.c:153) ==8665==by 0x7B4504FD: ??? (in /usr/local/lib64/wine/kernel32.dll.so) ==8665== Address 0x87654321 is on thread 1's stack ==8665== namely badfree.c:12 and crtexe.c:339. Note that there's some spurious output from the patch, e.g.,: size: 130284 @Julian, if feasible, it would be great to target this for valgrind-3.16.0. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 211031] valgrind doesn't show symbols for programs compiled with mingw's gcc
https://bugs.kde.org/show_bug.cgi?id=211031 Timur Iskhodzhanov changed: What|Removed |Added CC|timur...@google.com | -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 211031] valgrind doesn't show symbols for programs compiled with mingw's gcc
https://bugs.kde.org/show_bug.cgi?id=211031 Timur Iskhodzhanov changed: What|Removed |Added CC||timur...@google.com -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 211031] valgrind doesn't show symbols for programs compiled with mingw's gcc
https://bugs.kde.org/show_bug.cgi?id=211031 --- Comment #22 from Jefferson Carpenter --- (In reply to Jefferson Carpenter from comment #21) > I created the patch using git format-patch, so you should apply it using > either > > $ git apply 0001-Add-read_pe_debug_info-V2.patch > > or > > $ patch -p 1 <0001-Add-read_pe_debug_info-V2.patch > > I'm still not clear on the best way to create patch files. Here's what I think happened - by default patch strips all directories off of the path in the patch file. Since Makefile.am does exist in the root directory patch attempts to apply HUNK 1 but fails because HUNK 1 is actually for the coregrind/Makefile.am file. (Then, since coregrind/m_debuginfo/debuginfo.c is modified but debuginfo.c does not exist in the root directory of valgrind, patch has to ask for its directory. priv_readpe.h and readpe.c are both new files, but patch again strips their directories and places them in the root directory). Moral of the story: run patch with a -p option if the patch file has knowledge of the directory structure of your project. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 211031] valgrind doesn't show symbols for programs compiled with mingw's gcc
https://bugs.kde.org/show_bug.cgi?id=211031 --- Comment #21 from Jefferson Carpenter --- (In reply to Austin English from comment #20) > Fails to build: > make[3]: *** No rule to make target 'm_debuginfo/readpe.c', needed by > 'm_debuginfo/libcoregrind_amd64_linux_a-readpe.o'. Stop. > > (try 1 compiles okay) I created the patch using git format-patch, so you should apply it using either $ git apply 0001-Add-read_pe_debug_info-V2.patch or $ patch -p 1 <0001-Add-read_pe_debug_info-V2.patch I'm still not clear on the best way to create patch files. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 211031] valgrind doesn't show symbols for programs compiled with mingw's gcc
https://bugs.kde.org/show_bug.cgi?id=211031 --- Comment #20 from Austin English --- (In reply to Jefferson Carpenter from comment #19) > Created attachment 126977 [details] > Hackish patch: Add read_pe_debug_info: v2 > > Fixed some of the most significant lies from my first patch. No longer > assumes .text is the first section. Instead of "main.exe" uses the basename > of the executable as the soname (I don't know whether this is even correct). > Uses correct-looking arenas for allocations. Correctly sorts symbols in > descending order and corrects addSym calls. Fails to build: make[3]: *** No rule to make target 'm_debuginfo/readpe.c', needed by 'm_debuginfo/libcoregrind_amd64_linux_a-readpe.o'. Stop. (try 1 compiles okay) -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 211031] valgrind doesn't show symbols for programs compiled with mingw's gcc
https://bugs.kde.org/show_bug.cgi?id=211031 --- Comment #19 from Jefferson Carpenter --- Created attachment 126977 --> https://bugs.kde.org/attachment.cgi?id=126977&action=edit Hackish patch: Add read_pe_debug_info: v2 Fixed some of the most significant lies from my first patch. No longer assumes .text is the first section. Instead of "main.exe" uses the basename of the executable as the soname (I don't know whether this is even correct). Uses correct-looking arenas for allocations. Correctly sorts symbols in descending order and corrects addSym calls. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 211031] valgrind doesn't show symbols for programs compiled with mingw's gcc
https://bugs.kde.org/show_bug.cgi?id=211031 --- Comment #18 from Jefferson Carpenter --- Created attachment 126950 --> https://bugs.kde.org/attachment.cgi?id=126950&action=edit Hackish patch: Add read_pe_debug_info -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 211031] valgrind doesn't show symbols for programs compiled with mingw's gcc
https://bugs.kde.org/show_bug.cgi?id=211031 Jefferson Carpenter changed: What|Removed |Added CC||jeffersoncarpenter2@gmail.c ||om --- Comment #17 from Jefferson Carpenter --- (In reply to fenrir+kde-bugs from comment #5) > I have attached a very hackish patch against valgrind 3.6.0 that I have > made to load the informations. It partially works for VLC: I have the file > and line number working but that's all. e.g. In order to get the function names, you may have to iterate through the PE/COFF symbol table, and insert the symbols into the debuginfo. I have also attached a very hackish patch, one that reads debug info from the PE32 file itself having been compiled with mingw. It does not support PE64. In addition to being hackish, it contains numerous lies. It currently assumes that the .text section is sections[0] for no particular reason. It also adds a DebugInfoMap covering the range [image_base, image_base + size_of_image) assuming that's where the image will be during execution (I think a better way to do that would be to intercept the call that moves it there, be that a memcpy, memmove, mmap, or what have you). Furthermore, I was not able to tell if there is a way to get the ending address of symbols - only the starting address. So I have it pushing all of the symbols into an array, sorting it descending by symbol starting address, and setting each symbol's address range to go from its starting address to just before starting address of the next symbol. (The last symbol is then said to end at the end of the text section.) -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 211031] valgrind doesn't show symbols for programs compiled with mingw's gcc
https://bugs.kde.org/show_bug.cgi?id=211031 --- Comment #16 from Austin English --- I recently tested llvm-mingw (from https://github.com/mstorsjo/llvm-mingw/), and built wine with llvm's pdb debug symbols. That gives similar results to gnu mingw: ==23786== Invalid read of size 2 ==23786==at 0x7B01F09E: ??? ==23786==by 0x60B93DA: ??? ==23786==by 0x60B89AC: ??? ==23786==by 0x507872F: ??? (in /home/austin/wine-valgrind-mingw/dlls/user32/user32.dll.so) ==23786==by 0x5078CFE: call_window_proc (winproc.c:249) ==23786==by 0x507A02C: WINPROC_CallProcAtoW (winproc.c:609) ==23786==by 0x507ABC4: WINPROC_call_window (winproc.c:956) ==23786==by 0x5043C8D: call_window_proc (message.c:2225) ==23786==by 0x5046E09: send_message (message.c:3294) ==23786==by 0x50498B9: SendMessageA (message.c:3517) ==23786==by 0x41C0A6: ??? ==23786==by 0x4143D1: ??? ==23786==by 0x49F862: ??? ==23786==by 0x49F71C: ??? ==23786==by 0x401394: ??? ==23786==by 0x7B449E31: ??? (in /home/austin/wine-valgrind-mingw/dlls/kernel32/kernel32.dll.so) ==23786==by 0x7B44A262: start_process (process.c:153) ==23786==by 0x7B449E3D: ??? (in /home/austin/wine-valgrind-mingw/dlls/kernel32/kernel32.dll.so) ==23786== Address 0x5ec1a08 is 744 bytes inside a block of size 1,024 free'd ==23786==at 0x7BC6255E: notify_free (heap.c:268) ==23786==by 0x7BC64B94: RtlFreeHeap (heap.c:1771) ==23786==by 0x52123C3: free_heap_bits (bitblt.c:168) ==23786==by 0x521CF08: nulldrv_StretchDIBits (dib.c:606) ==23786==by 0x521D285: StretchDIBits (dib.c:636) ==23786==by 0x500C450: create_icon_from_bmi (cursoricon.c:1265) ==23786==by 0x500D26B: CURSORICON_Load (cursoricon.c:1867) ==23786==by 0x500F153: LoadImageW (cursoricon.c:3065) ==23786==by 0x6111289: ??? ==23786==by 0x60B1CE7: ??? ==23786==by 0x61221E0: ??? ==23786==by 0x7BC667C9: ??? (in /home/austin/wine-valgrind-mingw/dlls/ntdll/ntdll.dll.so) ==23786==by 0x7BC6A582: MODULE_InitDLL (loader.c:1331) ==23786==by 0x7BC6A80A: process_attach (loader.c:1425) ==23786==by 0x7BC6CBD2: LdrLoadDll (loader.c:3094) ==23786==by 0x7B01436E: ??? ==23786==by 0x7B014279: ??? ==23786==by 0x7B01419B: ??? ==23786==by 0x7B01415E: ??? ==23786==by 0x4145B5: ??? ==23786== Block was alloc'd at ==23786==at 0x7BC62514: notify_alloc (heap.c:260) ==23786==by 0x7BC65377: RtlAllocateHeap (heap.c:1725) ==23786==by 0x5212AB4: convert_bits (bitblt.c:183) ==23786==by 0x521D045: nulldrv_StretchDIBits (dib.c:589) ==23786==by 0x521D285: StretchDIBits (dib.c:636) ==23786==by 0x500C450: create_icon_from_bmi (cursoricon.c:1265) ==23786==by 0x500D26B: CURSORICON_Load (cursoricon.c:1867) ==23786==by 0x500F153: LoadImageW (cursoricon.c:3065) ==23786==by 0x6111289: ??? ==23786==by 0x60B1CE7: ??? ==23786==by 0x61221E0: ??? ==23786==by 0x7BC667C9: ??? (in /home/austin/wine-valgrind-mingw/dlls/ntdll/ntdll.dll.so) ==23786==by 0x7BC6A582: MODULE_InitDLL (loader.c:1331) ==23786==by 0x7BC6A80A: process_attach (loader.c:1425) ==23786==by 0x7BC6CBD2: LdrLoadDll (loader.c:3094) ==23786==by 0x7B01436E: ??? ==23786==by 0x7B014279: ??? ==23786==by 0x7B01419B: ??? ==23786==by 0x7B01415E: ??? ==23786==by 0x4145B5: ??? ==23786== which is interesting, given that valgrind has some pdb support. LLVM uses the publicly documented pdb info from https://github.com/Microsoft/microsoft-pdb, fwiw. Note that I did run until other issues in some tests with this setup, see bug 416779. Tested with VALGRIND_3_15_0-193-gfe6805efc -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 211031] valgrind doesn't show symbols for programs compiled with mingw's gcc
https://bugs.kde.org/show_bug.cgi?id=211031 --- Comment #15 from Austin English --- As of wine-4.6, wine now supports building its dlls with mingw: https://source.winehq.org/git/wine.git/commitdiff/a3cf86a18446e9d7df4e045b83d3aa3d9193512a the plan is to eventually make that the default (not sure if there's a timeline for that yet, but I would guess that before next stable release is likely). When compiling wine with mingw support, stacktraces are pretty poor. As a comparison, here's the same test with native gcc (8.3.0) versus mingw (i686-w64-mingw32-gcc (Gentoo 9.2.0-r2 p3) 9.2.0). With dlls/comctl32/tests/edit.c in wine-4.20-213-gddec23013e native: ==10945== Invalid read of size 2 ==10945==at 0x4F0C401: LocalLock (memory.c:661) ==10945==by 0x63FAE1A: EDIT_LockBuffer (edit.c:1195) ==10945==by 0x640216D: EDIT_WindowProc (edit.c:4608) ==10945==by 0x55FB4A7: ??? (in /home/austin/wine-valgrind-no-mingw/dlls/user32/user32.dll.so) ==10945==by 0x55FBA94: call_window_proc (winproc.c:249) ==10945==by 0x55FCEFE: WINPROC_CallProcAtoW (winproc.c:609) ==10945==by 0x55FDB4D: WINPROC_call_window (winproc.c:956) ==10945==by 0x55C38CE: call_window_proc (message.c:2225) ==10945==by 0x55C6EB6: send_message (message.c:3294) ==10945==by 0x55C9B02: SendMessageA (message.c:3517) ==10945==by 0x5016FDF: test_EM_GETHANDLE (edit.c:3041) ==10945==by 0x5018F22: func_edit (edit.c:3411) ==10945==by 0x50A0581: run_test (test.h:637) ==10945==by 0x50A0E08: main (test.h:721) ==10945== Address 0x4952a58 is 16 bytes after a recently re-allocated block of size 32 alloc'd ==10945==at 0x7BC6656F: notify_alloc (heap.c:260) ==10945==by 0x7BC695B5: RtlAllocateHeap (heap.c:1725) ==10945==by 0x59177B7: create_family (freetype.c:1594) ==10945==by 0x59278A4: load_font_list_from_cache (freetype.c:1768) ==10945==by 0x59283B9: WineEngInit (freetype.c:4458) ==10945==by 0x5928CCD: DllMain (gdiobj.c:693) ==10945==by 0x594011C: __wine_spec_dll_entry (dll_entry.c:44) ==10945==by 0x7BC6AA95: ??? (in /home/austin/wine-valgrind-no-mingw/dlls/ntdll/ntdll.dll.so) ==10945==by 0x7BC6EC1A: MODULE_InitDLL (loader.c:1331) ==10945==by 0x7BC6EEBB: process_attach (loader.c:1425) ==10945==by 0x7BC6EDFD: process_attach (loader.c:1411) ==10945==by 0x7BC6EDFD: process_attach (loader.c:1411) ==10945==by 0x7BC6EDFD: process_attach (loader.c:1411) ==10945==by 0x7BC715B9: LdrInitializeThunk (loader.c:3782) ==10945==by 0x7BC9C556: attach_thread (signal_i386.c:2746) ==10945==by 0x7BC991C3: ??? (in /home/austin/wine-valgrind-no-mingw/dlls/ntdll/ntdll.dll.so) mingw: ==15488== Invalid read of size 2 ==15488==at 0x7BC74A86: RtlInitNlsTables (locale.c:760) ==15488==by 0x7125EB11: ??? ==15488==by 0x7126254F: ??? ==15488==by 0x71262871: ??? ==15488==by 0x7BC6AAD5: ??? (in /home/austin/wine-valgrind-mingw/dlls/ntdll/ntdll.dll.so) ==15488==by 0x7BC6EC5A: MODULE_InitDLL (loader.c:1331) ==15488==by 0x7BC6EEFB: process_attach (loader.c:1425) ==15488==by 0x7BC6EE3D: process_attach (loader.c:1411) ==15488==by 0x7BC6EE3D: process_attach (loader.c:1411) ==15488==by 0x7BC715F9: LdrInitializeThunk (loader.c:3782) ==15488==by 0x7BC9D12A: attach_thread (signal_i386.c:2746) ==15488==by 0x7BC99D97: ??? (in /home/austin/wine-valgrind-mingw/dlls/ntdll/ntdll.dll.so) ==15488== Address 0x2 is not stack'd, malloc'd or (recently) free'd ==15488== interestingly, mingw shows RtlInitNlsTables while gcc doesn't (but that's likely it, since RtlInitNlsTables is in dlls/ntdll/locale.c at line 760 and that's the ??? in the gcc output. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 211031] valgrind doesn't show symbols for programs compiled with mingw's gcc
https://bugs.kde.org/show_bug.cgi?id=211031 --- Comment #14 from Austin English --- (In reply to Austin English from comment #13) > This is also relevant again for wine-gecko. Upstream Firefox moved to > require Visual Studio 2013+, and those newer format PDBs don't work with > Wine: > https://bugs.winehq.org/show_bug.cgi?id=37746 > https://bugs.winehq.org/show_bug.cgi?id=38594 > https://bugs.winehq.org/show_bug.cgi?id=38604 Still present in wine-2.1 / valgrind-3.13.0.SVN-16222-vex-3303 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 211031] valgrind doesn't show symbols for programs compiled with mingw's gcc
https://bugs.kde.org/show_bug.cgi?id=211031 cpon changed: What|Removed |Added CC||cpigat...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
