search

VerySleepy / verysleepy

Very Sleepy, a sampling CPU profiler for Windows
http://www.codersnotes.com/sleepy
GNU General Public License v2.0
1.07k stars 104 forks source link

mingw-w64 compiled executables' symbols not recognized #66

Closed kotauskas closed 5 years ago

kotauskas commented 5 years ago

The title says it all. I built an executable with mingw-w64 (latest official, G++ 8.1.0), of course with the -g flag, and it shows just addresses, not actual function names (and doesn't display code).

CyberShadow commented 5 years ago

Does it work with the latest Dr. MinGW? (download and unpack mgwhelp.dll over dbghelpdr.dll).

kotauskas commented 5 years ago

There's no dbghelpdr.dll file in the Very Sleepy installation directory.

CyberShadow commented 5 years ago

I'm assuming you are using the latest release from the website. Please update to the latest development version as described in this repository's README first.

kotauskas commented 5 years ago

No, still doesn't recognize (latest development snapshot, -g 64-bit mingw-w64 executable, latest Dr. MinGW): image

CyberShadow commented 5 years ago

Does it work if you rebuild the profiled program with -gdwarf-3 or -gdwarf-2 ?

kotauskas commented 5 years ago

No, ld doesn't know what's a -gdwarf-3: ld.exe: cannot open output file build\output\exe\windows\x86_64\Debug\GemVerse.exe: Invalid argument collect2.exe: error: ld returned 1 exit status. Maybe that's because I have a seh GCC (64-bit doesn't have dwarf)

CyberShadow commented 5 years ago

That would be a compiler switch, not linker. Debug information is emitted by the compiler and placed in object files during compilation. The linker merely puts it together.

kotauskas commented 5 years ago

No, my command line is x86_64-w64-mingw32-g++.exe %INCLUDEDIRS% %LIBDIRS64% %CFLAGS% %OBJECTS64% %SOURCES% %LIBS% -o build\output\exe\windows\x86_64\Debug\GemVerse.exe where %CFLAGS% contains -gdwarf-3

kotauskas commented 5 years ago

Same for -gdwarf-2

CyberShadow commented 5 years ago

The error message you posted above really doesn't look like it's due to the debug information format. Is it possible that's due to an unrelated error with your build? Is the source code (or at least build script / Makefiles) available?

kotauskas commented 5 years ago

My project builds almost fine, except for errors in fstream and fs_path.h (errors in compiler headers, what?), but that's out of this ticket's scope.

CyberShadow commented 5 years ago

If you can't post the code, then I don't think I can help you until you figure out why your toolchain is producing a weird error given -gdwarf-2.

kotauskas commented 5 years ago

I removed the part that invokes fstream stuff and now I'm getting multiple definition errors, I'll write back when I fix that.

kotauskas commented 5 years ago

So, I decided to test the weird behavior with some simple code: image As you can see, the source code correctly shows up and symbols are recognized. To achieve this, I separated compiling and linking, as if I did an incremental build, and passed -gdwarf-3 to the compilaton step invocation of g++, so my compilation steps were:

PS> g++ -c main.cpp -o main.o -gdwarf-3
PS> g++ main.o -o main.exe
kotauskas commented 5 years ago

Resolution:

  1. Update Very Sleepy to 0.91+
  2. Download latest Dr. MinGW, unpack mgwhelp.dll and replace dbghelpdr.dll from Very Sleepy's files with it
  3. Compile executable with -gdwarf-3 and link separately without that flag
CyberShadow commented 5 years ago

If it works with -gdwarf-3, then the problem is not within Very Sleepy.

I don't know what position Dr.MinGW has regarding supporting newer DWARF versions. You may want to follow up there.

If Dr.MinGW does not intend to support newer DWARF versions, then we should document compiling with -gdwarf-3 in this project somewhere too.