今天在调试KE02的串口Bootloader时，由于中断向量表地址配置的错误，总是会出现0x400地址出现错误。心血来潮，发现每次在IAR调试下载时使用的 Debug with Downloading旁边还有一个Debug without Downloading选项，于是斟酌起其含义，从字面意思理解似乎是前者下载并且调试，后者调试但是不下载，不下载怎么调试，在RAM？于是困惑非常，Baidu了一圈也没看到有特别实质性的解释。所以，自己动手丰衣足食，就地取材，察看了IAR的help 文档，然后结合KE02的Bootloader APP代码测试了一下。
从IAR的help 文档可以看到两者的含义：
1.&Debug with Downloading：&Downloads the application and starts C-SPY so that you can debug the project object file. If necessary, a make will be performed before running C-SPY to ensure the project is up to date. This command is not available during a debug session.
下载应用程序，并且启动C-SPY以至于用户可以debug工程的Object 文件，在运行C-SPY之前IAR通常会先make一下工程，从而确保当前的Object文件是最新的（看起来每次修改完代码不用编译，如果使用这个选项，IAR在下载前就会自动编译代码了，从此再也不用担心修改完的代码忘记编译了）。
2.&Debug without Downloading：&Starts C-SPY so that you can debug the project object file. This menu command is a shortcut for the Suppress Download option available on the Download page. The Debug without Downloading command is not available during a debug session.
启动C-SPY以至于用户可以Debug工程Object文件，这个命令不会执行下载到Flash的操作，
看完这些，表示依然迷惑不已。于是结合KE02的Bootloader APP代码测试了一下。
思路很简单：APP中修改红色字体为with download和without download，然后依次分别执行Debug with Downloading、Clearn、Debug without Downloading查看结果，发现两种方式得到的结果都是如下图所示。
& & & & & count++;
& & & & & printf(&\ncount=%d\n&,count);
& & & & & printf(&\nRunning the Blink_use_bootloader without download\n&);
& & & & //for(i=0;i&0i++);
于是得出两者的区别，Debug with Downloading会每次下载到MCU，并启动C-SPY开始运行；而Debug without Downloading不会向MCU烧写代码，只会对上一次写入的代码进行调试，不会调试最新编译后的代码，个人感觉其作用在于，不必要经历重新Download的过程，从而节省时间，如果代码有改动一定要使用Debug with Downloading，否则修改后的代码不会生效。
旗下网站：
与非门科技(北京)有限公司 All Rights Reserved.
京ICP证:070212号
北京市公安局备案编号： 京ICP备：号2002年5月 Delphi大版内专家分月排行榜第一2002年1月 Delphi大版内专家分月排行榜第一
2007年11月 .NET技术大版内专家分月排行榜第二2007年1月 Delphi大版内专家分月排行榜第二2006年12月 Delphi大版内专家分月排行榜第二2006年10月 Delphi大版内专家分月排行榜第二2002年8月 Delphi大版内专家分月排行榜第二2002年6月 Delphi大版内专家分月排行榜第二2001年12月 Delphi大版内专家分月排行榜第二
2002年5月 Delphi大版内专家分月排行榜第一2002年1月 Delphi大版内专家分月排行榜第一
2007年11月 .NET技术大版内专家分月排行榜第二2007年1月 Delphi大版内专家分月排行榜第二2006年12月 Delphi大版内专家分月排行榜第二2006年10月 Delphi大版内专家分月排行榜第二2002年8月 Delphi大版内专家分月排行榜第二2002年6月 Delphi大版内专家分月排行榜第二2001年12月 Delphi大版内专家分月排行榜第二
2002年5月 Delphi大版内专家分月排行榜第一2002年1月 Delphi大版内专家分月排行榜第一
2007年11月 .NET技术大版内专家分月排行榜第二2007年1月 Delphi大版内专家分月排行榜第二2006年12月 Delphi大版内专家分月排行榜第二2006年10月 Delphi大版内专家分月排行榜第二2002年8月 Delphi大版内专家分月排行榜第二2002年6月 Delphi大版内专家分月排行榜第二2001年12月 Delphi大版内专家分月排行榜第二
本帖子已过去太久远了，不再提供回复功能。debuginfo-install glibc-2.12-1.166.el6_7.3.x86_64类似的问题
& & && & 在使用gdb进行调试的时候，可能会出现如下问题：debuginfo-install glibc-2.12-1.166.el6_7.3.x86_64，其实碰到此类问题继续continue就可以了，debuginfo通常是调试glibc本身使用。& & & &通常我们的解决方式如下：& & & (1)如果没有debuginfo-install命令的话，使用yum &install &yum-utils来安装此命令。& & & (2)如果/etc/yum.repos.d/CentOS-Debuginfo.repo文件中的enable不为1，修改为1.& & & (3)之后就可以使用gdb中给出的建议命令来进行安装操作了。& & & (4)如果没有glibc的话，使用yum &install &glibc来进行安装。
最新教程周点击榜
微信扫一扫C语言的debug ,log ,try - 开源中国社区
当前访客身份：游客 [
当前位置：
哈。好久没有水技术贴了。这里讨论一下C语言的 debug,log,try的区别和用法。
log大家都知道，我先简单重复一下作用，log的目的是对程序运行态下，运行状态的一个记录。
debug是什么？debug就是debug哈。我仍然坚持一个原则，其他C 程序员是否坚持和我没关系。即，不使用IDE。不使用DBG。
不使用IDE的主要原因是没有好的IDE，同时很多debug的策略技巧，IDE也没有办法实际提供。
不使用DBG的原因是，DBG真正能有效快速的DEBUG的场合或情况很少。
debug的模块应该能完成以下几个事情：
1、断言，C标准中有 assert.h这个头文件，对应gcc也有 _assert。断言的作用在于当一个逻辑不符合预期时，给出提示。比较悲催的是，很多库的断言，会调用exit。程序会直接退出。断言有另一个重要功能，使用了预编译的 __FILE__ ,__LINE__，这个作用可以使得在编译时，获取当前位置和当前文件名。由此，断言可以快速准确的找到当前的不合预期的位置。
2、条件判断的信息摘录。这个和LOG有很大区别。
通过断言，我们只能知道错的位置，但不能知道错的原因和机理。由此需要在断言发生前，对一些数据进行必要的输出摘录。这不属于LOG的是。如果你坚持，哈，那你慢慢享受工程操作中的“纠结”吧。
条件判断的信息摘录基本情况为两种，一个是状态判断。例如指定的内存，被改写，或被修改的超过范围。另一个是基数判断。例如我们一个大函数，循环到6543次时出错。你从头开始摘要一些变量的值进行保存显然没有必要，更何况你要摘要很多相关变量的情况下，输出内容会非常多，即影响了后期输出信息的识别，也影响了程序的运行速度。
基于上述两个功能的debug模块，可以说基本上对于C的高级语言部分，已经无敌了。但有些非高级语言可描述的问题就无能为力。例如，我们想判断一个指定的地址被写操作了，或者被读操作了。包括寄存器。这最软的，也需要对应硬件系统的SIMU进行处理。此处暂且不谈。
try，其实也就是等同其他高级语言的try catch。
try和debug，不一样。是属于运行态下的代码，不能将try理解为我在回避一个逻辑错误。而是得看作，try在为同步提供服务（抽象的理解，别和我鬼扯进程同步）。由于其他模块的状态没有到位，资源没有到位，引发的两个模块的逻辑不匹配，此时使用try。
因此，使用try的地方，应该是受外部状态影响，导致内部存在选择性执行的地方。没有try，使用其他方式也能完成，但try可以通过长跳转和重载（不的是面向对象概念）signal 中断相应函数，来实现。这对一个模块处于运行时，在外部同步状态不正确下（资源未到位等），对于保持，不死机，不退出，不服务，三不原则很有帮助。
需要补充的是，log和debug虽然都有信息采集，但debug只是为了抓BUG。这类判断验证逻辑并不是模块需要的，例如无原则的判断入口函数的指针是否为0或超过该指针应该对应的数组地址空间范围等。LOG是记录模块运行状态的，这是模块对外的一个展示，属于模块的必要组成。
debug原则上，应该尽可能的仅使用.h文件进行记录描述。而对于release版本，通过NDEBUG的宏，在预编译时对debug代码进行彻底移除。
LOG完全是个模块。其他模块使用LOG模块进行处理。
try，可以看作利用了setjmp.h ,signal.h的标准，进行的一个封装。属于基本库。即不独立成模块，也不被完全嵌入到其他C文件中。
共有10个评论
<span class="a_vote_num" id="a_vote_num_
这不是水帖，这是重口味帖。 不是一般人能轻易品尝的。
<span class="a_vote_num" id="a_vote_num_
在VC专家的指导下,修改宏在VC也能编译了.
&* This is Micro or printing the log messages
#ifndef cDPRINTF_h
#define cDPRINTF_h
#define LOG_INFO 1
#define LOG_NOTICE 2
#define LOG_DEBUG 4
#define LOG_FATAL 8
#define LOG_ALL 15
extern int g_debug_
#if defined(__GNUC__)
#define D_PRINTF(fmt,arg...){\
& & & & if((g_debug_level|LOG_FATAL )& fmt){\
& & & & & & & & fprintf(stderr,arg); \
& & & & }\
/* MS VC */
#elif defined(_MSC_VER)
#define D_PRINTF(fmt,__VA_ARGS__){\
& & & & if((g_debug_level|LOG_FATAL )& fmt){\
& & & & & & & & fprintf(stderr,__VA_ARGS__); \
& & & & }\
/* not implemented */
--- 共有 1 条评论 ---
哈。不在VC下搞。搞搞就被VC带坏了。。。。
(4年前)&nbsp&
<span class="a_vote_num" id="a_vote_num_
你这个技术贴……
<span class="a_vote_num" id="a_vote_num_
感觉有点混乱
<span class="a_vote_num" id="a_vote_num_
不管用不用IDE，都应该会文本编写代码
<span class="a_vote_num" id="a_vote_num_
C语言本身没有内建的异常机制，如果通过指定函数的那些返回值属于“异常”，显然就没有普适性了。Windows操作系统本身自带结构化异常（SEH），所以VC编译器也支持结构化异常关键字，这还算是有点靠谱。至于其它高级语言嘛，异常机制是很完备的。
在Java Python等高级语言里我一般这样用异常的：属于程序正常逻辑的异常，在哪里出现就在哪里处理；非预料情况下的，属于错误的，不处理，自动往上抛就是了，在最上层捕获并打印调用堆栈（Call Stack），错误在哪里出现、调用顺序一目了然。
程序出现非预料情况下的错误，最好退出，靠外部的“看门狗”重新启动就是了。如果涉及到数据状态等的恢复问题，只能说软件架构不合理。好的架构应该：1、重要的数据独立存放而不应该放在内存中，比如嵌入式里面可以使用文本文件或sqlite存数据；2、程序对外接口应该是无状态的，一个调用就是一个原子操作，不应该和之前之后的调用有任何关联。
日志我习惯四个级别：debug、info、warning、error。debug输出调试信息，发布版本去掉；info输出一般信息，比如程序启动时候显示的版权信息、运行时期显示的状态；warning和error都是错误，区别是error错误是不可恢复的，程序应该立即退出。把调试信息结合到日志中主要目的是为了美观，呵呵，另外日志级别的设置放在配置文件里，这样就不需要因为修改日志级别而重新编译了。
即便程序最终发布，至少非预料的异常和调用堆栈是应该记录的，能多详细就多详细。因为不可预料的错误总是有的。
<span class="a_vote_num" id="a_vote_num_
C语言里调试寄存器、内存等信息，还是不要用打印输出来做吧，一个好的开发环境会提供这样的功能的，另外dump文件里也有的。
IDE嘛Code::Blocks是非常好的，对GCC支持非常好，必备的调试手段都有。
<span class="a_vote_num" id="a_vote_num_
引用来自“mallon”的答案C语言里调试寄存器、内存等信息，还是不要用打印输出来做吧，一个好的开发环境会提供这样的功能的，另外dump文件里也有的。
IDE嘛Code::Blocks是非常好的，对GCC支持非常好，必备的调试手段都有。哈。业务面不一样。我做算法和底层库的，一旦出现逻辑错误，有时需要大量的数据运行后才能出现。例如10分钟以后（EMU的运行下，SIMU不能跑，慢的不是一点两点）等等。内部逻辑关联很强，一致性的信息输出，或断点跟踪方式，都很难处理。IDE嘛，基本还是放弃了。IDE用的越熟练，开发手段越被IDE限制。
<span class="a_vote_num" id="a_vote_num_
引用来自“中山野鬼”的答案引用来自“mallon”的答案C语言里调试寄存器、内存等信息，还是不要用打印输出来做吧，一个好的开发环境会提供这样的功能的，另外dump文件里也有的。
IDE嘛Code::Blocks是非常好的，对GCC支持非常好，必备的调试手段都有。哈。业务面不一样。我做算法和底层库的，一旦出现逻辑错误，有时需要大量的数据运行后才能出现。例如10分钟以后（EMU的运行下，SIMU不能跑，慢的不是一点两点）等等。内部逻辑关联很强，一致性的信息输出，或断点跟踪方式，都很难处理。IDE嘛，基本还是放弃了。IDE用的越熟练，开发手段越被IDE限制。
嘿嘿说到底还是习惯问题
--- 共有 1 条评论 ---
哈。业务决定习惯。。。
(4年前)&nbsp&
<span class="a_vote_num" id="a_vote_num_
更多开发者职位上
有什么技术问题吗？
中山野鬼的其它问题
类似的话题