GD32F130FXP6学习笔记十一：KEIL MDK输出map文件分析

分手后的思念是犯贱 2022-06-16 03:30 421阅读 0赞

出处：[http://kmoving.blog.163.com/blog/static/20504919720129241952437/][http_kmoving.blog.163.com_blog_static_20504919720129241952437]

一、文件分析流程

1、第一部分：Section Cross References

主要是各个源文件生成的模块之间相互引用的关系。

stm32f10x.o(STACK) refers (Special) to stkheap2.o(.text) for \_\_use\_two\_region\_memory

比如上面这句话，stm32f10x.o是stm32f10x.s生成的目标文件模块，(STACK)是文件内定义

的一个段，链接器把它视为一个Section，输入节。它引用了模块stkheap2.o输入节(.text)里

面的一个全局符号\_\_use\_two\_region\_memory（可能是一个函数或变量）。这个(Special)

不知道是什么含义。剩下的基本都是这用的意思。

stm32f10x\_vector.o(.text) refers to \_\_main.o(!!!main) for \_\_main

\_\_main.o(!!!main) refers to kernel.o(.text) for \_\_rt\_entry

kernel.o(.text) refers to usertask.o(.text) for main

上面这几个对于程序意义比较重大用户在启动代码中调用了\_\_main.o模块中的\_\_main函数，

\_\_main又调用了kernel.o中的\_\_rt\_entry函数，最后kernel.o又调用了用户定义的main主函数。

2、第二部分：Removing Unused input sections from the image.

就是将库中没有用到的函数从可执行映像中删除掉，减小程序的体积。

Removing os\_mbox.o(.text), (1094 bytes).

Removing os\_mutex.o(.text), (1744 bytes).

Removing os\_sem.o(.text), (1016 bytes).

3、第三部分：Image Symbol Table

Local Symbols

符号表里的局部符号。

../../angel/boardlib.s 0x00000000 Number 0 boardinit1.o ABSOLUTE

../../angel/handlers.s 0x00000000 Number 0 \_\_scatter\_copy.o ABSOLUTE

../../angel/kernel.s 0x00000000 Number 0 kernel.o ABSOLUTE

../../angel/rt.s 0x00000000 Number 0 rt\_raise.o ABSOLUTE

../../angel/scatter.s 0x00000000 Number 0 \_\_scatter.o ABSOLUTE

../../angel/startup.s 0x00000000 Number 0 \_\_main.o ABSOLUTE

../../angel/sys.s 0x00000000 Number 0 sys\_exit.o ABSOLUTE

../../angel/sysapp.c 0x00000000 Number 0 sys\_wrch.o ABSOLUTE

../../armsys.c 0x00000000 Number 0 \_get\_argv.o ABSOLUTE

../../division\_7m.s 0x00000000 Number 0 rtudiv10.o ABSOLUTE

../../fpinit.s 0x00000000 Number 0 fpinit.o ABSOLUTE

../../heapalloc.c 0x00000000 Number 0 hrguard.o ABSOLUTE

../../printf.c 0x00000000 Number 0 \_printf\_outstr\_char.o ABSOLUTE

../../signal.c 0x00000000 Number 0 defsig\_exit.o ABSOLUTE

../../stdlib.c 0x00000000 Number 0 exit.o ABSOLUTE

../../stkheap.s 0x00000000 Number 0 heapext.o ABSOLUTE

以上是一些系统内部的局部符号，还有用户的一些局部符号

4、第四部分：Global Symbols

全局符号

\_terminate\_user\_alloc - Undefined Weak Reference

\_terminateio - Undefined Weak Reference

\_\_Vectors 0x08000000 Data 4 stm32f10x\_vector.o(RESET)

\_\_main 0x08000131 Thumb Code 8 \_\_main.o(!!!main)

\_\_scatterload 0x08000139 Thumb Code 0 \_\_scatter.o(!!!scatter)

\_\_scatterload\_rt2 0x08000139 Thumb Code 44 \_\_scatter.o(!!!scatter)

这些是一些系统的全局符号

Font8x16 0x08001a82 Data 2048 tft018.o(.constdata)

Font8x8 0x08002282 Data 2056 tft018.o(.constdata)

codeGB\_16 0x08002a8a Data 770 tft018.o(.constdata)

Region$$Table$$Base 0x08002dc0 Number 0 anon$$obj.o(Region$$Table)

Region$$Table$$Limit 0x08002de0 Number 0 anon$$obj.o(Region$$Table)

后面这两个符号我认为很重要，在运行库代码将可执行映像从加载视图转变为可执行

视图的过程中起到了关键作用。Number是指它并不占据程序空间，而只是一个具有一

定数值的符号，类似于程序中用define和EQU定义的。所以这里，我先放下map文件的

分析，先通过仿真调试，看这两个数值在程序中怎么用。

![20170504103558843][]

果然，在刚开始执行程序时，R10和R11的值就已经被赋值成了这两个值。

![20170504103604094][]

很快就将0x08002dc0到0x08002dcf处的16个字节，4个双字加载到了R0-R3，我们可以分析

一下里面的内容，R0就是程序加载视图的RW区的起始地址（0x08002de0），R1就是要输出

的执行视图的RW区的地址（0x20000000），R2就是要复制的RW数据的个数，R3是复制函

数 （ \_\_scatterload\_copy)的地址，类似于一个回调函数。接下来就要用了：

