编译连接.O文件变大

[zcm_xh2008]

由于工程很大，文件很多，无法具体描述，所以我就按照情形打个比方：在整改工程前有一个大的cpp文件A，在VXWORKS环境下编译连接出来的.O文件的大小是2M，现在整改工程后，大文件A里面的东西被拆分成若干个小的cpp文件，每个文件包含一个功能模块，并提供一个对外调用接口，供总的接口调用，现在在VX的环境下编译链接出来的.O文件总大小是3M，变大了1M，求教大神，会是什么原因？冗余不必要的代码已经清理干净了的。。。

[赵4老师]

VXWORKS环境下不知道有没有类似Windows的dumpbin.exe和Linux的objdump工具可以查看.obj或.o文件内部具体格式？ 提醒:.obj或.o文件们的总大小不重要，重要的是链接后生成的可执行映像的大小。

[ztenv]

我的理解：接口文件依赖过多的.h文件导致的，不过问题并不大，重要的是链接后可执行映像的大小； 不过可以试试减小的办法，不一定行，因为不熟悉VXworks：不要使用一个总的接口文件，拆分为几个，分别依赖

[zcm_xh2008]

引用 1 楼 zhao4zhong1 的回复:

VXWORKS环境下不知道有没有类似Windows的dumpbin.exe和Linux的objdump工具可以查看.obj或.o文件内部具体格式？ 提醒:.obj或.o文件们的总大小不重要，重要的是链接后生成的可执行映像的大小。

有，我比较了，整改后text段增加了1.4M的样子，data段减小了130KB左右，bss段基本没变

[zcm_xh2008]

引用 2 楼 lianshaohua 的回复:

我的理解：接口文件依赖过多的.h文件导致的，不过问题并不大，重要的是链接后可执行映像的大小； 不过可以试试减小的办法，不一定行，因为不熟悉VXworks：不要使用一个总的接口文件，拆分为几个，分别依赖

就是.O文件增大了导致可执行文件变大了一百多KB，要减小这一百多KB，.O上就要减小很多，现在减不下来，没找到根本原因。。。过多依赖头文件可能性不大，我试过的，没什么影响。。。

[zcm_xh2008]

引用 1 楼 zhao4zhong1 的回复:

VXWORKS环境下不知道有没有类似Windows的dumpbin.exe和Linux的objdump工具可以查看.obj或.o文件内部具体格式？ 提醒:.obj或.o文件们的总大小不重要，重要的是链接后生成的可执行映像的大小。

我有想过一个问题，打个比方哈：我之前的大文件A里面的所有功能全部写在一个函数fun里面，现在我整改后，把这些功能按照模块分别写在若干小文件里面，每个小文件里面都会增加4个左右的接口funX，不知道这样是不是会对.O大小影响很大？

[赵4老师]

如果最终你的代码和只读数据足够写到目标设备中的话，依我看你没必要纠结其大小。 反而你应该把主要精力放在代码执行效率、修改效率、发现bug的效率……等方面。

[ztenv]

引用 6 楼 zhao4zhong1 的回复:

如果最终你的代码和只读数据足够写到目标设备中的话，依我看你没必要纠结其大小。 反而你应该把主要精力放在代码执行效率、修改效率、发现bug的效率……等方面。

这个我同意。

[zcm_xh2008]

引用 6 楼 zhao4zhong1 的回复:

如果最终你的代码和只读数据足够写到目标设备中的话，依我看你没必要纠结其大小。 反而你应该把主要精力放在代码执行效率、修改效率、发现bug的效率……等方面。

现在因为变大了导致在设备上出现了问题，必须要纠结，没法

[zcm_xh2008]

引用 7 楼 lianshaohua 的回复:

[quote=引用 6 楼 zhao4zhong1 的回复:] 如果最终你的代码和只读数据足够写到目标设备中的话，依我看你没必要纠结其大小。 反而你应该把主要精力放在代码执行效率、修改效率、发现bug的效率……等方面。

