一些调试C编译的随想

终于看到 elf文件了，虽然 hex文件还没有生成成功，想写个随笔，随便说些什么~

 

你可能还不知道，除了和软件相关的所有岗位之外，在 IC设计开发领域有一个叫SOC验证的工种，也需要知道一些C编译，链接的知识。

所以，最近我看到有同事在看《嵌入式C语言自我修养》，我真是一点也不意外。

事实上，市面上ARM为例子将C编译，链接的书，我还没有找到过。

 

新项目，要用到C家两个DSP的core了。C的makefile，include，common函数，嗯嗯，又要搞起来了

好不容易ARM架构很熟悉了，又要稍微熟悉下另外一种core了。

鉴于我司TB本来就要一些底层公用函数，C家core也有自己的底层库文件，又是一个事情。

嗯，忘了说，我司还有自己的makefile flow，makefile文件很多框架是定死的！事情变的更复杂起来。

 

这两天遇到了一个C链接的问题，链接时会报 undefined reference to的错误，

这种错误，以前见多了，一般就是会发现某个函数确实没有定义，加一下定义就可以了。

这次不一样，明明有定义，为什么还报告这个错误？

一开始也没有debug，一通操作把我司底层C的定义，include文件理一下。

再编译，还是有错误。。。无语了，遂google，找了两篇文件，把文件里面提到的可能原因都排除了，没有发现问题。

更无语了。。。

晚上睡觉也睡不好。

 

第二天，起床。google再战，有找到一篇知乎的文章，提到了nm文件，那就看看 symbol吧。C家这个编译也有类似的文件，xxx.map

查了下，确实没有symbol。奇怪，明明函数定义了呀。

回去看了下.c文件，等等。。。为什么有个define，这个define把这个函数定义mask掉了呀，瞬间，我卒。

 

不要问我为什么一开始没有发现，我司这样的底层C文件还是有不少的，你没法掌握所有的细节。

这个文件从另一个项目迁移过来，发现用最新的makefile flow的项目，这个文件里面这个define都去掉了。。。

有时候真是，历史包袱太重，真比从头开发更困难。

 

后面还发现一个重复定义的问题，是因为在一个.h文件里面，定义了一个变量。而这个.h文件被多个.c调用。

 

总结来说，就是C语言自我修养比较欠缺。

比如.h header文件，extern怎么用？这些都导致在解析过程中走了些弯路。

 

但仔细想想，总计debug的有效时间加起来也就4？5个小时，不能说非常长。但是和预期来说，长的离谱了，所以感觉上会非常糟糕。

标签：文件,定义,core,我司,makefile,编译,随想,调试
来源： https://www.cnblogs.com/damian-gong/p/16173490.html