wes
15a2dd31b7
different options used on Vtune for analysis.
|
há 4 anos atrás | |
|---|---|---|
| .. | ||
| README.txt | há 4 anos atrás | |
README.txt
07JUN20
Using -gstabs debugging tag to compile lame.exe, for VTune Profiler, we found differences in the profiling results (sometimes lame.exe/related functions would be shown
and sometimes not).
Found an Intel employee and post,
See Dennis Mochanov: https://software.intel.com/en-us/forums/vtune/topic/852219
"For MinGW binaries VTune expects debugging information in DWARF format. Make sure your application is built with -g or -gdwarf-version option"
& related post: https://software.intel.com/content/www/us/en/develop/documentation/vtune-help/top/set-up-analysis-target/linux-targets/debug-info-for-linux-binaries.html
He suggested to use the DWARF format when compiling (states that VTune expects the DWARF format for MinGW binaries), however the above link states linux targets & binaries.
We are trying to solve the issue in WINDOWS for .exe files. To see if there is an validity in using the DWARF format, we will test out his "suggested advice".
Using the above advice, using the -gdwarf-2 or -g will work with the profiler. -g is for debug info, -gdwarf is the format for the profiler.
Taking out the source path or binary/symbols path is not necessary for the setup of VTune profiler.
having the object or sources files in the working directory is not necessary.
The profiler using "pulling" at a given interval, in this case it is about 1ms. If your program executes faster than the profiler, you won't see it in the
analysis results. This is the main issue
we had for VTune aside from the gcc arguments we found mentioned above.
09JUN20
! adding srv*C:\local_symbols_cache_location*http://msdl.microsoft.com/download/symbols when running analysis in VTune will add function names in the
results/analysis (still doesnt link source files however...) this needs to be done everytime to see function names.
11JUN20
tried to use the below to compile with the supposed debug version of libstdc++ in the Makefile
g++ $< -L C:\MinGW\lib\gcc\mingw32\8.2.0\debug\ -lstdc++ -D_GLIBCXX_DEBUG -g3 -gdwarf-4 -o $(basename $@)\$@
This doesn't seem to work and also does not produce the debug symbols we want with VTune anyways.
VTune is still acting randomly today - i.e. sometimes we get lame.cpp to reference main, sometimes not. Still stuck on libstdc++ debug symbols added.
Today when opening up VTune, it forgot the prior instructions to start analysis (i.e. fold paths and what project executable to use).
Program also crashed upon running for the "first run of the day". Analysis results "catch" maybe 1/5 times when using the "User-Mode Sampling" option for
analysis.
Using -gstabs debugging tag to compile lame.exe, for VTune Profiler, we found differences in the profiling results (sometimes lame.exe/related functions would be shown
and sometimes not).
Found an Intel employee and post,
See Dennis Mochanov: https://software.intel.com/en-us/forums/vtune/topic/852219
"For MinGW binaries VTune expects debugging information in DWARF format. Make sure your application is built with -g or -gdwarf-version option"
& related post: https://software.intel.com/content/www/us/en/develop/documentation/vtune-help/top/set-up-analysis-target/linux-targets/debug-info-for-linux-binaries.html
He suggested to use the DWARF format when compiling (states that VTune expects the DWARF format for MinGW binaries), however the above link states linux targets & binaries.
We are trying to solve the issue in WINDOWS for .exe files. To see if there is an validity in using the DWARF format, we will test out his "suggested advice".
Using the above advice, using the -gdwarf-2 or -g will work with the profiler. -g is for debug info, -gdwarf is the format for the profiler.
Taking out the source path or binary/symbols path is not necessary for the setup of VTune profiler.
having the object or sources files in the working directory is not necessary.
The profiler using "pulling" at a given interval, in this case it is about 1ms. If your program executes faster than the profiler, you won't see it in the
analysis results. This is the main issue
we had for VTune aside from the gcc arguments we found mentioned above.
09JUN20
! adding srv*C:\local_symbols_cache_location*http://msdl.microsoft.com/download/symbols when running analysis in VTune will add function names in the
results/analysis (still doesnt link source files however...) this needs to be done everytime to see function names.
11JUN20
tried to use the below to compile with the supposed debug version of libstdc++ in the Makefile
g++ $< -L C:\MinGW\lib\gcc\mingw32\8.2.0\debug\ -lstdc++ -D_GLIBCXX_DEBUG -g3 -gdwarf-4 -o $(basename $@)\$@
This doesn't seem to work and also does not produce the debug symbols we want with VTune anyways.
VTune is still acting randomly today - i.e. sometimes we get lame.cpp to reference main, sometimes not. Still stuck on libstdc++ debug symbols added.
Today when opening up VTune, it forgot the prior instructions to start analysis (i.e. fold paths and what project executable to use).
Program also crashed upon running for the "first run of the day". Analysis results "catch" maybe 1/5 times when using the "User-Mode Sampling" option for
analysis.