Chinaunix首页 | 论坛 | 博客
  • 博客访问: 1567674
  • 博文数量: 237
  • 博客积分: 5139
  • 博客等级: 大校
  • 技术积分: 2751
  • 用 户 组: 普通用户
  • 注册时间: 2008-11-18 14:48
文章分类

全部博文(237)

文章存档

2016年(1)

2012年(4)

2011年(120)

2010年(36)

2009年(64)

2008年(12)

分类: C/C++

2009-06-19 17:46:02

S60 breakpoint problem. When setting a breakpoint but the debugger wasn’t stopping and the editor was showing a warning symbol over the break.

unresolvedbreak.jpg

第一种可能的情况:

When the debugger can’t determine where to set a breakpoint you will see a little warning symbol on top of the breakpoint. This usually means that there hasn’t been an executable loaded that was built with the source file the breakpoint is in(可执行程序不包含可容纳断点的源文件). So if you are debugging with the emulator but you haven’t opened your app(使用epoc模拟器调试,但并没有打开你想调试的程序) yet then your breakpoints will be shown this way. When you do something that causes your code to get loaded then Carbide will install the breakpoints in the correct place and the warning marker will go away. (可见所调试的程序必须是对应的源文件所编译出来的)

When using the emulator you can see exactly what bits of code are loaded by turning on the “Show System Messages” option in the launch configuration dialog. I used this to verify his executable really was loaded when it appeared to be.

systemmessages.jpg

第二种可能的情况:

If you are sure the source file with the breakpoint is in code that gets loaded and executed then the problem may be that Carbide’s debugger isn’t loading symbols for the executable. We need to load the compiler-generated symbols for an executable so we can translate the source location of the breakpoint into an address in memory where we can tell the debugger to stop. If we don’t load symbols for an executable then this won’t happen and the break will remain unresolved.

Loading symbols for an executable is required to set breakpoints but there is also a performance hit each time we do it. So Carbide tries to guess which executables you are interested in debugging and only loads symbols for those files. Normally this includes any executables produced by any of the projects in your workspace for the SDK you are debugging in. But my Dallas colleague had set the breakpoint in a source file for a library he wasn’t building. The library he was building was calling it but the debugger didn’t know that. The debugger wasn’t loading symbols for that library and so couldn’t determine where to set his breakpoint.

If you open the Executables View you can see a list of the executables Carbide thinks you are interested in debugging. If you want to add more to this list just drag the executable file into the view and the debugger will be able to set breakpoints in that file too. Once we added his other executable in then the breakpoints lost their warning symbol and worked correctly
阅读(908) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~