Tips for using Breakpoints

原文地址

 

I've been working with one of our customers the last couple of days,and found that there were a few handy tips for using the PlatformBuilder debugger with Windows CE that I knew and they didn't.  So I amsharing them here.

Uninstantiated Breakpoints

If you've ever tried to set a breakpoint, but gotten the pink-coloruninstantiated circle (indicating that the breakpoint is not yet set)instead of the maroon-color circle (indicating that the breakpoint isset), the problem might be something like this:

• Wrong source file:  The code you set a breakpoint in isn't actually running.
• Bad source path mapping:  The binaries andPDBs you use contain strings indicating where the source code camefrom.  But those strings are inserted when they are compiled.  If youare trying to set a breakpoint inside of code that Microsoft compiled,then the strings will indicate a location that does not exist on yourmachine.  The "source path mapping" is a mapping from the locationsthat are compiled-in to the code (eg.c:/SomeMicrosoftBuildMachine/foo/...) to the corresponding locations onyour machine (eg. D:/WINCE500/bar/...)  If you have ever had PlatformBuilder ask you for a source location when you tried to set abreakpoint, it's probably a source path mapping question.  If yoursource path mapping is wrong for the file you set the breakpoint in, orif PB gets confused about it somehow, then it may not understandproperly that the code you're looking at is the code that's running onthe device.
• Bad symbols:  The PDB files in your releasedirectory don't match the EXEs or DLLs that are running on the device. Usually this results in the breakpoint being set in some random otherlocation in the code.
  • Common issue #1: you built the .exe or .dll more
    recently than the .pdb.  This can happen if you rebuild while debugging;
    Platform Builder will hold the .pdb open and the compiler won't be able to
    overwrite the .pdb.  Fix by rebuilding while you are not debugging the
    module.
  • Common issue #2: you built the .pdb more recently than the .exe or
    .dll.  Usually this happens if it's a file in ROM and you forgot to re-run
    makeimg.  Or if you rebuilt the .exe/.dll but the old version is still
    running on the device.
  • At worst, all of these problems can be fixed by
    disconnecting from the device, rebuilding, re-running makeimg, and
    reconnecting.  But as you get familiar with how the tools work you should be
    able to figure out quicker ways of working.
• Optimizations: The code is optimized (= release build) and the source line with the pink breakpoint doesn't
  mapto code the debugger understands.  In this case you might have toswitch to a disassembly window, examine the disassembly and place yourbreakpoint using that window.  Or build a debug version of your code,so that the
  optimizations don't confuse the debugger.
• Module not loaded:  The breakpoint cannot beinstantiated until the code is actually loaded.  So if the DLL or EXEis not loaded, the breakpoint will stay pink.  When the DLL or EXE isloaded it should become maroon.
• Breakpoint is pending:  The debugger onlyinstantiates breakpoints while the device is stopped for debugging. Not while the device is running.  Our debugger doesn't stop the devicefrom running in order to add the breakpoint when you set it.  Insteadit waits until you break into the debugger before setting thebreakpoint.  PB also breaks into the debugger automatically for a verybrief time whenever a DLL or EXE is loaded or unloaded.  So you mayfind that the breakpoint becomes instantiated when that happens.
• Debugger is not connected:  Try running "sloaddbg" in the target control window.  That will load debugger DLLsand connect the PB debugger.  To run that, you will need: loaddbg.exeand kd.dll, and if present in your release directory you'll needhd.dll, osaxst0.dll and osaxst1.dll.  You can also get the debugger tostart automatically during boot if you make sure that the IMGNODEBUGGERflag is not set before you make a new image.
• Flash ROM: You can't debug ROM.  By that I mean,if your image is running directly from flash ROM, the debugger can'tedit the ROM to insert your breakpoint.  A breakpoint is just areplacement of the existing code with a call to stop in the debugger,so if the debugger can't edit the code it can't insert the breakpoint. You can debug if your image is running from RAM, or if your .dll or.exe is running from RAM (which is generally true if it's not in theMODULES section of ROM).
• If the modules you are trying to debug are built with VS2005, thereis a QFE to Platform Builder 5.0 to support VS2005 symbols.  The updateis in the 2005 update package at http://www.microsoft.com/downloads/details.aspx?FamilyID=6c69461e-89fa-40b0-8953-b4cc1adbc8d8&DisplayLang=en.  You can also just copy msobj71.dll into “Program Files/Windows CE Platform Builder/5.00/CEPB/BIN”.

Breakpoints without source

You can set a breakpoint even if you don't have the source code toset it on.  If you know the exact function name and module name you canuse the breakpoint window to break on function entry.  In the Viewmenu, go to Debug Windows / Breakpoint List.  You can also get there byclicking the "hand" icon on the debug toolbar or by hitting ALT + 9. In the breakpoint window, create a new breakpoint using this syntax:

    {,,modulename} function_name

That's an open curly-brace, two commas, module name, closecurly-brace, function name.  You can use this for EXEs or DLLs.  Forexample:

    {,,nk.exe} SC_QueryPerformanceCounter
    {,,pm.dll} PlatformSetSystemPowerState

This syntax is not actually specific to breakpoints.  It's just away to tell the debugger that a symbol is specific to a module.  Forexample if you want to look at a global variable in the Watch window,you can use this syntax there too.  For example you could type{,,nk.exe}CurMSec in the Watch window to see that global variableinside the kernel.

By setting a breakpoint on a symbol instead of a source file line,you use only the PDBs to set the breakpoint.  There is no dependency onhaving the right source file or source path mapping.

Don't just guess random function names when using this methodthough.  OS APIs often have prefixes and postfixes that differ fromtheir official names (eg. the implementation of CreateFile isFS_CreateFileW) and may be completely different (eg. for some reasonthe implementation of DeleteAndRenameFile is calledFS_PrestoChangoFileName...  I like that one :-) ).  You can search the.map files in your release directory to get clues about what the APInames are.

The other useful thing about the breakpoint window is that you cansee if your breakpoint changes are pending.  Like I mention above, ifyou set (or unset) a breakpoint while the target device is stillrunning, the change will not occur until you stop in the debugger.

Other tips

If you have a bunch of breakpoints set you may notice that yourdevice is running slower.  Every time a DLL or EXE is loaded thedebugger does work to figure out if it needs to instantiate abreakpoint inside the module.  Unfortunately from my experience,deactivating the breakpoints does not help.  I don't know why.  Youwould have to completely delete the breakpoints in order to get back tonormal speed.  My advice is not to do that though.  Delete breakpointswhen you're totally done with them, but don't let debugger speed putyou into the habit of setting & deleting breakpoints left andright.  Slower speed is better than having to redo some debuggingbecause you forgot to set something.

Happy debugging...

UPDATE Dec 9, 05: I added the "debugger is not connected" case above.
UPDATE Dec 4, 06: I added some more details to the "Bad Symbols" case and added the "Optimizations" and "Flash ROM" cases.
UPDATE Jan 5, 07: Added bullet about the QFE to support VS2005 symbols.
UPDATE Feb 14, 07: See also http://blogs.msdn.com/hopperx/archive/2007/02/14/map-file-breakpoints.aspx