Windows 10, can't resolve mingw executable symbols

[fpopineau]

Hi,

I tried to use sleepy on emacs.exe compiled with mingw64. Sleepy is displaying statistics, but is not able to resolve symbols :

Any hint on how to solve this ?

I have compiled sleepy myself from sources.

Thanks,

(And BTW I'm impressed by sleepy !)

[CyberShadow]

Hi,

Could you please go into more detail on how you build Emacs?

• Which Emacs version?
• Exactly which MinGW toolkit did you use? (Download URLs would be perfect)
• Any relevant command lines

[fpopineau]

Sure, I used the MSYS2/MinGW64 toolchain available from http://www.msys2.org/

$ gcc --version gcc.exe (Rev2, Built by MSYS2 project) 6.3.0

About emacs, I compiled http://git.savannah.gnu.org/cgit/emacs.git/snapshot/emacs-25.2-rc2.tar.gz basically by running the configure script, with CFLAGS=-I/mingw64/include -O0 -ggdb3 -fno-omit-frame-pointer' Maybe the -ggdb3 option is not the right one ?

[CyberShadow]

Maybe the -ggdb3 option is not the right one ?

Not sure. I can't look at this right now, but I suggest trying to compile a simple C program and checking if symbol resolution works there. Check the tests directory (esp. gcc49-64) for example programs and command lines.

[fpopineau]

It does work with program.exe in gcc49-64. I will investigate the linker flags and maybe try to run temacs.exe instead of emacs.exe, that is the process before dump. EDIT: It seems that in the case of temacs.exe (the normal emacs, not the dumped one), there is a shift between the addresses that sleepy reports and the symbol addresses in temacs.map as generated by the linker. None of the addresses reported by sleepy appear in temacs.map.

[CyberShadow]

there is a shift between the addresses that sleepy reports and the symbol addresses in temacs.map as generated by the linker

That sounds like ASLR. Perhaps Dr. MinGW or something it uses may not support that.

Have you checked whether a test program compiled with the same toolset exhibits the same behavior?

It might be possible to work around this by disabling ASLR in the executable's header of stripping relocations.

[tim-lebedkov]

A similar issue here with my program Npackd. ASLR is disabled. The program and Very Sleepy run with elevated privileges. MinGW-w64 4.9.2 is used.

[tim-lebedkov]

development version of Very Sleepy does not help, switching to "MinGW" or "Wine" does not help, using the GCC switch -ggdb1 does not help either.

[CyberShadow]

Tim, have you tried writing a small test program which has this problem?

[tim-lebedkov]

I haven't tested with a small program yet.

A workaround: use https://github.com/rainers/cv2pdb to convert the GDB information to a .PDB.

[tim-lebedkov]

Here is a small program:

Issue43.zip

[CyberShadow]

Could you please add build instructions (full compiler command line) and exact version of toolchain used (preferably with download links)?

[tim-lebedkov]

The command line (also in the .cpp file): C:\Users\t>C:\ProgramFiles\MinGW-w64_x86_64_SEH_POSIX_threads-4.9.2\bin\gcc -g "C:\Users\t\Downloads\Issue43.cpp" -o "C:\Users\t\Downloads\Issue43 .exe"

GCC version: C:\Users\t>gcc --version gcc (x86_64-posix-seh-rev1, Built by MinGW-W64 project) 4.9.2 Copyright (C) 2014 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[tim-lebedkov]

you can download the compiler from here: https://github.com/tim-lebedkov/packages/releases/download/2016_Q1/x86_64-4.9.2-release-posix-seh-rt_v3-rev1.7z

[CyberShadow]

@tim-lebedkov Sorry, I can see that you uploaded that to your personal GitHub account. Did you build that yourself (if so, how?), or did you download that initially from somewhere else (if so, where?)?

[CyberShadow]

I am somewhat confused because in our test suite we have a test specifically for gcc 4.9: https://github.com/VerySleepy/tests/tree/master/tests/gcc49-64

[CyberShadow]

or did you download that initially from somewhere else (if so, where?)?

Found it: https://downloads.sourceforge.net/project/mingw-w64/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/4.9.2/threads-posix/seh/x86_64-4.9.2-release-posix-seh-rt_v3-rev1.7z?r=https%3A%2F%2Fsourceforge.net%2Fprojects%2Fmingw-w64%2Ffiles%2FToolchains%2520targetting%2520Win64%2FPersonal%2520Builds%2Fmingw-builds%2F4.9.2%2Fthreads-posix%2Fseh%2F&ts=1499894864&use_mirror=10gbps-io

[CyberShadow]

@tim-lebedkov Your example program works for me:

Please make sure you are using the latest version from CI. If possible, please test on another machine as well.

[tim-lebedkov]

You're right. The Issue43.exe can be profiled with the version from CI. This is still not the case with my application. BTW, another workaround is to use CodeXL. In the newest version it supports GCC debug information.

[CyberShadow]

OK, if you have time to dig into this deeper please figure out what is different between the small test program and your real application that makes Very Sleepy not understand the results. Some general ideas could be a compiler switch, a certain language feature (like RTTI or something like that), or some sort of limit.

[CyberShadow]

Could you please see if this issue occurs with the latest release: https://github.com/VerySleepy/verysleepy/releases

As the latest release includes many fixes, it's likely that this particular problem was fixed as well. If you encounter further problems, please leave a comment or open a new issue. Thanks!