为什么arm none在链接时会将程序头与64KiB对齐?我该如何更改它



考虑以下程序和相应的链接器脚本:

// file: foo.c
int foo = 42;
/* file: link.x */
SECTIONS {
.data : { *(.data) }
/DISCARD/ : { *(*) }
}

现在我构建并链接如下:

$ arm-none-eabi-gcc -c foo.c
$ arm-none-eabi-ld -T link.x foo.o -o foo

我遇到的问题是链接器生成了一个巨大的文件:

$ ls -lh
total 20K
-rwxr-xr-x 1 admin admin 65K Mar 20 12:29 foo
-rw-r--r-- 1 admin admin  14 Mar 20 12:18 foo.c
-rw-r--r-- 1 admin admin 724 Mar 20 12:19 foo.o
-rw-r--r-- 1 admin admin  64 Mar 20 12:18 link.x

foo.o对象只有724字节,但链接的foo可执行文件是65KiB!

readelf快速揭示问题:

$ readelf -l foo
Elf file type is EXEC (Executable file)
Entry point 0x0
There is 1 program header, starting at offset 52
Program Headers:
Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
LOAD           0x010000 0x00000000 0x00000000 0x00004 0x00004 RW  0x10000
Section to Segment mapping:
Segment Sections...
00     .data 

程序标题的对齐为0x10000,这可以通过hexdump:进行确认

$ hexdump foo
0000000 457f 464c 0101 0001 0000 0000 0000 0000
0000010 0002 0028 0001 0000 0000 0000 0034 0000
0000020 0084 0001 0200 0500 0034 0020 0001 0028
0000030 0005 0004 0001 0000 0000 0001 0000 0000
0000040 0000 0000 0004 0000 0004 0000 0006 0000
0000050 0000 0001 0000 0000 0000 0000 0000 0000
0000060 0000 0000 0000 0000 0000 0000 0000 0000
*
0010000 002a 0000 0000 0000 0000 0000 0000 0000
0010010 0000 0000 0000 0000 0000 0000 0000 0000
0010020 0003 0001 0001 0000 0000 0000 0000 0000
0010030 0004 fff1 0007 0000 0000 0000 0000 0000
0010040 0000 0001 000a 0000 0000 0000 0004 0000
0010050 0011 0001 6600 6f6f 632e 2400 0064 6f66
0010060 006f 2e00 7973 746d 6261 2e00 7473 7472
0010070 6261 2e00 6873 7473 7472 6261 2e00 6164
0010080 6174 0000 0000 0000 0000 0000 0000 0000
0010090 0000 0000 0000 0000 0000 0000 0000 0000
00100a0 0000 0000 0000 0000 0000 0000 001b 0000
00100b0 0001 0000 0003 0000 0000 0000 0000 0001
00100c0 0004 0000 0000 0000 0000 0000 0004 0000
00100d0 0000 0000 0001 0000 0002 0000 0000 0000
00100e0 0000 0000 0004 0001 0050 0000 0003 0000
00100f0 0004 0000 0004 0000 0010 0000 0009 0000
0010100 0003 0000 0000 0000 0000 0000 0054 0001
0010110 000e 0000 0000 0000 0000 0000 0001 0000
0010120 0000 0000 0011 0000 0003 0000 0000 0000
0010130 0000 0000 0062 0001 0021 0000 0000 0000
0010140 0000 0000 0001 0000 0000 0000          
001014c

所以本质上有一个小标题,后面跟着大约64KiB的对齐,后面跟着一个小后缀。

这种对齐方式是从哪里来的?我如何才能消除这种对齐

如果我用我的常规工具链进行相同的过程,这不会发生:

$ gcc -c foo.c
$ ld -T link.x foo.o -o foo
$ ls -lh
total 20K
-rwxr-xr-x 1 admin admin 4.5K Mar 20 13:01 foo
-rw-r--r-- 1 admin admin   30 Mar 20 13:00 foo.c
-rw-r--r-- 1 admin admin  952 Mar 20 13:01 foo.o
-rw-r--r-- 1 admin admin   84 Mar 20 13:01 link.x

所以这似乎与ARM有关?

写下这个问题让我找到了答案,链接器试图将.data部分与页面边界对齐,默认情况下该边界似乎是64KiB。(这看起来真的很大,可能是无意的?(

无论如何,正如这篇博客文章中的一条评论所建议的那样,链接器选项--nmagic将关闭:

-n
--nmagic
Turn off page alignment of sections, and disable linking
against shared libraries.  If the output format supports Unix
style magic numbers, mark the output as "NMAGIC".

ld(1(手册页

有了这个变化,二进制现在是416字节,而不是65KiB:

$ arm-none-eabi-gcc -c foo.c
$ arm-none-eabi-ld -T link.x foo.o -o foo --nmagic
$ ls -lh
total 16K
-rwxr-xr-x 1 admin admin 416 Mar 20 13:17 foo
-rw-r--r-- 1 admin admin  30 Mar 20 13:17 foo.c
-rw-r--r-- 1 admin admin 724 Mar 20 13:17 foo.o
-rw-r--r-- 1 admin admin  84 Mar 20 13:17 link.x

最新更新