今天的计划是先完成：用全加器full_adder构建一个四位的逐位进位加法，编写测试平台验证其功能。然后，测试平台修改为从文件中读取输入值，进行仿真和验证，并将观察到的输出结果写入文件。（虽然，操作文件不是很难，就想多练一下）
    编写测试平台没有花多久的时间就完成了，解决几个编译过程中的小问题后，编译通过。运行可执行文件，然后出现了人生的第一次Core dumped。

    what's this? 虽然4个单词认识3个，但仍然不知道这个要表达什么意思，按惯例，百度一下，找到这一篇文章

http://blog.csdn.net/yam_killer/article/details/7970163

    其实，这位仁兄介绍了那么多指令，在我电脑上有反应的只有这一条：#ulimit -c 1024 ，用了这一条指令后我才看到core.xxxx。      
    所以，当程序dump掉以后,没有生成core时,用ulimit -c 1024这个指令可以生成core.****,其中****是程序运行时的PID号。然后就可以看到core.xxxx文件了。

别问我为什么有这么多。按照
(http://blog.csdn.net/yygydjkthh/article/details/7470671)这位大哥的文章里面的操作应该可以定位到出错误的具体一行的，可是，并没有想的那么简单，我只弄出了这个样子，没有具体到错误的行。

    也许是我的问题太古怪，自己把各个.h和.cpp可能会有问题的地方都尝试修改了一下，然后就出现了许多core文件，但都没有解决问题，看来从core文件这里是找不出原因了，竟一时陷入迷茫，根据此前的经历，遇到问题后去百度一下，基本上能找到解决办法（在此谢谢那些分享经验的人）。这次居然不起作用了！？怎么办？
    只能问刘师兄了，师兄有点事情，给我介绍了另一个前辈--周*，把问题给周前辈简单说了一下，前辈给了一个简单粗暴的办法---“cout”，即在程序各处加上cout输出语句，以此判断程序死在哪一步，我在主函数里面加上cout以后，立即就定位到了问题所在地（谢谢前辈指点）

    2 ok 没有出现，那么问题就在full_adder_4_bit里面了，到full_adder_4_bit继续cout

    运行后 fu1 OK 没有出现，范围更小了！仔细看看这个图

    修改以后，错误消失，最终实现功能。

    一个大意造成的小错误打乱了今天的计划，尝试了网上各种Segmentation  fault (Core dumped)的解决办法以后，我本来打算跳过这个问题，继续看后面的内容，但最后还是没有放弃，内心独白是 说不定从这个问题的解决中能学到更多，书本上的东西永远在那里，可这个错误万一错过可能就不好再遇到了，不能放弃这个机会。最后问题得以解决，从这个过程的确学到不少。
    实际上，过去自己在写C#程序调试的时候也经常用打印输出的办法寻找问题行，在用keil给单片机写代码的时候也用串口调试看程序的运行状态，画单片机板子的时候都会加几个LED来方便调试，过去那么熟练的方法，怎么在Linux下写systemc就没有想起呢？ 可能的原因是，自己对linux和systemc太崇拜了，总觉得很高大上，自己以前的一套办法都是低端应用，怎么能解决这些高端问题呢，还有一点就是不敢用，怕造成什么不可预知的问题。总结起来，无非就是对这两个new things不了解，心生敬畏。
    学习一门编程语言，个人认为，可以分成两个部分。1.学习其数据类型和逻辑语法。2.在练习中实现自己想要的功能并解决出现的bug。今天主要做了第2部分的事情。

    （最后提醒，在修改程序过程中，我发现，g++编译器对.h文件不感冒啊，修改.h文件以后，保存再编译，居然提示可执行文件已经是最新的，然后不编译；我的解决办法是：重新编译前把所有.o 文件和生成的run文件删除掉，Linux的优点就出来了 直接 rm -f *.o 然后一堆.o文件就处理干净了）