程序本身如何知道自身大小？这是鸡生蛋还是蛋生鸡的问题

来源：公众号【鱼鹰谈单片机】

作者：鱼鹰Osprey

ID   ：emOsprey

有些情况下，我们可能需要知道程序本身占用的空间大小，一般来说，我们可以从编译结果中看到我们的程序到底有多大（不包含 ZI-data 部分）：

还可以通过生成的bin文件大小来查看，这个 bin 文件就是不需要经过任何转化直接烧录到 flash 的数据，当然它也不包含 ZI-data，因为它初始化全是 0，只需要在程序开始时清零即可（该工作由库函数自动帮你完成），没必要保存到 flash中浪费空间。

Bin 文件生成方法（fromelf --bin !L --output hello.bin）：

我们可以看一看这些数据的空间分布：

一般来说，const 声明的函数将放在 RO-data 区。全局（或局部静态）未进行初始化（或初始化为0）的变量放在 ZI-data 区，当然栈（stack）也会放在 ZI-data。

MDK的编译器为我们提供了一些内置变量，这些变量是由编译链接之后自动生成的，我们可以直接在程序中获取，那么有哪些变量，又该如何获取呢？

据鱼鹰了解，MDK 内置了如下变量（有些变量在有些情况下表示相同值）:

Image$$ER_IROM1$$Base;
Image$$ER_IROM1$$Limit;
Image$$ER_IROM1$$Length;   // 获取总大小


Load$$LR$$LR_IROM1$$Limit; // 这个和上面的效果一样


Image$$ER_IROM1$$RO$$Limit;  // 这个和上面的效果一样


Image$$RW_IRAM1$$Base;
Image$$RW_IRAM1$$Limit;
Image$$RW_IRAM1$$Length;


Image$$RW_IRAM1$$ZI$$Base;
Image$$RW_IRAM1$$ZI$$Limit;
Image$$RW_IRAM1$$ZI$$Length;

Image$$ER_IROM1$$Length 对应于 Code + RO Data 的大小，而 base 和 limit 为这段空间的起始和结束地址。

Image$$RW_IRAM1$$Length 对应于 RW-Data 的大小，而 base 和 limit 为这段空间的起始和结束地址。

Image$$RW_IRAM1$$ZI$$Length 对应于 ZI-Data（包括STACK） 的大小，而 base 和 limit 为这段空间的起始和结束地址。

那么我们该如何使用这些变量呢？下面鱼鹰提供C语言和汇编两个版本：

// C语言
extern int Image$$ER_IROM1$$Base;


unsigned int base = (uint32_t)&Image$$ER_IROM1$$Base


; 汇编  
IMPORT |Image$$ER_IROM1$$RO$$Base|
IMPORT |Image$$ER_IROM1$$RO$$Limit|


IMPORT |Image$$RW_IRAM1$$RW$$Base|
IMPORT |Image$$RW_IRAM1$$RW$$Limit|


IMPORT |Image$$RW_IRAM1$$ZI$$Base|
IMPORT |Image$$RW_IRAM1$$ZI$$Limit|

首先使用 extern 关键声明这个外部变量，int 类型。

但是你通过它的使用方式你会发现，这个变量是不可以直接使用的，需要把对它进行取地址，而它的地址才是你想要的数据。

事实上，这些内置变量本身是不占用空间的的，和用户声明的变量是不同的。

我们可以这样理解，这些变量存放在某个地址空间，这个地址就是它要表示的值（含义），但因为它的特殊性，所以它不占用空间，只能采用取地址的方式获取它代表的值。

通过这些内置变量，原本我们计算 Code + RO-data + RW-Data 的值就可以得到 bin 文件的大小，但当你查看 bin 文件大小之后，你会发现 bin 文件小于该值，这是怎么回事？

通过分析 map 文件我们可以看到如下信息：

你会发现，实际的bin文件包含的 RW 数据大小并不是 372，而是 56，也就是说，有一部分数据并没有被包含进 bin 文件用于拷贝（可能和 RW 的数据有部分初始值为 0 有关而被压缩了）。

具体原因，鱼鹰也没搞懂，但是按照之前的变量来看，我们无法准确获得 bin 文件的大小，只能说获取到一个比 bin 文件大小稍大的数字。

原本以为鱼鹰不可能获得准确的 bin 文件大小了，一个偶然的map文件查看，让鱼鹰看到了这么个变量：

好奇的鱼鹰对它进行了比较深入的研究，发现我需要的bin文件（程序）大小就隐藏在这里。

通过分析，鱼鹰发现这个地址包含的8个数据含义如下：

通过图中数据，减去flash 的基地址，我们就可以获取到 0x2FE8，即我们 bin 文件实际大小。

而另外两个函数地址，原本鱼鹰并不知道这些值是干什么用的，还是通过分析 map 文件，才最终确认是两个函数的地址，至于到底干什么用的，鱼鹰就不是很清楚的，不过看名字也知道应该和变量初始化有关系。

以上就是鱼鹰分享的关于程序本身获取自身大小的知识点，至于你用这些数据干啥用那就是你的事情了。

原本鱼鹰是准备获取到bin的大小后通过指定地址的方式在bin文件最后放一些数据的，但是这就真的变成鸡生蛋蛋生鸡的问题了，看来通过内置变量的方式是不行了，不知道各位道友有没有好的方法让编译器自动在 bin 文件的后面添加想要的数据呢（非第三方工具）？

推荐阅读：

嵌入式系统优先级详解

KEIL 调试经验总结

线程CPU使用率到底该如何计算？

许久以后，你会感谢自己写的异常处理代码

终极串口接收方式，极致效率

延时功能进化论(合集)

如何写一个健壮且高效的串口接收程序？

打了多年的单片机调试断点到底应该怎么设置？| 颠覆认知

-THE END-

---

如果对你有帮助，记得转发分享哦

微信公众号「鱼鹰谈单片机」

每周一更单片机知识

长按后前往图中包含的公众号关注

鱼鹰，一个被嵌入式耽误的畅销书作家

个人微信「EmbeddedOsprey」

长按后打开对方的名片关注