当前位置:  开发笔记 > 编程语言 > 正文

什么是"ld -Ttext"选项呢?

如何解决《什么是"ld-Ttext"选项呢?》经验,为你挑选了1个好方法。

我正在按照这个半完成的教程来开发一个简单的操作系统.一步(第50页)是使用编译一个简单的内核$ld -o kernel.bin -Ttext 0x1000 kernel.o --oformat binary.但是我真的不明白选项-Ttext在做什么.

为了使问题具体化,为什么在以下实验中md5s为kernel_1000.bin&kernel.binequal,kernel_1001.bin&kernel_1009.binequal和kernel_1007.bin&kernel_1017.binequal,而所有其他对不相等?

我的实验

我尝试编译几个不同的内核,-Ttext如下所示Makefile:

...
kernel.o: kernel.c
    gcc -ffreestanding -c kernel.c

kernel.bin: kernel.o
    ld -o $@ kernel.o --oformat binary

kernel_1000.bin: kernel.o
    ld -o $@ -Ttext 0x1000 kernel.o --oformat binary

kernel_1001.bin: kernel.o
    ld -o $@ -Ttext 0x1001 kernel.o --oformat binary
...

然后我检查了他们的md5:

$ ls *.bin | xargs md5sum
d9248440a2c816e41527686cdb5118e4  kernel_1000.bin
65db5ab465301da1176b523dec387a40  kernel_1001.bin
819a5638827494a4556b7a96ee6e14b2  kernel_1007.bin
d9248440a2c816e41527686cdb5118e4  kernel_1008.bin
65db5ab465301da1176b523dec387a40  kernel_1009.bin
216b24060abce034911642acfa880403  kernel_1015.bin
e92901b1d12d316c564ba7916abca20c  kernel_1016.bin
819a5638827494a4556b7a96ee6e14b2  kernel_1017.bin
d9248440a2c816e41527686cdb5118e4  kernel.bin
kernel.c
void main() {
  char* video_memory = (char*) 0xb8000;
  *video_memory = 'X';
}
发展环境
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.2-10' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.9 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.9.2 (Debian 4.9.2-10) 
$ uname -a
Linux localhost 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u1 (2015-12-14) x86_64 GNU/Linux

0xAX.. 7

-Ttext选项将程序的.text部分放在给定的地址中.例如,如果您编译此汇编代码:

section .text
global _start
_start:
    mov al, '!'
    jmp l
l:  mov ah, 0x0e
    mov bh, 0x00
    mov bl, 0x07

    int 0x10
    jmp $

times 510-($-$$) db 0

db 0x55
db 0xaa

有:

nasm -f elf64 -o test.o test.S
ld -o test test.o

并且会用它来查看它objdump,你会看到它是通过默认地址链接的,0x0000000000400000有关x86_64:

~$ objdump -D test

test:     file format elf64-x86-64


Disassembly of section .text:

0000000000400080 <_start>:
  400080:   b0 21                   mov    $0x21,%al
  400082:   eb 00                   jmp    400084 

0000000000400084 :
  400084:   b4 0e                   mov    $0xe,%ah
  ...
  ...
  ...

程序中的所有地址(至少在本.text节中)都与该地址有关.如果您要添加该-Ttext 1000选项,您将看到:

〜$ objdump -D测试

test:     file format elf64-x86-64


Disassembly of section .text:

0000000000001000 <_start>:
    1000:   b0 21                   mov    $0x21,%al
    1002:   eb 00                   jmp    1004 

0000000000001004 :
    1004:   b4 0e                   mov    $0xe,%ah

您编程将链接到0x1000地址开始,所有地址(包括jmp等)将相0x1000对于.

这对两件事很重要.简而言之,当操作系统内核加载程序时,它会以elf格式或其他二进制格式加载可执行文件,并读取该.text部分的开始位置.在我们的例子中,您可以kernel.bin根据需要链接您,因为没有加载器作为操作系统内核,并且您是所有内存空间的主人.

因此,如果您将链接kernel.bin开始0x1000,您将知道代码开始工作的位置(当然,如果它实际上将在内存中的这个位置加载),并且如果您知道代码的基址,则可以获取内部的所有地址它,像my_label_inside_program - _start.



1> 0xAX..:

-Ttext选项将程序的.text部分放在给定的地址中.例如,如果您编译此汇编代码:

section .text
global _start
_start:
    mov al, '!'
    jmp l
l:  mov ah, 0x0e
    mov bh, 0x00
    mov bl, 0x07

    int 0x10
    jmp $

times 510-($-$$) db 0

db 0x55
db 0xaa

有:

nasm -f elf64 -o test.o test.S
ld -o test test.o

并且会用它来查看它objdump,你会看到它是通过默认地址链接的,0x0000000000400000有关x86_64:

~$ objdump -D test

test:     file format elf64-x86-64


Disassembly of section .text:

0000000000400080 <_start>:
  400080:   b0 21                   mov    $0x21,%al
  400082:   eb 00                   jmp    400084 

0000000000400084 :
  400084:   b4 0e                   mov    $0xe,%ah
  ...
  ...
  ...

程序中的所有地址(至少在本.text节中)都与该地址有关.如果您要添加该-Ttext 1000选项,您将看到:

〜$ objdump -D测试

test:     file format elf64-x86-64


Disassembly of section .text:

0000000000001000 <_start>:
    1000:   b0 21                   mov    $0x21,%al
    1002:   eb 00                   jmp    1004 

0000000000001004 :
    1004:   b4 0e                   mov    $0xe,%ah

您编程将链接到0x1000地址开始,所有地址(包括jmp等)将相0x1000对于.

这对两件事很重要.简而言之,当操作系统内核加载程序时,它会以elf格式或其他二进制格式加载可执行文件,并读取该.text部分的开始位置.在我们的例子中,您可以kernel.bin根据需要链接您,因为没有加载器作为操作系统内核,并且您是所有内存空间的主人.

因此,如果您将链接kernel.bin开始0x1000,您将知道代码开始工作的位置(当然,如果它实际上将在内存中的这个位置加载),并且如果您知道代码的基址,则可以获取内部的所有地址它,像my_label_inside_program - _start.

推荐阅读
郑谊099_448
这个屌丝很懒,什么也没留下!
DevBox开发工具箱 | 专业的在线开发工具网站    京公网安备 11010802040832号  |  京ICP备19059560号-6
Copyright © 1998 - 2020 DevBox.CN. All Rights Reserved devBox.cn 开发工具箱 版权所有