プログラムはどう動くのか? 〜 ELFの黒魔術をかいまみる もう締切日なのにネタがない。というわけで簡単なプログラム "hello, world" がどのように起動され、どのように処理されて動くのかを無意味に詳しく解説してみよう。 #include int main(int argc, char *argv[]) { printf("hello, world\n"); exit(0); } この hello.c をコンパイルすると次のようなhelloというバイナリができる % cc -g -o hello hello.c この hello というバイナリは % file hello hello: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.0, dynamically linked (uses shared libs), not stripped のように ELFというフォーマットのバイナリである。 dynamically linked なので ldd をつかうと % ldd hello libc.so.6 => /lib/libc.so.6 (0x4001c000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) のようにどの shared libs を使っているのかを見ることができる。 より詳しくは objdump をつかうとELFバイナリの中身をみることができる。 たとえば -x (--all-headers) でこのバイナリの実行コードではない情報、つまりどのアーキテクチャむけのバイナリか、どのshared libsを必要としているか、どういったsymbolがなかで使われているか/使おうとしているかなどといった情報を見ることができる。 % objdump -x hello hello: ファイル形式 elf32-i386 hello アーキテクチャ: i386, フラグ 0x00000112: EXEC_P, HAS_SYMS, D_PAGED 開始アドレス 0x08048340 プログラムヘッダ: PHDR off 0x00000034 vaddr 0x08048034 paddr 0x08048034 align 2**2 filesz 0x000000c0 memsz 0x000000c0 flags r-x INTERP off 0x000000f4 vaddr 0x080480f4 paddr 0x080480f4 align 2**0 filesz 0x00000013 memsz 0x00000013 flags r-- LOAD off 0x00000000 vaddr 0x08048000 paddr 0x08048000 align 2**12 filesz 0x000004b2 memsz 0x000004b2 flags r-x LOAD off 0x000004b4 vaddr 0x080494b4 paddr 0x080494b4 align 2**12 filesz 0x00000110 memsz 0x00000128 flags rw- DYNAMIC off 0x000004c8 vaddr 0x080494c8 paddr 0x080494c8 align 2**2 filesz 0x000000c8 memsz 0x000000c8 flags rw- NOTE off 0x00000108 vaddr 0x08048108 paddr 0x08048108 align 2**2 filesz 0x00000020 memsz 0x00000020 flags r-- (以下略) また -d (--disassemble) で逆アセンブルが、バイナリが-gオプションでビルドされていれば-S(--source) でソースコードとの対応も見ることができる。 % objdump -d hello hello: ファイル形式 elf32-i386 セクション .init の逆アセンブル: 80482bc: 55 push %ebp 80482bd: 89 e5 mov %esp,%ebp 80482bf: 83 ec 08 sub $0x8,%esp 80482c2: e8 9d 00 00 00 call 8048364 80482c7: 90 nop 80482c8: e8 1b 01 00 00 call 80483e8 80482cd: e8 7e 01 00 00 call 8048450 <__do_global_ctors_aux> 80482d2: c9 leave 80482d3: c3 ret セクション .plt の逆アセンブル: (以下略) % objdump -S hello hello: ファイル形式 elf32-i386 セクション .init の逆アセンブル: 080482bc <_init>: (略) 08048420
: #include int main(int argc, char *argv[]) { 8048420: 55 push %ebp 8048421: 89 e5 mov %esp,%ebp 8048423: 83 ec 08 sub $0x8,%esp printf("hello, world\n"); 8048426: 83 c4 f4 add $0xfffffff4,%esp 8048429: 68 a4 84 04 08 push $0x80484a4 804842e: e8 e1 fe ff ff call 8048314 <_init+0x58> 8048433: 83 c4 10 add $0x10,%esp exit(0); 8048436: 83 c4 f4 add $0xfffffff4,%esp 8048439: 6a 00 push $0x0 804843b: e8 e4 fe ff ff call 8048324 <_init+0x68> 8048440: 83 c4 10 add $0x10,%esp } 8048443: c9 leave 8048444: c3 ret (以下略) さて、これをshell(例えばbash)から起動する場合、fork(2)してstdin,stdout,stderrなどのリダイレクトの処理などをしてからexec(2)で、プログラムがfork(2)されたbashからexec(2)で指定したプログラム(この場合は hello)におきかわって実行が開始される。これを順をおってみていってみよう。 まず、execute_cmd.cのshell_execve()の中で execve(2)が呼ばれる。これはglibcのsysdeps/unix/sysv/linux/execve.cで、 return INLINE_SYSCALL (execve, 3, file, argv, envp); により system callのよびだしが行なわれる。これはsysdeps/unix/sysv/linux/i386/sysdep.h で #define されており以下のようなかんじのasmを実行することになる movl ,%edi movl ,%ecx movl ,%edx movl $11, %eax # execve int $0x80 このように %eax にsystemcall番号、%edx、%ecx,%ediあたりに引数がセットされて、int $0x80が実行される。int命令はソフトウェア割り込みでこの時点でkernel modeに移行する。kernelの初期化段階に arch/i386//kernel/traps.c のtrap_init()で set_system_gate(SYSCALL_VECTOR,&system_call); # SYSCALL_VECTOR = 0x80 と設定されているので、int $0x80が呼ばれるとsystem_callへやってくる。このsystem_callというのはarch/i386/kernel/entry.Sにある ENTRY(system_call) である。ここでは基本的にレジスタをスタックにつんで%eaxの内容に従ってsys_call_tableに設定されているアドレスをcallすることになる。 call *SYMBOL_NAME(sys_call_table)(,%eax,4) sys_call_tableもおなじくentry.Sにあり11番目が sys_execve である ENTRY(sys_call_table) 略 .long SYMBOL_NAME(sys_unlink) /* 10 */ .long SYMBOL_NAME(sys_execve) .long SYMBOL_NAME(sys_chdir) 略 sys_execveは arch/i386/kernel/process.c の asmlinkage int sys_execve(struct pt_regs regs)である。 asmlinkage int sys_execve(struct pt_regs regs) { int error; char * filename; filename = getname((char *) regs.ebx); error = PTR_ERR(filename); if (IS_ERR(filename)) goto out; error = do_execve(filename, (char **) regs.ecx, (char **) regs.edx, ® s); if (error == 0) current->ptrace &= ~PT_DTRACE; putname(filename); out: return error; } このように %ebx に設定されているファイル名をチェックしたあと、do_execve()を読んでいる。system callを読んだ時に%ecxにはargvを%edxにはenvpを設定してあるのでここは do_execve(filename, argv, envp, ...) のようによびだしていることになる。ここまでがarch依存なコードでありあとは非依存なコードに移行する。do_execve()はfs/exec.cにある。 do_execve()ではまずfilenameで指定されたファイルをファイルシステムからopen_exec()をつかって読みこんでいる。ここでパーミッションのチェックなども行なっている。openに成功すればstruct linux_binprmの情報を設定していく。struct linux_binprmにはargvやenvp,uid,gidなどの情報が保持されている。そしてexecしようとしているファイルの最初のBINPRM_BUF_SIZE (128byte)を読みこむ。 search_binary_handler()でfile headerのmagic numberなどをチェックし、そのbinary formatをあつかうhandlerをstruct linux_binfmt *formatsのなかから探しだしている。ELFに関してはfs/binfmt_elf.cのelf_formatの中のload_elf_binary()でELFヘッダのチェックがおこなわれている。ここでmagic numberなど必要な情報のチェックにクリアすればELF headerをkernel_read()をつかって読みこみをする。 ここで elf_ppnt->p_type == PT_INTERP で .interp sectionをみつけるとこの内容を読みとる。この内容は % objdump -s -j .interp hello hello: ファイル形式 elf32-i386 セクション .interp の内容: 80480f4 2f6c6962 2f6c642d 6c696e75 782e736f /lib/ld-linux.so 8048104 2e3200 .2. である。つまり elf_interpreter = "/lib/ld-linux.so.2" というのが読みこまれる。 ここで再び elf_interpreter を open_exec()して BINPRM_BUF_SIZE分だけよみこんでいる。symbolic linkをたどって、これは % file /lib/ld-linux.so.2 /lib/ld-linux.so.2: symbolic link to ld-2.3.1.so % file /lib/ld-2.3.1.so /lib/ld-2.3.1.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped という shared objectを実行することになる。 flush_old_exec() で現在のprogramの情報を消し、新しいprogramのための情報にcurrentの情報をいれかえていく。memory mapが初期化されプログラムヘッダでLOADのところがmapされる。fileszよりmemszがおおきい場合はその分のmemoryがこのあたりで 0 に fillされるように設定される。 最後に elf_interpreter "/lib/ld-2.3.1.so" がload_elf_interp()によってmemory上にmapされる。 % objdump -x /lib/ld-2.3.1.so /lib/ld-2.3.1.so: ファイル形式 elf32-i386 /lib/ld-2.3.1.so アーキテクチャ: i386, フラグ 0x00000150: HAS_SYMS, DYNAMIC, D_PAGED 開始アドレス 0x00000b50 プログラムヘッダ: LOAD off 0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**12 filesz 0x00010e00 memsz 0x00010e00 flags r-x LOAD off 0x00011000 vaddr 0x00011000 paddr 0x00011000 align 2**12 filesz 0x00000554 memsz 0x00000700 flags rw- DYNAMIC off 0x000113f8 vaddr 0x000113f8 paddr 0x000113f8 align 2**2 filesz 0x000000b0 memsz 0x000000b0 flags rw- (略) その後、currentの情報をさらに設定していって start_thread(regs, elf_entry, bprm->p); で elf_entry から実行を開始する。elf_entry は /lib/ld-2.3.1.so の entry(開始アドレス)からとなる。start_threadは include/asm-i386/processor.h で次のように #define されている。 #define start_thread(regs, new_eip, new_esp) do { \ __asm__("movl %0,%%fs ; movl %0,%%gs": :"r" (0)); \ set_fs(USER_DS); \ regs->xds = __USER_DS; \ regs->xes = __USER_DS; \ regs->xss = __USER_DS; \ regs->xcs = __USER_CS; \ regs->eip = new_eip; \ regs->esp = new_esp; \ } while (0) つまり elf_entry を次の %eip として設定している。これで search_binary_handler()からreturnしてdo_execve()がおり、sys_execve()からreturnする。 で、arch/i386/kernel/entry.S の call *SYMBOL_NAME(sys_call_table)(,%eax,4) に戻ってきて以下が実行される。 movl %eax,EAX(%esp) # save the return value ENTRY(ret_from_sys_call) cli # need_resched and signals atomic test cmpl $0,need_resched(%ebx) jne reschedule cmpl $0,sigpending(%ebx) jne signal_return restore_all: RESTORE_ALL rescheduleがよびだされて、kernel/sched.cのasmlinkage void schedule(void)の なかから include/asm-i386/system.hのswitch_to()からarch/i386/kernel/process.c の__switch_to()にきて %esp, %fs, %gs がいれかえられる。 そうして execされたプロセスに制御がまわってくると、このprocessの%eip、つまりelf_interpreterのentry addressから実行を開始することになる。 % objdump -f /lib/ld-2.3.1.so /lib/ld-2.3.1.so: ファイル形式 elf32-i386 アーキテクチャ: i386, フラグ 0x00000150: HAS_SYMS, DYNAMIC, D_PAGED 開始アドレス 0x00000b50 % objdump -d /lib/ld-2.3.1.so (略) 00000b50 <_start>: b50: 89 e0 mov %esp,%eax b52: e8 03 01 00 00 call c5a <_dl_start> ということで /lib/ld-2.3.1.so の _start から実行を開始する。これはsysdeps/i386/dl-machine.h の #define RTLD_START のコードである。 で_dl_start()がよばれる。この_dl_start()は glibcの elf/rtld.c の _dl_start()である。まず bootstrap_map.l_infoを 0 で初期化する。 sysdeps/i386/dl_machine.h に定義されているelf_machine_load_address()を つかってdynamic linker自体がどのアドレスにあるかを調べている。 で sysdeps/generic/dl-sysdep.c の _dl_sysdep_start()からelf/rtld.cの dl_main()がよばれてくる。まずここで process_envvars()がよばれ環境変数の チェックがおこなわれている。このコードをみると以下の環境変数が /lib/ld-2.3.1.soでつかわれていることがわかる。 LD_WARN - Warning level, verbose or not LD_DEBUG - Debugging of the dynamic linker? LD_VERBOSE - Print information about versions. LD_PRELOAD - List of objects to be preloaded. LD_PROFILE - Which shared object shall be profiled. LD_BIND_NOW - Do we bind early? LD_BIND_NOT - ? LD_SHOW_AUXV - Test whether we want to see the content of the auxiliary array passed up from the kernel. LD_HWCAP_MASK - Mask for the important hardware capabilities. LD_ORIGIN_PATH - Path where the binary is found. LD_LIBRARY_PATH - The library search path. LD_DEBUG_OUTPUT - Where to place the profiling data file. LD_DYNAMIC_WEAK - ? LD_PROFILE_OUTPUT - Where to place the profiling data file. LD_TRACE_PRELINKING - The mode of the dynamic linker can be set. LD_TRACE_LOADED_OBJECTS - The mode of the dynamic linker can be set. LD_PRELOAD や LD_LIBRARY_PATH はよく使われるが、他はあまりつかったことがないことだろう。とりあえずいくつかを簡単に紹介しよう。 % LD_DEBUG=help /lib/ld-2.3.1.so Valid options for the LD_DEBUG environment variable are: libs display library search paths reloc display relocation processing files display progress for input file symbols display symbol table processing bindings display information about symbol binding versions display version dependencies all all previous options combined statistics display relocation statistics help display this help message and exit To direct the debugging output into a file instead of standard output a filename can be specified using the LD_DEBUG_OUTPUT environment variable. たとえば 以下のような結果を得ることができる。 % LD_DEBUG=libs ./hello 04836: find library=libc.so.6; searching 04836: search cache=/etc/ld.so.cache 04836: trying file=/lib/libc.so.6 04836: 04836: 04836: calling init: /lib/libc.so.6 04836: 04836: 04836: initialize program: ./hello 04836: 04836: 04836: transferring control: ./hello 04836: hello, world 04836: 04836: calling fini: /lib/libc.so.6 04836: % LD_DEBUG=reloc ./hello 04837: 04837: relocation processing: /lib/libc.so.6 (lazy) 04837: 04837: relocation processing: ./hello (lazy) 04837: 04837: relocation processing: /lib/ld-linux.so.2 04837: 04837: calling init: /lib/libc.so.6 04837: 04837: 04837: initialize program: ./hello 04837: 04837: 04837: transferring control: ./hello 04837: hello, world 04837: 04837: calling fini: /lib/libc.so.6 04837: % LD_DEBUG=files ./hello 04839: 04839: file=libc.so.6; needed by ./hello 04839: file=libc.so.6; generating link map 04839: dynamic: 0x40129618 base: 0x4001c000 size: 0x00112184 04839: entry: 0x40031a40 phdr: 0x4001c034 phnum: 7 04839: 04839: 04839: calling init: /lib/libc.so.6 04839: 04839: 04839: initialize program: ./hello 04839: 04839: 04839: transferring control: ./hello 04839: hello, world 04839: 04839: calling fini: /lib/libc.so.6 04839: % LD_DEBUG=symbols ./hello 04845: symbol=_IO_file_close; lookup in file=./hello 04845: symbol=_IO_file_close; lookup in file=/lib/libc.so.6 04845: symbol=_IO_2_1_stdin_; lookup in file=./hello 04845: symbol=_IO_2_1_stdin_; lookup in file=/lib/libc.so.6 04845: symbol=_IO_2_1_stdout_; lookup in file=./hello 04845: symbol=_IO_2_1_stdout_; lookup in file=/lib/libc.so.6 04845: symbol=_IO_2_1_stderr_; lookup in file=./hello 04845: symbol=_IO_2_1_stderr_; lookup in file=/lib/libc.so.6 (略) % LD_DEBUG=bindings ./hello 4849: binding file /lib/libc.so.6 to /lib/libc.so.6: normal symbol `_IO_file_c lose' [GLIBC_2.0] 04849: binding file /lib/libc.so.6 to /lib/libc.so.6: normal symbol `_IO_2_1_st din_' [GLIBC_2.1] 04849: binding file /lib/libc.so.6 to /lib/libc.so.6: normal symbol `_IO_2_1_st dout_' [GLIBC_2.1] 04849: binding file /lib/libc.so.6 to /lib/libc.so.6: normal symbol `_IO_2_1_st derr_' [GLIBC_2.1] (略) % LD_DEBUG=versions ./hello 04852: checking for version `GLIBC_2.0' in file /lib/libc.so.6 required by file ./hello 04852: checking for version `GLIBC_2.1' in file /lib/ld-linux.so.2 required by file /lib/libc.so.6 04852: checking for version `GLIBC_2.0' in file /lib/ld-linux.so.2 required by file /lib/libc.so.6 04852: checking for version `GLIBC_PRIVATE' in file /lib/ld-linux.so.2 required by file /lib/libc.so.6 04852: (略) % LD_DEBUG=statistics ./hello 04854: number of relocations: 119 04854: number of relocations from cache: 5 hello, world 04854: 04854: runtime linker statistics: 04854: final number of relocations: 126 04854: final number of relocations from cache: 5 LD_DEBUG=all とすればすべてが出力される。またLD_DEBUG=help で書いてある通り、LD_DEBUG_OUTPUTも指定すればそのファイルに出力される。 LD_SHOW_AUXV を使うとおもしろい情報をみることができる。 % LD_SHOW_AUXV=1 /lib/ld-2.3.1.so ./hello AT_HWCAP: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse AT_PAGESZ: 4096 AT_CLKTCK: 100 AT_PHDR: 0x80000034 AT_PHENT: 32 AT_PHNUM: 3 AT_BASE: 0x0 AT_FLAGS: 0x0 AT_ENTRY: 0x80000b50 AT_UID: 1000 AT_EUID: 1000 AT_GID: 1000 AT_EGID: 1000 AT_PLATFORM: i686 hello, world これは sysdeps/generic/dl-sysdep.cの_dl_show_auxv()で処理している。 AT_HWCAP に関しては sysdeps/unix/sysv/linux/i386/dl-procinfo.hの _dl_procinfo()で処理している。 どの bit がどの文字列になるかは sysdeps/unix/sysv/linux/i386/dl-procinfo.cの_dl_x86_cap_flags[][]である。前から順に 1, 2, 4, ... に対応している。 LD_TRACE_PRELINKING でどうリンクされるかを確認できる % LD_TRACE_PRELINKING=1 ./hello ./hello => ./hello (0x08048000, 0x00000000) libc.so.6 => /lib/libc.so.6 (0x4001c000, 0x4001c000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000, 0x40000000) lookup 0x4001c000 0x000053a0 -> 0x4001c000 0x00064dfc /0 _IO_file_close lookup 0x4001c000 0x00005530 -> 0x4001c000 0x0010a1e0 /0 _IO_2_1_stdin_ lookup 0x4001c000 0x00004a50 -> 0x4001c000 0x0010a340 /0 _IO_2_1_stdout_ lookup 0x4001c000 0x0000b7e0 -> 0x4001c000 0x0010a4a0 /0 _IO_2_1_stderr_ LD_TRACE_LOADED_OBJECTS はどのshared libsをloadするかを見ることができる。 つまり ldd を同じような動作をする。 % LD_TRACE_LOADED_OBJECTS=1 ./hello libc.so.6 => /lib/libc.so.6 (0x4001c000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) process_envvars()の処理の後は /lib/ld-2.3.1.so を直接呼びだした時の 処理がされている。 % /lib/ld-2.3.1.so Usage: ld.so [OPTION]... EXECUTABLE-FILE [ARGS-FOR-PROGRAM...] You have invoked `ld.so', the helper program for shared library executables. This program usually lives in the file `/lib/ld.so', and special directives in executable files using ELF shared libraries tell the system's program loader to load the helper program from this file. This helper program loads the shared libraries needed by the program executable, prepares the program to run, and runs it. You may invoke this helper program directly from the command line to load and run an ELF executable file; this is like executing that file itself, but always uses this helper program from the file you specified, instead of the helper program file specified in the executable file you run. This is mostly of use for maintainers to test new versions of this helper program; chances are you did not intend to run this program. --list list all dependencies and how they are resolved --verify verify that given object really is a dynamically linked object we can handle --library-path PATH use given PATH instead of content of the environment variable LD_LIBRARY_PATH --inhibit-rpath LIST ignore RUNPATH and RPATH information in object names in LIST たとえば --list オプションは ldd のような動作をする。 % /lib/ld-2.3.1.so --list ./hello libc.so.6 => /lib/libc.so.6 (0x4000a000) /lib/ld-linux.so.2 => /lib/ld-2.3.1.so (0x80000000) もしくは次のようにすると普通に実行することもできる。 % /lib/ld-2.3.1.so ./hello hello, world preloadlist != NULL のチェックをして LD_PRELOAD の処理をしている。その次に/etc/ld.so.preloadを見ておなじくpreloadの処理をする。 preloadのを処理をしてからDT_NEEDEDとされているshared libsの処理をおこなう。objdump -p で Dynamic Secion (動的セクション)で NEEDED になっている shared libs である。 % objdump -p ./hello (略) 動的セクション: NEEDED libc.so.6 INIT 0x80482bc FINI 0x804847c (略) つまりこの場合は libc.so.6 をリンクする。 最終的に dl_main で user_entry にプログラムの開始アドレスが設定され、それが _dl_sysdep_start()のreturn valueとなって start_addr になり start_addr = _dl_sysdep_start (arg, &dl_main); これが _dl_start_final()の return value となる。 ElfW(Addr) entry = _dl_start_final (arg, &info); この後 ELF_DYNAMIC_RELOCATE (&bootstrap_map, 0, 0); で _GLOBAL_OFFSET_TABLE_ に対して設定をしている。これはelf/dynamic-link.hで#defineされており、この中でsysdeps/i386/dl-machine.hのelf_machine_runtime_setup()がそれをしている。これについては後に説明する。 さて entry はその後 return ELF_MACHINE_START_ADDRESS (GL(dl_loaded), entry); でさらに _dl_start()のreturn valueとなって sysdeps/i386/dl-machine.h のRTLD_STARTのコードに続き _dl_start_user()にくる。GOTなどを設定し、最終的に call _dl_start\n\ _dl_start_user:\n\ # Save the user entry point address in %edi.\n\ movl %eax, %edi\n\ (略) # Jump to the user's entry point.\n\ jmp *%edi\n\ で _dl_start()からのreturn valueのアドレスへjumpしユーザのプログラムの実行が開始される。 hello: ファイル形式 elf32-i386 hello アーキテクチャ: i386, フラグ 0x00000112: EXEC_P, HAS_SYMS, D_PAGED 開始アドレス 0x08048340 なので開始アドレスが 0x08048340 なので 08048340 g F .text 00000000 _start で _start から実行が開始される。 08048340 <_start>: 8048340: 31 ed xor %ebp,%ebp 8048342: 5e pop %esi 8048343: 89 e1 mov %esp,%ecx 8048345: 83 e4 f0 and $0xfffffff0,%esp 8048348: 50 push %eax 8048349: 54 push %esp 804834a: 52 push %edx 804834b: 68 7c 84 04 08 push $0x804847c 8048350: 68 bc 82 04 08 push $0x80482bc 8048355: 51 push %ecx 8048356: 56 push %esi 8048357: 68 20 84 04 08 push $0x8048420 804835c: e8 a3 ff ff ff call 8048304 <_init+0x48> 8048361: f4 hlt 8048362: 90 nop 8048363: 90 nop stackに引数をpushしていって 804835c: e8 a3 ff ff ff call 8048304 <_init+0x48> で 8048304: ff 25 b4 95 04 08 jmp *0x80495b4 ここで、0x80485a0〜が _GLOBAL_OFFSET_TABLE_ なのでこれを参照して 080495a0 <_GLOBAL_OFFSET_TABLE_>: 080495b4 が 0a 83 04 08 なので 0804830a に jmp 804830a: 68 10 00 00 00 push $0x10 804830f: e9 c0 ff ff ff jmp 80482d4 <_init+0x18> ちなみにこのあたりは gdb をつかってみると (gdb) disassemble 0x804830a Dump of assembler code for function __libc_start_main: 0x8048304 <__libc_start_main>: jmp *0x80495b4 0x804830a <__libc_start_main+6>: push $0x10 0x804830f <__libc_start_main+11>: jmp 0x80482d4 <_init+24> End of assembler dump. と __libc_start_main である。ちなみにこのあたりはセクション.pltで ここを disassemble してみると 0x80482e4 <__register_frame_info>: jmp *0x80495ac 0x80482ea <__register_frame_info+6>: push $0x0 0x80482ef <__register_frame_info+11>: jmp 0x80482d4 <_init+24> 0x80482f4 <__deregister_frame_info>: jmp *0x80495b0 0x80482fa <__deregister_frame_info+6>: push $0x8 0x80482ff <__deregister_frame_info+11>: jmp 0x80482d4 <_init+24> 0x8048304 <__libc_start_main>: jmp *0x80495b4 0x804830a <__libc_start_main+6>: push $0x10 0x804830f <__libc_start_main+11>: jmp 0x80482d4 <_init+24> 0x8048314 : jmp *0x80495b8 0x804831a : push $0x18 0x804831f : jmp 0x80482d4 <_init+24> 0x8048324 : jmp *0x80495bc 0x804832a : push $0x20 0x804832f : jmp 0x80482d4 <_init+24> のようになっている。ここはどうなっているかを簡単に説明しよう。 まず_GLOBAL_OFFSET_TABLE_にsymbolがresolvされたアドレスがはいることになっている。0x80495b4に格納されるアドレスがさしているのが __libc_start_mainの実体となる。ただし最初はまだマップされていないので、その場合は 0x804830a をさしている。ここにくると push $0x10 して jmp 0x80482d4 である。0x80482d4ではなにをしているかというと 80482d4: ff 35 a4 95 04 08 pushl 0x80495a4 80482da: ff 25 a8 95 04 08 jmp *0x80495a8 である。ここで 0x80495a8 は _GLOBAL_OFFSET_TABLE_ が 080495a0 なので _GLOBAL_OFFSET_TABLE_[2] に相当している。ここには実は sysdeps/i386/dl-machine.h の elf_machine_runtime_setup() により got[1] = (Elf32_Addr) l; /* Identify this shared object. */ got[2] = (Elf32_Addr) &_dl_runtime_resolve; のような値が代入される。つまり jmp *0x80495a8 で _dl_runtime_resolve()を呼ぶことになる。_dl_runtime_resolv は sysdeps/i386/dl-machine.h にありelf/dl-runtime.c の fixup()を呼ぶ。fixup()がshared libsとのsymbolのresolveをおこなって、この場合は __libc_start_main() を libc.so.6 の中のルーチンを差すようにアドレスを_GLOBAL_OFFSET_TABLE_ に登録する。そうすることでまた同じルーチンを呼ぶときは 0x8048304 <__libc_start_main>: jmp *0x80495b4 で 0x80495b4に書かれているアドレスが本当のルーチンへのアドレスになっているのでresolveする必要もなくそこにjmpするようになる。__libc_start_main()の実体はlibc.so.6 で これは sysdeps/generic/libc-start.c の中にある。そしていろいろ処理をした後最終的に result = main (argc, argv, __environ); で main()を呼ぶことになる。これでようやく int main(int argc, char *argv[]) { printf("hello, world\n"); exit(0); } まできたことになる。あとはこれを実行である。もちろん printf や exit などは__libc_start_main()で説明したようなfixupがおこなわれてlibc.so.6とlinkされてそれらが実行されるという処理がおこなわれる。最後に exit (result); で exit処理をする。exit()もsystem callであるからexecve()の時のようにsysdeps/unix/sysv/linux/_exit.cの INLINE_SYSCALL (exit, 1, status); により system call 1 (__NR_exit) がよびだされ ENTRY(sys_call_table) .long SYMBOL_NAME(sys_ni_syscall) /* 0 - old "setup()" system ca ll*/ .long SYMBOL_NAME(sys_exit) から kernel/exit.c の asmlinkage long sys_exit(int error_code)からprocessがもっていたresourceの解放をしてreschedule()して他のプロセスに処理をわたしておわりである。あとは親プロセスが waitで tsk->exit_code にのこっている終了コードをひろってもらえるまで zombie 状態となっているのである。これでプロセスの一生がおわりである。この原稿もここでおしまい。 おまけ: yaegashi先生からreadelf(1)は使わないのか という指摘があったけれども、もう遅いのでかきなおすのはやめておきます。readelf(1)もつかっていろいろ遊んでみるのは宿題にしておきましょう:-)