这个我同意。[/quote] 不需要纠结的话我肯定不纠结，但是。。。功能出现问题了，因为这个东西变大了，在设备上跑出问题了。。。

[赵4老师]

引用 9 楼 zcm_xh2008 的回复:

[quote=引用 7 楼 lianshaohua 的回复:] [quote=引用 6 楼 zhao4zhong1 的回复:] 如果最终你的代码和只读数据足够写到目标设备中的话，依我看你没必要纠结其大小。 反而你应该把主要精力放在代码执行效率、修改效率、发现bug的效率……等方面。

这个我同意。[/quote] 不需要纠结的话我肯定不纠结，但是。。。功能出现问题了，因为这个东西变大了，在设备上跑出问题了。。。[/quote] 你这个结论下的太早，我猜。 在实际设备上想办法实现断点、单步或写日志功能才是在实际设备环境下调试的王道。

[赵4老师]

盲目重构代码也是码农之殇。 为什么要说“也”，是因为： 盲目升级是码农之殇。

[zcm_xh2008]

引用 10 楼 zhao4zhong1 的回复:

[quote=引用 9 楼 zcm_xh2008 的回复:] [quote=引用 7 楼 lianshaohua 的回复:] [quote=引用 6 楼 zhao4zhong1 的回复:] 如果最终你的代码和只读数据足够写到目标设备中的话，依我看你没必要纠结其大小。 反而你应该把主要精力放在代码执行效率、修改效率、发现bug的效率……等方面。

这个我同意。[/quote] 不需要纠结的话我肯定不纠结，但是。。。功能出现问题了，因为这个东西变大了，在设备上跑出问题了。。。[/quote] 你这个结论下的太早，我猜。 在实际设备上想办法实现断点、单步或写日志功能才是在实际设备环境下调试的王道。[/quote] http://bbs.csdn.net/topics/390768504

[梦想照旧实现]

能理解你的处境，嵌入式小设备上的内存flash有限，执行映像过大会出现问题。我之前遇到过直接在链接的时候提示代码段不够的情况。 这个应该与你重构函数有关，你可以做个简单的测试，在一个文件中将你的FuncX拆分成FuncX_1 ~ FuncX_n，如果修改后确实增大了，那么问题就清楚了。你也可以选择继续优化你的代码或者不做这样的重构。

引用 9 楼 zcm_xh2008 的回复:

[quote=引用 7 楼 lianshaohua 的回复:] [quote=引用 6 楼 zhao4zhong1 的回复:] 如果最终你的代码和只读数据足够写到目标设备中的话，依我看你没必要纠结其大小。 反而你应该把主要精力放在代码执行效率、修改效率、发现bug的效率……等方面。

这个我同意。[/quote] 不需要纠结的话我肯定不纠结，但是。。。功能出现问题了，因为这个东西变大了，在设备上跑出问题了。。。[/quote]

[zcm_xh2008]

引用 13 楼 swgshj 的回复:

能理解你的处境，嵌入式小设备上的内存flash有限，执行映像过大会出现问题。我之前遇到过直接在链接的时候提示代码段不够的情况。 这个应该与你重构函数有关，你可以做个简单的测试，在一个文件中将你的FuncX拆分成FuncX_1 ~ FuncX_n，如果修改后确实增大了，那么问题就清楚了。你也可以选择继续优化你的代码或者不做这样的重构。 [quote=引用 9 楼 zcm_xh2008 的回复:] [quote=引用 7 楼 lianshaohua 的回复:] [quote=引用 6 楼 zhao4zhong1 的回复:] 如果最终你的代码和只读数据足够写到目标设备中的话，依我看你没必要纠结其大小。 反而你应该把主要精力放在代码执行效率、修改效率、发现bug的效率……等方面。

这个我同意。[/quote] 不需要纠结的话我肯定不纠结，但是。。。功能出现问题了，因为这个东西变大了，在设备上跑出问题了。。。[/quote][/quote] http://bbs.csdn.net/topics/390768504 大神，我重新提了个问题，在这，帮忙解释解释呗。。。