STM32F gcc编译后续

后话之定制链接分散文件

在通常应用中，需要将程序的Flash空间进行自定义的划分，如下图所示。

为此，在gcc的链接文件*.ld文件中根据上图来进行编写。
MEMORY
{
  FLASH (rx)      : ORIGIN = 0x08000000, LENGTH = 64K
  RAM (xrw)       : ORIGIN = 0x20000000, LENGTH = 8K
}
 
/* Define output sections */
SECTIONS
{
/* 第一段中断向量区 */
  .vector :               
  {
    . =ALIGN(4);
   KEEP(*(.isr_vector)) /* Startup code */
    . =ALIGN(4);
   *_start_gcc.o(.text*)
  } >FLASH
 
/* 应用程序1空间 */
.app1 0x08001000 :
  {
    . = ALIGN(4);
    app1.o(.text*)
    . = ALIGN(4);
  } >FLASH
 
/* 应用程序2空间 */
  .app2 0x08002000 :
  {
    . = ALIGN(4);
    app2.o(.text*)
    . = ALIGN(4);
  } >FLASH
 
/* 其他应用程序空间，下面并不是完整的链接文件，其中还有数据段，bss段堆栈段等没有列出 */
 .text 0x08003000:
  {
    . = ALIGN(4);
    *(.text.startup.main)
    *(.text)           /* .text sections (code) */
 
    . = ALIGN(4);
    _etext = .;        /* define a global symbols at end ofcode */
  } >FLASH
 
在编写好上面文件，进行重新链接的时候，提示错误信息如下：
c:/programfiles/gnu tools arm embedded/4.7 2013q1/bin/../lib/gcc/arm-none-eabi/4.7.3/../../../../arm-none-eabi/bin/ld.exe:cannot find app1.o
collect2.exe: error: ld returned 1 exitstatus
找不到app1.o，于是将app1.o包含暂时屏蔽处理，然后从*.map文件中可以找到如下字段
LOAD app1.o
这个时候有点犯迷糊了，怎么明明都正确装载了，却找不到呢?
经过多番试验，仍然不然找到问题原因。那么在map文件里肯定可以找到app1.o对应的函数定义信息，不看不知道，问题原因竟在这里
.text.app1_test1
               0x08002e74       0x24d:\Tmp\ccKPCaS8.ltrans1.ltrans.o
.text.app1_test2
               0x08002f74       0x24d:\Tmp\ccKPCaS8.ltrans1.ltrans.o
原来在链接的时候，链接器都从*.ltrans.o文件中来获得，这到底是什么原因呢，后来经过仔细对比Make的编译选项，发现有一个编译选项是–flto，它的目的是用于提高链接速度的，刚开始在试验的时候有怀疑过这个选项，但是它的作用是提高链接速度，所以当初并没有更加深入去分析这个选项。原文如下：
-flto
This option runs the standard link-time optimizer. When invoked withsource
code, it generates GIMPLE (one of GCC’s internal representations)and writes
it to special ELF sections in the object file. When the object filesare linked
together, all the function bodies are read from these ELF sectionsand instan-tiated as if they had been part of the same translation unit.
于是在链接选项中将 –flto去掉，结果编译和验证顺利通过。