VTune Profiler now working with proper gcc arguments. lame.cpp now uses enough resources for VTune to capture the activity.

Makefile

@@ -15,9 +15,9 @@ OUTPUT_FOLDER = $(basename $@)
 #  all: ; $(foreach v, $(.VARIABLE), $(info $(v) = $($(v))))
 #  info : 
 #  $(foreach v, $(.VARIABLE), $(info $(v) = $($(v))))
-#  -g enables extra debugging information. enabled this for vtune to work properly.
+#  -gdwarf-2 for debug information for intel VTune Profiler.
 %.exe : %.cpp
-	g++ $< -g3 -gstabs -o $(basename $@)\$@
+	g++ $< -g3 -gdwarf-4 -o $(basename $@)\$@
 
 clean :
 #	del $(basename $(f))\$(f)

ToDo/ToDo.txt

@@ -17,4 +17,7 @@ Some people at StackOverFLOW have a suggestion on how to deal with it.
 Microsoft does not gurantee that a file will be written and be able to be read. To undo this and figure out where a file is being written/read
 the link below may have a possible solution. Since Msft writes files "randomly", when trying to read or modify the same file the program is unable
 to access the file. The below link will potentially help in detection of Msft's read write redirect (Msft claims that they do it both directions...). 
-https://stackoverflow.com/questions/14005081/how-to-detect-file-redirection-to-the-windows-virtualstore 
+https://stackoverflow.com/questions/14005081/how-to-detect-file-redirection-to-the-windows-virtualstore 
+07JUN20
+Add the Microsoft API debug information into VTune Profiler - so other winAPI calls can be tracked, for instance Sleep. 
+Have a release and a debug version of executables -> change Makefile

Vtune Profiling/README.txt

@@ -0,0 +1,18 @@
+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.

lame.cpp

@@ -1,6 +1,10 @@
 #include <iostream>
+// #include <windows.h>
 int main (){
     std::cout << "ha" << std::endl;
-    
+    for (int i = 0;i < 5000; i++){
+    // Sleep(500);
+    std::cout << "hahaha" << std::endl;
+    }
 }