I have used vtune several times in the past, usually without too much trouble. Unfortunately the gaps between each use are often so long that I forget some aspects of how to use it each time. I know that the line number and symbols information needs to be stored somehow. I thought that all that was required was to compile your exe with "Program Database" (/Zi), but I have just done a sampling and found that vtune reports there are no symbols available.
Is there anything I missed?
There are two options for debugging (check $> cl /?):
/Zi enable debugging information
/ZI enable Edit and Continue debug info
Make sure that you have .pdb and manifest file (if generated).
It's not related but maybe turn off optimizations as well.
Like Bua mentioned, you definitely need to be compiling with debugging information enabled. If the pdb files are in the same directory as the exe that you're profiling, then it should be able to find them. If not, you can also try explicitly adding the path to the pdbs in config -> options -> directories. alt text http://software.intel.com/file/21331 Add an item with your symbols directory. You might also want to add a symbol server and symbol cache, because then you'll get symbols for all of Microsoft's public binaries. The image above shows how to add a symbol server with a symbol cache at c:\websymbols. Generally, the format for a "symbol server" is a string of the form:
an example:
SRV*C:\MySymbolCache\*http://msdl.microsoft.com/download/symbol
of the form:
SRV * [CACHE] * [SYM SERVER PATH]
Hope this helps!
The problem has been solved: It turned out that it was a mistake in setting the working directory; "/Zi" appears to be all that is required after all. I don't need to switch off optimization.
Related
Using the symbols window(CTRL + S), i have set WinDbg to load my symbols from a specific location.
Now when i attach my debugger and try to view the stack window, it seems like symbols aren't really loaded properly.
Now, when i use the !sym noisy command and .reload /f, i get the following info from the debugger:
So, from the third picture, why is SYMSRV is even defined? and why is it adding the GUID prefix to the end of the file?
It would've worked if it wasn't that guid windbg adds to the path. What am i doing wrong.
EDIT: after reviewing the log furthermore, i see that the debugger attemps to load the symbol from the local drive.
There are several different formats in which symbols can be stored. These are 0-tier, 2-tier and 3-tier.
0-tier is basically a flat list of files, which is suitable if you have just built your program and all the PDBs are located in one folder. If you enter a local path like c:\path or server share like \\server, WinDbg should consider a 0-tier store layout, but might try others as well.
The problem is that you can only store one version of PDBs in a 0-tier store, which is why the 2-tier and 3-tier symbol stores exist. When symbols are added to such a store, it will consider the GUID, so it is possible to store several versions of the same program. 2- and 3-tier symbol stores should start with srv*. The exact difference between a 2-tier and a 3-tier store is explained in Channel 9 episode 87 and it's possible to convert a 2-tier store into a 3-tier store.
Do not confuse the srv* symbol path syntax with the SYMSRV: debug output. IMHO the SYMSRV: is just a debug message of the symsrv.dll, so nothing to worry about.
The truth about loading symbols can only be monitored with Process Monitor. Not all location where WinDbg searches for symbols are logged, even in the noisy mode.
In addition to the symbol path, DLLs contain a reference to the local path of the PDB and WinDbg will consider this path, independent of the symbol path settings.
I've got a C++ project in MSVS 2013, which causes problems when debugging: whenever I run a debug session, a message box shows up, saying "No Debug Information -- Debugging information for 'xy.exe' cannot be found or does not match. Cannot find the PDB file. Do you want to continue debugging?" This is a common issue and the question was asked several times, however, none of the answers I found so far apply to my case.
Project Properties -> Configuration Properties -> C/C++ ->
Optimization -> Optimization is disabled
Project Properties -> Configuration Properties -> Linker -> Debugging -> Generate Debug Info is turned on
Path and filename are correct; Project Properties -> Configuration Properties -> Linker -> Debugging -> Generate Program Database File is "$(OutDir)$(TargetName).pdb" (Output File is "$(OutDir)$(TargetName)$(TargetExt)", so there's no misconfiguration here either)
I tried deleting the file manually, restarting Visual Studio, cleaning and rebuilding. From the file timestamp I see it is indeed the PDB file just created, and both exe and pdb are built to the very same folder and are named correctly.
Someone suggested doublechecking the task manager and see if devenv.exe is still running in the background -- indeed, it was. I killed it, deleted PDB files, restarted, cleaned, rebuilt, no luck.
I switched the startup project to a different one and back, as a poster suggested [1]. No luck.
Somebody reported having this issue when the local PDB file of the main project has the same name as the final PDB file for the entire executable [2]. This is not the case here.
When I open the Modules Window [3], I see that for my exe, in the "Symbol Status" column, it says "Cannot find or open the PDB" file. When I try to right click -> Load Symbols, I see they are right there (e.g. xy.pdb for xy.exe). When I select them, a message box says "A maching symbol file was not found in this folder."
Interestingly, none of the projects in this solution work. Other projects, however, work withouth any problems. I tried to compare each and every setting in the project properties with the ones that work, but I cannot find any differences.
Any more ideas?
[1] https://stackoverflow.com/a/15378106/4508058
[2] https://stackoverflow.com/a/21640745/4508058
[3] https://stackoverflow.com/a/540599/4508058
Okay, a hint to future readers: now it is finally working. I noticed that the project shared it's intermediate directory with another project. However, just changing this, cleaning, rebuilding, even deleting the intermediate directory manually didn't help. But after some builds it finally worked, so it might have had something to do with it (?). So I don't have an absolute solution to the problem, but maybe it helps.
I sometimes still get the Linker error I mentioned in my comment above, though (LNK1209: program database 'D:\work-coding-\Projects\vrtheater\LoadingApp\bin\LoadingAppD.pdb') so there still might be something wrong...
The c++ compile also needs generate debug info /Zi. If that is also set, use windbg with !sym noisy to see where it is trying to load symbols.
I followed the instruction from this video to run the code line by line:
http://www.youtube.com/watch?v=6CGH9Z19dS8
However, after I pressed F8, it just ran without going to the breakpoint(I couldn't see the yellow triangle). In addition, I also tried "attach to process", and it was the same.
Did I miss anything?(btw, there are multiple files in my project, but I guess that won't be the problem, right? cuz I could do this easily in VS studio. Perhaps, I am not that familiar with codeblocks)
Thanks for help!
If you are interested, this is the debugger log:
Building to ensure sources are up-to-date
Selecting target:
Release
Adding source dir: C:\Users\liuca_000\Documents\Lattice_Boltzmann_code\lattice_boltzmann\
Adding source dir: C:\Users\liuca_000\Documents\Lattice_Boltzmann_code\lattice_boltzmann\
Adding file: C:\Users\liuca_000\Documents\Lattice_Boltzmann_code\lattice_boltzmann\bin\Release\lattice_boltzmann.exe
Changing directory to: C:/Users/liuca_000/Documents/Lattice_Boltzmann_code/lattice_boltzmann/.
Set variable: PATH=.;C:\Program Files (x86)\CodeBlocks\MinGW\bin;C:\Program Files (x86)\CodeBlocks\MinGW;C:\Python27\Lib\site-packages\PyQt4;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Windows\System32;C:\Windows;C:\Windows\System32\wbem;C:\Windows\System32\WindowsPowerShell\v1.0;C:\Python27;C:\Python27\DLLs;C:\Python27\Scripts;C:\Python27\Lib\site-packages\vtk;C:\Python27\gnuplot\binary;C:\Python27\Lib\site-packages\osgeo;C:\Program Files (x86)\pythonxy\SciTE-3.3.2-3;C:\Program Files (x86)\pythonxy\console;C:\MinGW32-xy\bin;C:\Program Files (x86)\pythonxy\swig;C:\Program Files (x86)\pythonxy\gettext\bin;C:\Program Files\MATLAB\R2012b\runtime\win64;C:\Program Files\MATLAB\R2012b\bin;C:\Program Files\TortoiseSVN\bin;C:\Program Files\MiKTeX 2.9\miktex\bin\x64;C:\Program Files (x86)\Windows Live\Shared;C:\Users\liuca_000\AppData\Roaming\MiKTeX\2.9\miktex\bin\x64;.;\
Starting debugger: C:\Program Files (x86)\CodeBlocks\MINGW\bin\gdb.exe -nx -fullname -quiet -args C:/Users/liuca_000/Documents/Lattice_Boltzmann_code/lattice_boltzmann/bin/Release/lattice_boltzmann.exe
done
Registered new type: wxString
Registered new type: STL String
Registered new type: STL Vector
Setting breakpoints
Reading symbols from C:\Users\liuca_000\Documents\Lattice_Boltzmann_code\lattice_boltzmann\bin\Release\lattice_boltzmann.exe...(no debugging symbols found)...done.
Debugger name and version: GNU gdb (GDB) 7.5
Child process PID: 16672
[Inferior 1 (process 16672) exited normally]
Debugger finished with status 0
Even if you have had marked -g compiler option the problem may be spaces in path to the project file. Moving to place with no spaces in path solved the problem in my case.
See that: http://wiki.codeblocks.org/index.php?title=Debugging_with_Code::Blocks#Path_with_spaces
I think this part of your log says why:
(no debugging symbols found)
build a debug version of your code - no optimisation, debug symbols included or built and try again.
Spent quite a while working through this today trying:
"Make sure using "debug" instead of "release"
"No spaces in directory names"
"-g ticked, -s unticked"
"download a nightly"
None worked until, I figured I had been making a very novice mistake unfamiliar with the IDE and to debug so it stops at the break points you have to run with the red arrow not the green one. So anyone as silly as me hopefully this helps! xD
You seem to have found a solution that is the wrong solution and likely
to have adverse consequences. (Apologies if I am mistaken)
Your were unable to set breakpoints because your build contained no debugging
information (as you now know); and the build contained no debugging information
because you were trying to debug a Release build and not a Debug build.
You can see this in the build log:
Adding file: C:\Users\liuca_000\Documents\Lattice_Boltzmann_code\lattice_boltzmann\bin\Release\lattice_boltzmann.exe
and also:
Reading symbols from C:\Users\liuca_000\Documents\Lattice_Boltzmann_code\lattice_boltzmann\bin\Release\lattice_boltzmann.exe...(no debugging symbols found)...done.
The executable generated by a Release build will be <project_dir>\bin\Release (as it is), and the executable
from a Debug build will be in <project_dir>\bin\Debug
It appears that you have "solved" the problem by going to Build Options -> Compiler flags and ticking
the checkbox Produce debugging symbols.
But if you go back there and look at the tree control at the left of the window I expect you
will see:
lattice_boltzmann
Debug
Release
with Release selected. That means you have now configured your Release build
to contain debugging information. You don't want that because:-
Although you will now get debugging symbols in the executable and the debugger will be able to use them, the Release build is still configured with high optimisation by default (as it should be) and you are very likely to find that the behaviour of the debugger is at times strangely puzzling, because the optimized object code doesn't always properly match up with the source code.
Your Release executable will be vastly inflated in size by the debugging information.
What you should have done is simply to ensure that the build you tried to debug was
a Debug build. To do that:
Navigate from the top menu bar Build -> Select Target
Uncheck Release. Check Debug
Then Rebuild the project (i.e. clean and build) and you will be able to debug it
properly. Code::Blocks default options for a Debug build are perfectly fine.
Don't forget to go back and remove the -g option from the Release configuration.
I am having trouble with very large object files being produced. We are working with VxWorks 5.5.1, but we have a GCC 4.1.2 available.
Our modules are roughly 6.2MB in size, and we are looking for ways to reduce that. The problem seems to be mainly caused by excessive use of templates. When dumping the symbols in the file using nm I get a text-file of 1.8MB. This tells me that almost ⅓ of the file is just the names. Is there any way to reduce the file size?
The following approaches have not worked:
--strip-all seems to have no effect - the output is the same as using --strip-debug
I cannot use --gc-sections, because it is not supported for that platform (the option is simply ignored)
I understand that VxWorks links the code at load time, but all it has to link is the C++ runtime library, and I don't want any symbols to be added to the global symbol table, so there should be a way to strip that information, right?
For reference, here is my linker version:
i386-wrs-vxworks-ld.exe --version
>>> GNU ld (Wind River VxWorks G++ DWARF-EH 4.1-131) 2.17.50.20070509
>>> SPR fixes: cq103489 cq111170 cq116027 cq116652 cq118878 cq125145
and my compiler version:
i386-wrs-vxworks-g++.exe --version
>>> i386-wrs-vxworks-g++.exe (GCC) 4.1.2
I see what you mean by wanting to strip the symbols out of the object. But if you were to strip all the symbols, you wouldn't have any symbol to use as the entry point to start your application. But I believe you still have options. Unfortunately VxWorks 5 is known for having a not very effecient C++ compiler.
If you compiled your application into a *.a (archive - aka static library), you would be able to link this into your operating system at build time, and call this from within usrAppInit.c. This should allow for striping out symbols - or at least moving them to an optional downloaded symbol table. From your application build properties, select the Macros tab and add your archive to the LIBS macro.
To make an archive, goto the build properties and select the Rules tab, then select archive from the dropdown box.
To trim the size of your OS (with your application linked in), modify your vxworks settings. Disable as many components as you can. Also be sure to use a downloaded symbol table (development tool components -> symbol table components -> symbol table initialization componts -> selecte symbol table initialization -> downloaded symbol table).
This will strip all the symbols out of the OS, and make a downloadable symbol table, that can be downloaded after boot time to debug.
Good luck!
PS. Make sure you have turned off debug (-g) in your compiler. Maybe we could help more if you post your compiler switches.
The way we have normally handled this is to compress the image. You will also need to build the bootrom so that it will decompress to RAM before running. I believe that there are standard makefile options that will allow you to do this.
When I compile the release version of my iOS app (based on standard Apple supplied iOS app template), look into the resulting executable binary, I see all sorts of symbols and even local cpp source and header paths in there. I'm really stumped why this is (I haven't enabled RTTI*). Especially the source file paths make me feel uncomfortable sending this app across the globe (why should everyone be able to see the directory layout of my development machine?).
Here's are two (randomly picked, moderated) excerpts:
TS/../ACTORS/CActorCanvasCharPart.cpplastMeshcapVerticesOFF BOUNDSupload VERTICES: %d
20CActorCanvasCharPartgrassscrub/Volumes/Data/iOS_projects/code/MyAppName_proj/MyAppName/source/STATES/GAMES/2/CStateGame2_grass.cppbaseShadowmowerstartmowerloopmowermowerCharcutGrassChargrassStuffgrassParticles/Volumes/Data/iOS_projects/code/MyAppName_proj/MyAppName/source/STATES/GAMES/2/CStateGame2_grass.h17CStateGame2_grasssinwriteStroke/Volumes/Data/iOS_projects/code/MyAppName_proj/MyAppName/source/STATES/GAMES/2/CStateGame2_flowers.hflowerBedsandTrailclickstart3inplace2sandDrag/Volumes/Data/iOS_projects/code/MyAppName_proj/MyAppName/source/STATES/GAMES/2/CStateGame
And here are a lot of symbols for self-defined types and structs:
CAssetMgr="_vptr$CMgrBase"^^?"pMain"^{CMain}"inited"B"curveCount"S"curveSpecs"^{CCurveSpec}"gameSpecs"[23{CGameStateSpec="header"{SpecDiskHeader="type"i"version"S}"gameID"C"backgroundColor"{CRGBAcolorf="r"f"g"f"b"f"a"f}"clickPointColor"{CRGBAcolorf="r"f"g"f"b"f"a"f}"clickPointIconColor"{CRGBAcolorf="r"f"g"f"b"f"a"f}"hintColor"{CRGBAcolorf="r"f"g"f"b"f"a"f}}]"currentFont"^{CCharset}"userCharParts"^^{CCharPart}"words"{CDataSet<CName4,CCharArray>="_vptr$CObjectBase"^^?"pMain"^{CMain}"count"i"data"*"dataSize"l}"sets"{CDataSet<CName16,CCharArray>="_vptr$CObjectBase"^^?"pMain"^{CMain}"count"i"data"*"dataSize"l
Can this be avoided, how?
*UPDATE: I just found out that RTTI is on by default. So I cleaned the target, disabled RTTI (GCC_ENABLE_CPP_RTTI = NO) and recompiled. I still see a lot of symbols and source paths in the binary.
UPDATE 2: I checked a few other apps from the app store, and many of them also have their source file paths show up. Pretty scary, if you ask me:
Joined Up Lite
/Users/lloydy/Documents/Development/iPhone/ABC Joined Up/main.m
/Users/lloydy/Documents/Development/iPhone/ABC Joined Up/Classes/SettingsView.m
Crayon Physics
/Users/smproot/Desktop/unzip/CrayonPhysics/v104/Classes/crayon/src/ceng/gameutils/killspriteslowly/killspriteslowly.cpp
/Users/smproot/Desktop/unzip/CrayonPhysics/v104/Classes/crayon/src/ceng/tasks/task/sdl/mixer/ctaskaudiosdlmixer.cpp
Wall Times
/Users/fred/_WORK/ZDNDRP/WallTimes/main.m
/Users/fred/_WORK/ZDNDRP/WallTimes/Classes/SystemCategories.m
Jumbo Calculator
/Users/Christopher/Documents/Development/JumboCalculator 1.0.3/main.m
/Users/Christopher/Documents/Development/JumboCalculator 1.0.3/Classes/CalculatorFaceViewController.m
The file paths are most likely from assert macros which stringify __FILE__ as part of their failure message. iOS's implementation of assert(3) does this, as do the NSAssert macros.
You can remove asserts in release builds by defining NDEBUG (for the C asserts) and NS_BLOCK_ASSERTIONS (for NSAsserts).
In Xcode set Deployment Prostprocessing to Yes in order to trigger Xcode to call the strip command during build process. Then you don't see any source path via nm -a.
However, I still see the source paths of some m files via the strings command :/
What worked for me was setting Generate Debug Symbols to No for release builds. This is under the Apple LLVM 7.0 - Code Generation in Xcode 7.2.
Have ticked the strip debug symbols in the build settings? You can do this (or not) depending on the configuration (build/release). Also you can look into Objective-C Code Obfuscation (which is long winded). From what I gather, you cannot completely remove objective-c information as all method calls are done dynamically, so the library has to have information about your classes/method names in order to function. A useful tip here.
If you have c++ code then you can use the gcc strip utility, although I'm not sure how it like Objetive-C++, if it doesn't you could compile all you cpp into a lib, strip that and link against it in your iOS project.