support for mingw-w64

[TheOneRing]

Using very sleepy with mingw-w64 x86 http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/4.9.1/threads-posix/dwarf/ leads to a crash.

Using very sleepy with mingw-w64 x64 http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/4.9.1/threads-posix/seh/
works but the symbols aren't resolved.

[CyberShadow]

Hi, thanks for filing this. I'll have a look into this eventually, though currently I'm busy with other projects so unable to say when. If you can put together a pull request, I'll try to review and merge it sooner.

[rmitton]

Hi,
I am told that using -gdwarf-2 to compile with will help resolve the symbols.
I'll look into adding dwarf4 support in future.

[CyberShadow]

Can you give this version a try?
http://dump.thecybershadow.net/58c4691eb50f22da99ad2adbce0a2644/verysleepy-0.91-test-2015-02-17.exe

[TheOneRing]

Profiling works, qt function names aren't resolved fully and I somehow don't get the function names for the actual application I profiled. see capture: http://winkde.org/~pvonreth/other/tmp/sleepy/ the profiled app is snorenotfy build with cmake and -DCMAKE_BUILD_TYPE=Debug

[CyberShadow]

Please try this version:
http://dump.thecybershadow.net/98079a7c593fd4142330f634c22903ab/verysleepy-0.91-test-2015-02-26.exe

[TheOneRing]

Hi here is a screenshot http://winkde.org/~pvonreth/other/tmp/sleepy/quick%20(4).png
it looks like its still not really working besides for the main function.

Here is a small test app that directly crashes very sleepy.
http://winkde.org/~pvonreth/other/tmp/sleepy/test.7z

Start it with "downward-debug.exe --search 'lazy(random(ff(cost_type=one),epsilon=0.20),cost_type=one)' < output"

[CyberShadow]

I've forwarded the crash report upstream.

You might have more luck with -gdwarf-2, or by targeting i686 instead of amd64, or by switching the MinGW debug engine to "Wine" in Very Sleepy's options.

The executable is also built without stack frames, which current MinGW parsers need to traverse the call stack. To get meaningful stack traces and inclusive/exclusive times, you will also need to rebuild the program with -fno-omit-frame-pointer.

[CyberShadow]

This should fix the crash:

http://dump.thecybershadow.net/e3b9f6606dc0f2a6dcb3948554b38398/verysleepy-0.91-test-2015-02-27.exe

I think I'm seeing valid stack traces with your example, so I think stack frames might not be required after all. Please give it a go.

[rmitton]

Hi,
Unless something's changed recently, our MinGW support doesn't rely on
stack frames at all - it uses the built-in DWARF unwind data to get a
valid callstack even with FPO enabled.

Richard Mitton
richard@codersnotes.com

Vladimir Panteleev wrote:

This should fix the crash:

http://dump.thecybershadow.net/e3b9f6606dc0f2a6dcb3948554b38398/verysleepy-0.91-test-2015-02-27.exe

I think I'm seeing valid stack traces with your example, so I think
stack frames might not be required after all. Please give it a go.

—
Reply to this email directly or view it on GitHub
#9 (comment).

[CyberShadow]

@rmitton Wine's DbgHelp is now disabled by default due to poor support of 64-bit and anything newer than DWARF 2. Dr. MinGW (which uses libdwarf) is now used by default, but currently it leaves stack walking to Microsoft's DbgHelp. Nevertheless, it seems to work in the given example.

[jrfonseca]

@CyberShadow

BTW, thanks for integrating Very Sleepy with MgwHelp.

Believe it or not, it was thinking of VerySleepy that I split DrMinGW's guts into MgwHelp DLL. Many years ago I actually integrated some of DrMinGW code into Very Sleepy to see MinGW symbols, but all was very hackish. Everything would be much easier if MinGW symbol resolution had exectly the same interface as DbgHelp. Alas I never got around to re-attempt modifying Very Sleepy, and in the meanwhile the Wine DWARF support was added Very Sleepy so it stop being urgent.

It's nice to see things come around full circle!

[TheOneRing]

looks cool. http://winkde.org/~pvonreth/other/tmp/sleepy/quick%20(5).png
the code location is wrong and the mem usage is at 4gb for a few captured seconds but still very cool :D

[CyberShadow]

OK, I understand that we can consider this issue resolved.

New issues can be opened for specific problems with the new MinGW debug engine.