深入浅出Hello World 1

首先的感谢那些无私奉献的大牛们，深入Hello World下载地址在http://blog.linux.org.tw/~jserv/archives/001844.html。在上面

还有源码的下载地址链接，同时还要感谢那些网上的勤勤恳恳写blog的bloger们。

Hello World是学习程序设计语言的第一个程序浅出 Hello World。我们试图分析自linux上的Hello World运行的整个过程，主要

包括下面的几个过程:

1.hello程序的编译链接过程和hello上可执行文件格式

2.hello可执行程序的加载及如何开始执行

3.hello在内存中镜像

4.寻址

5.调度程序

6.内存管理

7.系统调用

8.hello程序卸载

首先是hello可执行文件的连接过程，然后hello可执行文件如何被加载到内存中，然后从那里开始执行？在执行的过程中，可

能需要寻址，如何实现？可能的内核调度如何实现？内存管理如何实现？系统调用如何实现？hello程序执行完成之后，kernel

执行了那些清理的工作？

hello程序编译链接过程和hello可执行elf文件格式

vim hello.c

#include <stdio.h>
int main (int atgc, char* argv[])
{
printf ("Hello World");
return 0;
}

gcc hello.c -o hello

首先在Text Editor中编辑hello的source code，gcc在编译source code时，先执行预处理，完成将source code中的宏定义展开de

等功能，这个过程是由cpp完成，最终生成hello.i文件，然后由complier编译成hello.s，这个过程是由ccl完成，然后使用as

将上面的hello.s编译成hello.o，最后使用ld将上面生成的hello.o连接成可执行文件hello。

我们可以使用下面的命令来观察生成的hello程序：

file hello

hello: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux

2.6.15, not stripped

ldd hello

linux-gate.so.1 => (0xb7f01000)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7d89000)
/lib/ld-linux.so.2 (0xb7f02000)
objdump -x hello

hello: file format elf32-i386
hello
architecture: i386, flags 0x00000112:
EXEC_P, HAS_SYMS, D_PAGED
start address 0x08048310
Program Header:
PHDR off 0x00000034 vaddr 0x08048034 paddr 0x08048034 align 2**2
filesz 0x00000100 memsz 0x00000100 flags r-x
INTERP off 0x00000134 vaddr 0x08048134 paddr 0x08048134 align 2**0
filesz 0x00000013 memsz 0x00000013 flags r--
LOAD off 0x00000000 vaddr 0x08048000 paddr 0x08048000 align 2**12
filesz 0x000004c0 memsz 0x000004c0 flags r-x
LOAD off 0x00000f0c vaddr 0x08049f0c paddr 0x08049f0c align 2**12
filesz 0x00000108 memsz 0x00000110 flags rw-
DYNAMIC off 0x00000f20 vaddr 0x08049f20 paddr 0x08049f20 align 2**2
filesz 0x000000d0 memsz 0x000000d0 flags rw-
NOTE off 0x00000148 vaddr 0x08048148 paddr 0x08048148 align 2**2
filesz 0x00000020 memsz 0x00000020 flags r--
STACK off 0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**2
filesz 0x00000000 memsz 0x00000000 flags rw-
RELRO off 0x00000f0c vaddr 0x08049f0c paddr 0x08049f0c align 2**0
filesz 0x000000f4 memsz 0x000000f4 flags r--
反汇编:objdump -d hello

hello: file format elf32-i386
Disassembly of section .init:
08048294 <_init>:
8048294: 55 push %ebp
8048295: 89 e5 mov %esp,%ebp
8048297: 53 push %ebx
8048298: 83 ec 04 sub $0x4,%esp
804829b: e8 00 00 00 00 call 80482a0 <_init+0xc>
80482a0: 5b pop %ebx
80482a1: 81 c3 54 1d 00 00 add $0x1d54,%ebx
80482a7: 8b 93 fc ff ff ff mov -0x4(%ebx),%edx
80482ad: 85 d2 test %edx,%edx
80482af: 74 05 je 80482b6 <_init+0x22>
80482b1: e8 1e 00 00 00 call 80482d4 <__gmon_start__@plt>
80482b6: e8 e5 00 00 00 call 80483a0 <frame_dummy>
80482bb: e8 a0 01 00 00 call 8048460 <__do_global_ctors_aux>
80482c0: 58 pop %eax
80482c1: 5b pop %ebx
80482c2: c9 leave
80482c3: c3 ret
Disassembly of section .plt:
...

经过上面的观察，产生下面的疑问：ldd链接的文件的作用是什么？链接程序时发生了什么？可执行文件的格式是怎样的？为了解决上面的问题还

