GNU GCC Manual & Make Manual （烦请进来讨论一下，谢哈。。。）

crazydtone

GNU GCC 是一个编译器集合，那它应该有一些它自己的一些标准（关键字...），比如像keil、ICCAVR之类的编译软件 ！（总是感觉心里不是很踏实）

我是直接在Linux上使用 arm-linux-gcc 编译器Make生成可执行文件，烧到开发板上面的（现在是裸奔的），这样做的（请见谅）童鞋们可否给小弟点建议。。。 谢谢！

上传几个文档希望能给大家带来帮助。。。

文档下载地址：http://www.gnu.org/software/software.html.en

Cliff

一、什么是“自己的一些标准”，不已经有C89、C99了么？如果要说“自己的标准”，那么 __attribute__ 系列不知是不是你想要的东西
二、裸奔要 arm-none-eabi-gcc，好些年前是 arm-elf-gcc。然后也不是 libc，而是 newlib。
三、生成可执行文件，与gcc有关，与binutils有关，与make无关。

crazydtone

Cliff 发表于 2014-1-3 21:54
一、什么是“自己的一些标准”，不已经有C89、C99了么？如果要说“自己的标准”，那么 __attribute__ 系列 ...

赞成。。。

编译时不是使用 arm-none-linux-gnueabi-gcc  
连接 arm-none-linux-gnueabi-ld

生成的映像文件确实和Make没有多大的关系，它只是为了方便编译而已！

我这里有个问题，如下：

*.c/*.S文件经过预处理、编译、汇编（未连接生成*.bin文件）之后会生成一个*.o文件 。这个*.o文件中有几个section ： .text/.data/.bss/.rodata 还有系统附加的section。当我定义一个全局变量（被初始化的）时，它本应该放在.data section 中，但是它没有放在其中！ 当我使用了关键字 __attribute__ 定义变量之后 （unsigned char __attribute__((section(".data")))_iicData[IICBUFSIZE]={0};），该变量才被放在.data section中！目前情况是这样的，被初始化的全局变量被放在 .bss section中！之前我在调定时器时定义了一个全局变量，但是它在中断中不自增，当使用 __attribute__关键字将变量定义在.data section 中就可以自增了。 不知道你们有没有遇到过，这是由什么而造成的，很疑惑......

Cliff

需要被初始化成0的，特别是数组，就是放在bss的呀。
关于自增什么的，你有没有用volatile？

crazydtone

Cliff 发表于 2014-1-4 10:33
需要被初始化成0的，特别是数组，就是放在bss的呀。
关于自增什么的，你有没有用volatile？ ...

谢谢。。。

.text : code
.data : initialized data
.bss  : unintialized data

那些全局变量都是  initialized data ，应该放在 .data section 呢

Ps：自增的那个变量使用了 volatile关键字声明了

dr2001

crazydtone 发表于 2014-1-4 11:15
.text : code
.data : initialized data
.bss  : unintialized data

.bss需要C环境运行前被清0，这是前置默认条件。

因此，未初始化以及初始化为0的都会丢bss。

crazydtone

dr2001 发表于 2014-1-4 12:23
.bss需要C环境运行前被清0，这是前置默认条件。

因此，未初始化以及初始化为0的都会丢bss。 ...

谢谢。。。

SECTIONS
{
        . = 0x00000000 ;

        .init : AT(0)
                {
                        head.o init.o nand.o
                }

        . = 0x30000000 ;

            .text : AT(4096)
                {
                        *(.text)
                }
        .rodata ALIGN(4) : AT((LOADADDR(.text)+SIZEOF(.text)+3)&~(0x03))
                {       
                        *(.rodata*)
                }
            .data ALIGN(4) : AT((LOADADDR(.rodata)+SIZEOF(.rodata)+3)&~(0x03))

                {
                        *(.data)
                }

        __bss_start = .;
            .bss ALIGN(4)  :
                {        
                        *(.bss)  
                        *(COMMON)
                }
        __bss_end = .;

}

以上是我的 Linker Script，按照以下清零 .bss section

void clean_bss(void)
{
        extern int __bss_start,__bss_end;
        int *p=&__bss_start;

        for(;p<&__bss_end;p++)
                *p=0;
}

是这样吗？

Ps： VMA 和 LMA 把我弄的晕头转向的

VMA is the address the section will have when the output file is run.
LMA is the address at which the section will be loaded.

1、以上的Linker Script 中用AT指定该 section 的加载地址，此地址是该段存在于 NandFlash中的物理地址吗 ？

2、当不用AT指定 某 section 的加载地址时，LMA和VMA是一样的，那此时所指定的地址，比如 0x30000000，已经远远超过 NandFlash 的实际容量，那该文件是如何被放置的呢？

我不知道那里理解错了，1和2结合在一起想的话很矛盾 ，麻烦可否给点思路。。。

小弟谢谢你了。。。

crazydtone

不要沉，，，

crazydtone

Etual 帮忙看哈，谢谢，，，

Etual

crazydtone 发表于 2014-1-8 00:44
Etual 帮忙看哈，谢谢，，，

lma 在嵌入式中主要是知道 elf 文件的生成

一个比较好的讨论。你可以看看
http://bbs.chinaunix.net/thread-1963291-1-1.html

被搞到头晕是正常，我开始也很晕，想了好久才想明白，good luck :-)

crazydtone

Etual 发表于 2014-1-8 23:16
lma 在嵌入式中主要是知道 elf 文件的生成

一个比较好的讨论。你可以看看

谢谢 Etual 。。。

下面这些摘自你给我发的那个链接：
“......另外lma对于产生的bin size是有影响的，lma可以看成是在bin中的位置，vma是实际运行时的位置，所以产生的bin的size是看lma而不是vma
虽然lma对于elf的size没影响，但是objcopy成bin时，你就可以看到影响了......”

假如是这样的话，那我七楼那样理解是可以的，但是事实上并不是那个样子的。。。还是有疑问，呵呵...