I'm going to load several elf-fils into TRACE32 and onto the chip.
But Lauterbach only keeps the symbols of the last uploaded elf file.
How can I change the behavior?
data.load.elf clears all symbols. To prevent TRACE32, tell it to refrain from doing so.
use:
# clear all existing symbols
data.load.elf path\to\myfirst.elf
# additionally load symbols without clearing existing ones.
data.load.elf path\to\mysecond.elf /noclear
Related
I use a symbol store on a network drive to collect debug symbols for our application. The symbols are used while debugging a crash dump file that has been loaded into Visual Studio. I have Powershell scripts in place that manage deleting ‘old’ versions of symbols. Or, so, I thought.
Recently, while working on another script, I noticed that using symstore to delete symbols doesn’t actually delete anything. When I use symstore to delete symbols I see a “0000000161.deleted” file in 000Admin folder for example. This file contains entries for the associated debug symbols. It contains entries like:
"Aggregat.pdb\B4E7044117F0469CB321E9FA9003E4CA5","C:\temp\pdbs\1823\Aggregat.pdb"
The first entry above is the folder for the associated debug symbols for the ‘Aggregat’ module. I would expect that when I delete symbols using the transaction ID, that the corresponding folders (ie. B4E7044117F0469CB321E9FA9003E4CA5) would also be removed. It appears like that’s not the case.
Is my assumption correct? Am I responsible for the full cleanup of the symbols store structure?
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 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.
I have a c++ executable for windows and a minidump that I am trying to analyze using windbg.
I copied the assosciated pdb and minidump into the same folder and set the symbol path.
Windbg however complains
DBGHELP: c:\logs\marketdepthserver crashdump\SFMarketDepthServer.pdb - E_PDB_CORRUPT
Besides concluding the file is corrupt.. is there anything else I can determine from this or is there a workaround that will allow me to load the pdb.
!sym noisy : tells you why you failed to load symbols
.reload /f foo.exe - to force load
.reload /f /i foo.exe - to force load with mismatched symbols. This may give you some valuable info.
This is not the answer, but this might work for you as well..
I also got this error long time back. I don't know the reason/solution for this, but I remember that I copied both the files (.exe and .pdb) to a new folder and then reloaded symbols (.reload) after specifying the new symbol path (.sympath) and that worked. (Rebuilding was also not working).
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.