Chinaunix

标题: GCC 链接脚本这样写对吗?编译出来的bin 居然有700多M [打印本页]

作者: cjjnjust 时间: 2010-09-30 23:26
标题: GCC 链接脚本这样写对吗?编译出来的bin 居然有700多M
本帖最后由 cjjnjust 于 2010-10-08 16:04 编辑

我的目的就是想用jlink直接加载到RAM中运行.
利用这个脚本编译出来的elf文件大概几百K,但是用objcopy生成bin 后照理说是变小,但是确是700多M.

补充:我想调用C库中的vsprintf函数.
SECTIONS{
. = 0x30000000;
. = ALIGN(4);
.text : {
nand_main.o (.text)
* (.text)
}
__libc_subinit : { * (__libc_subinit) }
__libc_atexit : { * (__libc_atexit) }
__libc_subfreeres : { * (__libc_subfreeres) }

. = ALIGN(4);
.rodata : { * (.rodata) }
. = ALIGN(4);
.data : { * (.data) }

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

目前我的办法是直接在脚本里面为这些段添加装载地址.这样弄了好像就可以了.不知道方法正确不.

作者: linyunxian 时间: 2010-10-01 09:52
给出你的 objdump 命令的参数看看？

作者: cjjnjust 时间: 2010-10-07 18:56
国庆哈哈..
下面是arm-linux-objdump -h nand_elf 的输出结果.
nand_elf:    file format elf32-littlearm

Sections:
Idx Name       Size    VMA    LMA    File off  Algn
  0 .text       00046f00  30000000  30000000  0000d090  2**4
               CONTENTS, ALLOC, LOAD, CODE
  1 .glue_7    00000000  30046f00  30046f00  00053f90  2**2
               CONTENTS, ALLOC, LOAD, READONLY, CODE
  2 .glue_7t    00000000  30046f00  30046f00  00053f90  2**2
               CONTENTS, ALLOC, LOAD, READONLY, CODE
  3 .data       000010c8  30046f00  30046f00  00053f90  2**2
               CONTENTS, ALLOC, LOAD, DATA
  4 .got       00000008  30047fc8  30047fc8  00055058  2**2
               CONTENTS, ALLOC, LOAD, DATA
  5 .got.plt    0000000c  30047fd0  30047fd0  00055060  2**2
               CONTENTS, ALLOC, LOAD, DATA
  6 .bss       00000cb4  30047fe0  30047fe0  00055070  2**4
               ALLOC
  7 .rodata.str1.4 00000038  30048c94  30048c94  00055070  2**2
               CONTENTS, ALLOC, LOAD, READONLY, DATA
  8 .comment    0000236e  00000000  00000000  000550a8  2**0
               CONTENTS, READONLY
  9 __libc_atexit 00000004  00002370  00002370  00000094  2**2
               CONTENTS, ALLOC, LOAD, READONLY, DATA
10 .rodata    0000cfa8  00002374  00002374  00000098  2**2
               CONTENTS, ALLOC, LOAD, READONLY, DATA
11 __libc_subinit 0000000c  0000f31c  0000f31c  0000d040  2**2
               CONTENTS, ALLOC, LOAD, READONLY, DATA
12 __libc_subfreeres 0000003c  0000f328  0000f328  0000d04c  2**2
               CONTENTS, ALLOC, LOAD, READONLY, DAT

我想应该是我在代码里面调用C库的vsprintf函数的原因.然后它调用了这三个函数:
__lib_atexit __libc_subinit __libc_subfreeres
不过奇怪.当用ADS的时候.scat_ram.scf链接脚本里面也是这样.为什么它没有问题.

作者: wwwlh 时间: 2010-10-08 10:50
__libc_subinit会预先初始化内存空间，你以jlink直接加载到RAM运行自然要初始化内存了，预分配的方式是生成巨大的空间了。

作者: cjjnjust 时间: 2010-10-08 11:29
回复 4# wwwlh
我的步骤是:
h
loadbin nand.bin 0x30000000
setpc 0x30000000
g
其实板子上有VIVI ,在我开板子的时候就应该初始化过了.

当我不调用C库的相关函数的时候,bin 文件就正常了.一调用到C库的文件,就会导致bin文件异常大.这个还真的比较晕.
是不是C库中的函数的地址采用虚拟地址,大概在0x0000**什么的.而我这边虚拟地址和物理地址相同,导致了bin文件要填充0x00000000-0x33fffffff之间的空间来给C库函数.

欢迎光临 Chinaunix (http://bbs.chinaunix.net/)