0x0800011E 4718 BX r3这条指令去执行复制工作。

![20170504103608515][]

接下来又将0x08002dd0到0x08002ddf处的16个字节，4个双字加载到了R0-R3，我们可以分

析一下里面的内容，R0就是程序加载视图的RW区的起始地址（0x08002de0+0x20=0x08002e00）

，R1就是要输出的执行视图的RW区的地址（0x20000020），R2就是要复制的RW数据的个数，

R3是ZI区域建立函数（ \_\_scatterload\_zeroinit )的地址。

执行完成后，程序就会进入BL.W \_\_rt\_entry处进行库的初始化工作。

经过这么一分析，现在我对于程序的加载映像和执行映像有了较深的理解：程序的RO\_Code

加上RO\_Data总共是0x2dc0这么大，地址范围0x0800,0000到0x8000,2dbf。然后在0x0800,

2dc0-2dcf共16个字节放了RW加载映像地址（0x0800,2de0）、执行映像地址(0x2000,0000)、

RW长度(0x20)和将该段数据从加载映像复制到执行映像的函数地址。在0x0800,2dd0-2ddf共

16个字节放了ZI加载映像地址（0x0800,2e00）、执行映像地址(0x2000,0020)、ZI长度(0x480)

和建立ZI、HEAP和STACK执行映像的函数地址。

在上面的第二个阶段，将ZI清零阶段，程序的ZI长度实际上只有0x20，而库代码留出了0x60

的长度。因此数据区的顶端为0x2000,00a0-1。接下来从0x2000,00a0开始为堆的起始地址，

堆长度加上程序栈长度为0x2000,04a0，这就是堆栈顶端，也是\_\_initial\_SP的初始值。

程序进入\_rt\_entry后，还要对heapstack进行处理，但我没有看到有什么用的变化。从中对库

留出的ZI数据区进行了一些处理，我暂时也看不明白。好了，调试就到这里，回到map文件分

析的正途。

5、第五部分：

Memory Map of the image

//映像的内存分布

Image Entry point : 0x080000ed

//程序的入口点：这里应该是RESET\_Handler的地址

Load Region LR\_IROM1 (Base: 0x08000000, Size: 0x00002e00, Max: 0x00020000, ABSOLUTE)

//程序的加载映像地址和长度，2e00=2dc0（代码和常数）+0x20（Region Table是RW的

加载和执行地址、ZI与HEAPSTACK的执行地址）+0x20（已经初始化的数据）。

Execution Region ER\_IROM1 (Base: 0x08000000, Size: 0x00002de0, Max: 0x00020000,

ABSOLUTE) //这段RO区域的加载映像和执行映像一致。

Base Addr Size Type Attr Idx E Section Name Object

0x08000000 0x000000ec Data RO 3 RESET stm32f10x.o

0x080000ec 0x00000008 Code RO 191 \* !!!main \_\_main.o(c\_w.l)

Execution Region RW\_IRAM1 (Base: 0x20000000, Size: 0x000004a0, Max: 0x00005000,

ABSOLUTE) //RW数据区 ZI数据区 Heap和Stack数据区。

Base Addr Size Type Attr Idx E Section Name Object

0x20000000 0x00000001 Data RW 100 .data tft018.o

x20000040 0x00000060 Zero RW 212 .bss libspace.o(c\_w.l)

0x200000a0 0x00000000 Zero RW 2 HEAP stm32f10x.o

0x200000a0 0x00000400 Zero RW 1 STACK stm32f10x.o

6、第六部分：Image component sizes

这是指出各个模块的输入节的大小

Code (inc. data) RO Data RW Data ZI Data Debug Object Name

972 58 0 10 32 2416 can.o

824 168 0 15 0 1791 candemo.o

928 88 0 0 0 4529 stm32\_init.o

52 18 236 0 1024 2700 stm32f10x.o

1836 32 4874 1 0 8076 tft018.o

最后给出总长度：这个11744应该=0x2dc0，1184应该0x4a0。11776应该是=0x2e00。

Total RO Size (Code + RO Data) 11744 ( 11.47kB)

Total RW Size (RW Data + ZI Data) 1184 ( 1.16kB)

Total ROM Size (Code + RO Data + RW Data) 11776 ( 11.50kB)

二、总结

感觉经过这么分析一遍，对于嵌入式系统程序的静态结构和动态执行流程的了解又深入了一些，

当然也还是有些问题并没有了解透彻：留待以后慢慢解决吧。

[http_kmoving.blog.163.com_blog_static_20504919720129241952437]: http://kmoving.blog.163.com/blog/static/20504919720129241952437/
[20170504103558843]: /images/20220616/cc093d4d1fb4450392ab8b223007eddb.png
[20170504103604094]: /images/20220616/54988f9aeb564939919c3f41f6f2d51e.png
[20170504103608515]: /images/20220616/57c923225cd647c7b87c6f58989ab905.png