[valgrind] [Bug 211031] valgrind doesn't show symbols for programs compiled with mingw's gcc

[bugzilla_noreply]

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=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

[bugzilla_noreply]

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

[bugzilla_noreply]

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

[Austin English]

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

[Austin English]

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

[bugzilla_noreply]

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=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

[Austin English]

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=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

[Jefferson Carpenter]

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

[Austin English]

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=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

[Austin English]

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

[Jefferson Carpenter]

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=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

[Jefferson Carpenter]

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

[Austin English]

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

[Austin English]

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

[Timur Iskhodzhanov]

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

[Timur Iskhodzhanov]

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

[Jefferson Carpenter]

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

[Jefferson Carpenter]

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

[Austin English]

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

[Jefferson Carpenter]

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=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

[Jefferson Carpenter]

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=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

[Jefferson Carpenter]

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

[Austin English]

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

[Austin English]

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

[Austin English]

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

[cpon via KDE Bugzilla]

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.