linker - What is "ld -Ttext" option doing? -

i following this half-completed tutorial develop simple os. 1 step (on page 50) compile simple kernel $ld -o kernel.bin -ttext 0x1000 kernel.o --oformat binary. don't understand option -ttext doing.

to make question specific, why in following experiment md5s of kernel_1000.bin & kernel.bin equal, kernel_1001.bin & kernel_1009.bin equal, , kernel_1007.bin & kernel_1017.bin equal, while other pairs not equal?

my experiment

i tried compile several different kernels different -ttext in following 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 ... 

and checked 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'; } 

development environment

$ 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 

the -ttext option puts .text section of program given address. example if compile assembly code:

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 

with:

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

and on objdump, see linked default address, around 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 <l>  0000000000400084 <l>:   400084:   b4 0e                   mov    $0xe,%ah   ...   ...   ... 

and addresses in program (at least in .text section) relative address. if add -ttext 1000 option, see:

~$ objdump -d test

test:     file format elf64-x86-64   disassembly of section .text:  0000000000001000 <_start>:     1000:   b0 21                   mov    $0x21,%al     1002:   eb 00                   jmp    1004 <l>  0000000000001004 <l>:     1004:   b4 0e                   mov    $0xe,%ah 

that program linked start @ 0x1000 address , addresses (including jmp , etc.) relative 0x1000 to.

this important 2 things. in short words, when operating system kernel loads program, loads executable in elf format or in other binary format , reads .text section starts. in our case, can link kernel.bin want, because there no loaders operating system kernel , master of memory space.

so if link kernel.bin start @ 0x1000, know code starts work (of course if loaded @ place in memory) , if know base address of code, can addresses inside it, my_label_inside_program - _start.