arm编译后的bss区
① ARM中.c文件和.h文件有什么区别
其实要理解C文件与头文件有什么不同之处，首先需要弄明白编译器的工作过程，一般说来编译器会做以下几个过程：
1.预处理阶段
2.词法与语法分析阶段
3.编译阶段，首先编译成纯汇编语句，再将之汇编成跟CPU相关的二进制码，生成各个目标文件
4.连接阶段，将各个目标文件中的各段代码进行绝对地址定位，生成跟特定平台相关的可执行文件，当然，最后还可以用obj生成纯二进制码，也就是去掉了文件格式信息
编译器在编译时是以C文件为单位进行的，也就是说如果你的项目中一个C文件都没有，那么你的项目将无法编译，连接器是以目标文件为单位，它将一个或多个目标文件进行函数与变量的重定位，生成最终的可执行文件，在PC上的程序开发，一般都有一个main函数，这是各个编译器的约定，当然，你如果自己写连接器脚本的话，可以不用main函数作为程序入口！！！！
有了这些基础知识，再言归正传，为了生成一个最终的可执行文件，就需要一些目标文件，也就是需要C文件，而这些C文件中又需要一个main函数作为可执行程序的入口，那么我们就从一个C文件入手，假定这个C文件内容如下：
#include <stdio.h>
#include "mytest.h "
int main(int argc,char **argv)
{
test = 25;
printf( "test.................%d\n ",test);
}
头文件内容如下：
int test;
现在以这个例子来讲解编译器的工作：
1.预处理阶段：编译器以C文件作为一个单元，首先读这个C文件，发现第一句与第二句是包含一个头文件，就会在所有搜索路径中寻找这两个文件，找到之后，就会将相应头文件中再去处理宏，变量，函数声明，嵌套的头文件包含等，检测依赖关系，进行宏替换，看是否有重复定义与声明的情况发生，最后将那些文件中所有的东东全部扫描进这个当前的C文件中，形成一个中间“C文件”
2.编译阶段，在上一步中相当于将那个头文件中的test变量扫描进了一个中间C文件，那么test变量就变成了这个文件中的一个全局变量，此时就将所有这个中间C文件的所有变量，函数分配空间，将各个函数编译成二进制码，按照特定目标文件格式生成目标文件，在这种格式的目标文件中进行各个全局变量，函数的符号描述，将这些二进制码按照一定的标准组织成一个目标文件
3.连接阶段，将上一步成生的各个目标文件，根据一些参数，连接生成最终的可执行文件，主要的工作就是重定位各个目标文件的函数，变量等，相当于将个目标文件中的二进制码按一定的规范合到一个文件中
再回到C文件与头文件各写什么内容的话题上：
理论上来说C文件与头文件里的内容，只要是C语言所支持的，无论写什么都可以的，比如你在头文件中写函数体，只要在任何一个C文件包含此头文件就可以将这个函数编译成目标文件的一部分（编译是以C文件为单位的，如果不在任何C文件中包含此头文件的话，这段代码就形同虚设），你可以在C文件中进行函数声明，变量声明，结构体声明，这也不成问题！！！那为何一定要分成头文件与C文件呢？又为何一般都在头件中进行函数，变量声明，宏声明，结构体声明呢？而在C文件中去进行变量定义，函数实现呢？？原因如下：
1.如果在头文件中实现一个函数体，那么如果在多个C文件中引用它，而且又同时编译多个C文件，将其生成的目标文件连接成一个可执行文件，在每个引用此头文件的C文件所生成的目标文件中，都有一份这个函数的代码，如果这段函数又没有定义成局部函数，那么在连接时，就会发现多个相同的函数，就会报错
2.如果在头文件中定义全局变量，并且将此全局变量赋初值，那么在多个引用此头文件的C文件中同样存在相同变量名的拷贝，关键是此变量被赋了初值，所以编译器就会将此变量放入DATA段，最终在连接阶段，会在DATA段中存在多个相同的变量，它无法将这些变量统一成一个变量，也就是仅为此变量分配一个空间，而不是多份空间，假定这个变量在头文件没有赋初值，编译器就会将之放入BSS段，连接器会对BSS段的多个同名变量仅分配一个存储空间
3.如果在C文件中声明宏，结构体，函数等，那么我要在另一个C文件中引用相应的宏，结构体，就必须再做一次重复的工作，如果我改了一个C文件中的一个声明，那么又忘了改其它C文件中的声明，这不就出了大问题了，程序的逻辑就变成了你不可想象的了，如果把这些公共的东东放在一个头文件中，想用它的C文件就只需要引用一个就OK了！！！这样岂不方便，要改某个声明的时候，只需要动一下头文件就行了
4.在头文件中声明结构体，函数等，当你需要将你的代码封装成一个库，让别人来用你的代码，你又不想公布源码，那么人家如何利用你的库呢？也就是如何利用你的库中的各个函数呢？？一种方法是公布源码，别人想怎么用就怎么用，另一种是提供头文件，别人从头文件中看你的函数原型，这样人家才知道如何调用你写的函数，就如同你调用printf函数一样，里面的参数是怎样的？？你是怎么知道的？？还不是看人家的头文件中的相关声明啊！！！当然这些东东都成了C标准，就算不看人家的头文件，你一样可以知道怎么使用
② 请问arm-linux-gcc和arm-linux-ld还有arm-linux-obj之间是什么关系
arm-linux-ld 是连接器，它把一些目标和归档文件结合在一起，重定位数据，并连接符号引用。通常，建立一个新编译程序的最后一步就是调用ld。
arm-linux-gcc -wall -O2 -c -o $@ $<
-o 只激活预处理,编译,和汇编,也就是他只把程序做成obj文件
-Wall 指定产生全部的警告信息
-O2 编译器对程序提供的编译优化选项，在编译的时候使用该选项，可以使生成的执行文件的执行效率提高
-c 表示只要求编译器进行编译，而不要进行链接，生成以源文件的文件名命名但把其后缀由 .c 或 .cc 变成 .o 的目标文件
-S 只激活预处理和编译，就是指把文件编译成为汇编代码
arm-linux-ld 直接指定代码段,数据段,BSS段的起始地址
-Tbss ADDRESS Set address of .bss section
-Tdata ADDRESS Set address of .data section
-Ttext ADDRESS Set address of .text section
示例:
${CROSS}ld -Ttext=0x33000000 led.o -o led.elf
使用连接脚本设置地址:
arm-linux-ld -Tbeep.lds start.o beep.o -o beep.elf
其中beep.lds 为连接脚本如下：
arm-linux-obj被用来复制一个目标文件的内容到另一个文件中,可用于不同源文件的之间的格式转换
示例:
arm-linux-obj –o binary –S elf_file bin_file
常用的选项:
input-file , outflie
输入和输出文件,如果没有outfile,则输出文件名为输入文件名
2.-l bfdname或—input-target=bfdname
用来指明源文件的格式,bfdname是BFD库中描述的标准格式名,如果没指明,则arm-linux-obj自己分析
3.-O bfdname 输出的格式
4.-F bfdname 同时指明源文件,目的文件的格式
5.-R sectionname 从输出文件中删除掉所有名为sectionname的段
6.-S 不从源文件中复制重定位信息和符号信息到目标文件中
7.-g 不从源文件中复制调试符号到目标文件中
arm-linux-objmp
查看目标文件（.o文件）和库文件(.a文件）信息
arm-linux-objmp -D -m arm beep.elf > beep.dis
-D 显示文件中所有汇编信息
-m machine
指定反汇编目标文件时使用的架构，当待反汇编文件本身没有描述架构信息的时候(比如S-records)，这个选项很有用。可以用-i选项列出这里能够指定的架构.
[guowenxue@localhost asm_c_buzzer]$ cat beep.lds
/***********************************************************************
* File: beep.lds
* Version: 1.0.0
* Copyright: 2011 (c) Guo Wenxue <[email protected]>
* Description: Cross tool link text, refer to u-boot.lds
* ChangeLog: 1, Release initial version on "Mon Mar 21 21:09:52 CST 2011"
*
**********************************************************************/
OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm")
OUTPUT_ARCH(arm)
ENTRY(_start)
SECTIONS{
. = 0x33000000;
.text : {
*(.text)
*(.rodata)
}
.data ALIGN(4): {
*(.data)
}
.bss ALIGN(4): {
*(.bss)
}
}
[guowenxue@localhost asm_c_buzzer]$ cat makefile
# ***********************************************************************
# * File: makefile
# * Version: 1.0.0
# * Copyright: 2011 (c) Guo Wenxue <[email protected]>
# * Description: Makefile used to cross compile the ASM and C source code
# * ChangeLog: 1, Release initial version on "Mon Mar 21 21:09:52 CST 2011"
# *
# ***********************************************************************
CROSS = /opt/buildroot-2011.02/arm920t/usr/bin/arm-linux-
CFLAGS =
beep.bin: start.S beep.c
arm-linux-gcc $(CFLAGS) -c -o start.o start.S
arm-linux-gcc $(CFLAGS) -c -o beep.o beep.c
arm-linux-ld -Tbeep.lds start.o beep.o -o beep.elf
arm-linux-obj -O binary -S beep.elf beep.bin
rm -f *.elf *.o
install:
cp beep.bin ~/winxp -f --reply=yes
clean:
rm -f *.elf *.o
rm -f beep.bin
③ C语言代码组成 - BSS、Data、Stack、Heap、Code、Const
一段C语言经过编译连接后，成为一段可以运行的代码，可运行的代码可以分为以下四个部分组成：全局变量/静态变量区、堆、栈、代码区。其中全局变量/静态变量区又分为未初始化变量区和初始化变量区，代码区又分为代码和常量区。即汇总下来，代码可以分为6部分组成，包括：BSS区（未初始化的全局变量/静态变量区）、Data区（实始化的全局变量区）、Stack区（栈区）、heap区（堆区）、Code区（代码区）、const区（常量区）。
一、BSS区和Data区
C语言编程中定义的全局变量、静态局部变量，就是分配在全局变量/静态变量区域，但是为什么又要分为BSS区域和Data区域呢？其实我们在定义全局或者静态变量区，有时我会对它赋初始值，有的又不会赋初始化，比如我们定义的全局变量，初始化的赋值，是怎么样写到变量区域中的，我们定义的静态局部变量，在定义时初始化后，为什么后面函数被调用，又不会再初始化呢？这个局部静态变量是怎么样实始化的，什么时候初始化的？
如果分析编译后的汇编代码，就会发现在代码运行起来后，会有一段给变量赋值的指令，这一段代码，不是我们C代码对应的汇编，而是C编译器生成的汇编译代码，这段代码的作用就是给初始化了的静态变量和全局变量进行初始化。这也是为什么全局/静态变量区域，要分BSS和Data的原因。
二、Stack区
栈是一种先进后出的数据结构，这种数据结构正好完美的匹配函数调用时的模型过程，比如函数f(a)在运行过程中调用函数f(b)，f(a）在运行过程中的变量就是分配在栈中，通过在调用f(b)前，会将代码中用到的R0~Rn寄存器的值保存到栈中，同时将函数的传入参数写入到栈中，然后进入f(b)函数，函数f(b)的变量b分配在栈中，当函数运行完毕后，释放变量b，将栈中存放的f（a）函数的运行的R0~Rn寄存器值恢复到寄存器中，同时f(b)的返回结果存入到栈中，这样f（a）继续运行。当一个函数运行完毕后，它在栈中分配的临时变量会全部释放。
对于中断也是一样的，中断发生时，也是一个函数打断了另一个函数的运行，这种现场的保存（即寄存器的值）,都是通过栈来完成的。所以栈的作用有：
三、Heap区
全局变量分配的内存在代码整个运行周期内都是有效的，而在栈区分配的内存在函数调用完成后，就会释放。这两种内存模型都是由编译器决定它的使用，代码是无法控制的。那有没有内存是由用户控制的，要用时，就自由分配，不用时，就自行释放？答案是肯定的，这部分内存就是堆。
用户需要使用的动态内存，就是通过malloc函数，调用分配的，在没有释放前，可一直由代码使用。当这部分内存不再需要使用时，可以通过free函数进行释放，将它归还到堆中。从这中可以看出，堆的内存，是按需分配的。这就是赋予了代码很大的自由度，但这也是会带来负作用的，比如：内存碎片化导致的malloc失败；忘记释放内存导致的内存泄露，而这些往往是致命的失误。
四、Code区
代码区就是编译后机器指令，这些指令决定了功能的执行。我们编译的代码一般是下载进flash中，但是运行，却有两种方式：在RAM中运行和在ROM中运行。 在RAM中运行，即是boot启动后，将flash中的代码复制到RAM中，然后PC指针在指到RAM中的代码中开始运行。 有时在调试时，我们可以直接将代码下载进RAM中运行进行调试，这样加快调试速度。便是大部分的情况我们的代码是从flash中开始运行的。
五、常量区
代码中的常量，一部分是作为立即数，在代码区中，但是像定义的字符串、给某数组赋值的一串数值，这些常量，就存在常量区，我们常用const来定义一个常量，即该变量不能再必变。这部分的变量，编译器一般将它定义的flash中。
六、各个区域大小的是如何决定的：
code区和const区：是由代码的大小和代码中常量的多少来决定的。
bss区和data区：这是由代码中定义的全局变量和局部变量的多少来决定的。
stack区：这个可以由使用都自行定义大小，但使用都要根据自已代码的情况，评估出一个合理的值，再定义其大小，如果定义的太小，很容易爆栈，导至代码异常，但是如果定义的太大，就容易浪费内存。
heap区：RAM剩下的部分，编译器就会作为堆区使用。
七、嵌入式代码一般启动过程
以STM32为例，通过分析其汇编启支代码，大致可以分为以下几个步骤：
如果大家想看编译扣，代码文件的组成，可以查看统后生的map文件，里面有详细的数据，包括各个函数的分配内存，BSS，Data，Stack，Heap，Text的分配情况。
如果相要了解详细的代码启动过程，可看它的启动汇编文件。
④ arm瀛︿範锛歶boot镓ц岀涓阒舵典负浠涔堜笉绉诲姩bss娈靛埌SDRAM
bss娈甸噷闱㈠瓨鏀剧殑鏄镞犲埯濮嫔肩殑鍏ㄥ眬鍙橀噺銆佸埯濮嫔间负0镄勫彉閲忋
涔熷氨鏄钖庨溃瑕佸埯濮嫔寲镄勫彉閲忥纴镓浠uboot镄勭涓阒舵典笉绉诲姩bss娈点
鍙闇瑕佺煡阆揵ss娈电殑鍦板潃銆佸ぇ灏忓氨鍙浠ヤ简锛埚洜涓哄唴瀹规槸宸茬煡镄勨斺0锛夈
⑤ arm姹囩紪涓镄%鏄浠涔堜綔鐢锛
IDA镄勮剧疆涓嶅癸纴濡傛灉璁剧疆镄勫瑰氨杞鎹㈡垚浠ｇ爜浜嗐
鐢↖DA鍙嶆眹缂栧緢瀹规槗钖э纴浣犳庝箞鍙嶅嚭𨱒ユ槸杩欎簺涓滆タ銆
铏界劧鍙嶅嚭𨱒ュ规槗锛屽垎鏋愯捣𨱒ュ氨涓嶉偅涔埚规槗浜嗐
⑥ arm-linux-gcc 编译后，在开发板上没法运行
你是不是说反了？或者是说你的环境变量已经有arm-linux-gcc了，而你又用了另一个交叉编译版本，所以导致不能运行？