是得首先了解一下计算机程序的基础知识。

1.bss/data/code段，对于下面的程序:

int a;

int k = 3;

int foo (void)

{

return (k);

}

int b = 12;

int bar(void)

{

a = 0;

return (a + b);

}

在生成的汇编文件中，bss/data/text段如下：

------------------------

a = 0 bss

-----------------------

k = 3 b = 12 data

----------------------

ret text

----------------------

于是根据汇编文件生成的可执行文件镜像大致结构如下:

---------------------

12 data

3

---------------------

ret text

----------------------

header

---------------------

那么汇编文件中的bss段怎么没有了？在可执行文件的镜像中，在header中包含有该文件bss段的信息 。在kernel装载该hello可执行文件时，会产生

如下的内存镜像 ：

----------------------- bss，kernel根据hello的文件头header来得到bss段的信息

0

-----------------------

12 3 data

----------------------

ret text

---------------------

上面的只是一个文件的情况，没有涉及到链接，那如果是两个.o文件，ld链接程序是如何链接程序的？首先需要说明的是每个object file都是具有相同的address space，在链接多个.o文件时，ld所作的工作就是分别将各个object file的bss text data段分别组成到新的bss text data段。最终在生成的elf

文件中：

-----------------------

elf header include magic number, file type, machine,...

-----------------------

program header table page size, virtual address memory segment, segment size

-----------------------

.text section code

-----------------------

.data section initialized data

-----------------------

.bss section bass data (0)

-----------------------

.symtab symbol table

------------------------

.rel.text relocation information for text section

-------------------------

.rel.data relocation information for .data section

-------------------------

.debug debug information

------------------------

section header table

------------------------

对于上面的elf文件elf header可以使用readelf -h filename来读取文件头。

readelf -h hello

ELF Header:

Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00

Class: ELF32

Data: 2's complement, little endian

Version: 1 (current)

OS/ABI: UNIX - System V

ABI Version: 0

Type: EXEC (Executable file)

Machine: Intel 80386

Version: 0x1

Entry point address: 0x8048310

Start of program headers: 52 (bytes into file)

Start of section headers: 5996 (bytes into file)

Flags: 0x0

Size of this header: 52 (bytes)

Size of program headers: 32 (bytes)

Number of program headers: 8

Size of section headers: 40 (bytes)

Number of section headers: 36

Section header string table index: 33

对于上面的输出需要注意的是Entry point address: 0x8048310，Entry point address定义了elf文件执行的开始地址。下面是详细的解释：

http://blog.sina.com.cn/s/blog_5b9ea9840100avgg.html###

When executed, program will start running from virtual address 0x80482c0 (see entry point address). The "0x" prefix here means it is a hexadecimal number. This address doesn't point to our main() procedure, but to a procedure named _start. Never felt you had created such thing? Of course you don't. _start procedure is created by the linker whose purpose is to initialize your program.

同时可以使用gdb反汇编：

gdb hello

(gdb) disassemble 0x8048310

Dump of assembler code for function _start:

0x08048310 <_start+0>: xor %ebp,%ebp

0x08048312 <_start+2>: pop %esi

0x08048313 <_start+3>: mov %esp,%ecx

0x08048315 <_start+5>: and $0xfffffff0,%esp

0x08048318 <_start+8>: push %eax

0x08048319 <_start+9>: push %esp

0x0804831a <_start+10>: push %edx

0x0804831b <_start+11>: push $0x80483f0

0x08048320 <_start+16>: push $0x8048400

0x08048325 <_start+21>: push %ecx

0x08048326 <_start+22>: push %esi

0x08048327 <_start+23>: push $0x80483c4

0x0804832c <_start+28>: call 0x80482e4 <__libc_start_main@plt>

0x08048331 <_start+33>: hlt

可见程序是在地址0x8048310开始执行（注意的是此时还是虚地址），然后通过设置调用printf函数前的相关工作，然后call 0x80482e4 <__libc_start_main@plt>调用printf函数。

综上，hello.c源程序，通过编译生成.o文件，然后在通过ld程序链接成elf可执行文件。ld在链接时，默认使用的ld script可以使用命令查看:

ld --verbose。关于链接脚本的解释参见：http://fxl.blogbus.com/logs/12451338.在ld script中指定elf文件的加载地址和虚地址，上面的两种地址

在一般的情况下是相同的，但是在一些嵌入式的程序中加载地址和执行地址是不同的。

既然在elf文件中定义了程序在加载的虚地址，那么程序是如何被加载的？加载的内存镜像又是什么样子的？如何查看实际的物理地址?呵呵，有时间

接着开始...