/**************************************************/ 제목: 프로그램 실행 시 메모리 구도 원제: Memory Layout in Program Execution 저자: Fr??ick Giasson(fred@decatomb.com) 번역 및 편집: vangelis(vangelis@wowhacker.org) 발표일: October 2001 /*************************************************/ # 오늘부터 시간 나는대로 이 글 올립니다. 일부분은 저가 편집하기도 하는데 혹시라도 문제가 있다면 원문을 참고하시기 바랍니다. ## 이번 게시물은 차례와 본문에서 나오는 소스 코드들입니다. :: 목 차 :: 서문 도입 1장 1. 프로그램 실행: route map 1.1. pseudo-shell 쉘 코드 1.2. 자식 프로세스 만들기 1.2.1. FORKS 시스템 호출: 9 단계 1.3. 프로그램 실행 1.3.1. C 실시간, 시작(start-off) 절차 1.3.2. EXEC 시스템 호출, 9 단계 2장 2. 실행된 프로그램의 메모리 배치 2.1. ELF 실행 파일 해부 3장 3. 스택과 힙 3.1. 위치 3.2. 컴파일시 사용자 스택 프레임의 크기는 어떻게 알 수 있는가? 3.3. 레지스터 3.3.1. 일반 레지스터 3.3.2. 세그먼트 레지스터 3.3.3. 오프셋 레지스터 3.4. 스택 3.4.2. 프로시저 호출 동안 스택 관리 3.4.2.1. 호출 3.4.2.2. 프롤로그 3.4.2.3. 리턴 3.5. 힙 결론 Annex 1 Annex 2 Annex 3 참고문헌 Annex 1 : --------- do_fork() - Function Code - src/mm/forkexit.c --------------------------------------------- /*===========================================================================* * do_fork * *===========================================================================*/ 01 PUBLIC int do_fork() 02 { 03 /* The process pointed to by 'mp' has forked. Create a child process. */ 04 05 register struct mproc *rmp; /* pointer to parent */ 06 register struct mproc *rmc; /* pointer to child */ 07 int i, child_nr, t; 08 phys_clicks prog_clicks, child_base = 0; 09 phys_bytes prog_bytes, parent_abs, child_abs; /* Intel only */ 10 11 /* If tables might fill up during FORK, don't even start since recovery half 12 * way through is such a nuisance. 13 */ 14 rmp = mp; 15 if (procs_in_use == NR_PROCS) return(EAGAIN); 16 if (procs_in_use >= NR_PROCS-LAST_FEW && rmp->mp_effuid != 0)return(EAGAIN); 17 18 /* Determine how much memory to allocate. Only the data and stack need to 19 * be copied, because the text segment is either shared or of zero length. 20 */ 21 prog_clicks = (phys_clicks) rmp->mp_seg[S].mem_len; 22 prog_clicks += (rmp->mp_seg[S].mem_vir - rmp->mp_seg[D].mem_vir); 23 #if (SHADOWING == 0) 24 prog_bytes = (phys_bytes) prog_clicks << CLICK_SHIFT; 25 #endif 26 if ( (child_base = alloc_mem(prog_clicks)) == NO_MEM) return(ENOMEM); 27 28 #if (SHADOWING == 0) 29 /* Create a copy of the parent's core image for the child. */ 30 child_abs = (phys_bytes) child_base << CLICK_SHIFT; 31 parent_abs = (phys_bytes) rmp->mp_seg[D].mem_phys << CLICK_SHIFT; 32 i = sys_copy(ABS, 0, parent_abs, ABS, 0, child_abs, prog_bytes); 33 if (i < 0) panic("do_fork can't copy", i); 34 #endif 35 36 /* Find a slot in 'mproc' for the child process. A slot must exist. */ 37 for (rmc = &mproc[0]; rmc < &mproc[NR_PROCS]; rmc++) 38 if ( (rmc->mp_flags & IN_USE) == 0) break; 39 40 /* Set up the child and its memory map; copy its 'mproc' slot from parent. */ 41 child_nr = (int)(rmc - mproc); /* slot number of the child */ 42 procs_in_use++; 43 *rmc = *rmp; /* copy parent's process slot to child's */ 44 45 rmc->mp_parent = who; /* record child's parent */ 46 rmc->mp_flags &= ~TRACED; /* child does not inherit trace status */ 47 #if (SHADOWING == 0) 48 /* A separate I&D child keeps the parents text segment. The data and stack 49 * segments must refer to the new copy. 50 */ 51 if (!(rmc->mp_flags & SEPARATE)) rmc->mp_seg[T].mem_phys = child_base; 52 rmc->mp_seg[D].mem_phys = child_base; 53 rmc->mp_seg[S].mem_phys = rmc->mp_seg[D].mem_phys + 54 (rmp->mp_seg[S].mem_vir - rmp->mp_seg[D].mem_vir); 55 #endif 56 rmc->mp_exitstatus = 0; 57 rmc->mp_sigstatus = 0; 58 59 /* Find a free pid for the child and put it in the table. */ 60 do { 61 t = 0; /* 't' = 0 means pid still free */ 62 next_pid = (next_pid < 30000 ? next_pid + 1 : INIT_PID + 1); 63 for (rmp = &mproc[0]; rmp < &mproc[NR_PROCS]; rmp++) 64 if (rmp->mp_pid == next_pid || rmp->mp_procgrp == next_pid) { 65 t = 1; 66 break; 67 } 68 rmc->mp_pid = next_pid; /* assign pid to child */ 69 } while (t); 70 /* Tell kernel and file system about the (now successful) FORK. */ 71 sys_fork(who, child_nr, rmc->mp_pid, child_base); /* child_base is 68K only*/ 72 tell_fs(FORK, who, child_nr, rmc->mp_pid); 73 74 #if (SHADOWING == 0) 75 /* Report child's memory map to kernel. */ 76 sys_newmap(child_nr, rmc->mp_seg); 77 #endif 78 79 /* Reply to child to wake it up. */ 80 reply(child_nr, 0, 0, NIL_PTR); 81 return(next_pid); /* child's pid */ 82 } ------ Annex 2 : --------- Process Table definition - src/kernel/proc.h -------------------------------------------- struct proc { struct stackframe_s p_reg; /* process' registers saved in stack frame */ #if (CHIP == INTEL) reg_t p_ldt_sel; /* selector in gdt giving ldt base and limit*/ struct segdesc_s p_ldt[2]; /* local descriptors for code and data */ /* 2 is LDT_SIZE - avoid include protect.h */ #endif /* (CHIP == INTEL) */ #if (CHIP == M68000) reg_t p_splow; /* lowest observed stack value */ int p_trap; /* trap type (only low byte) */ #if (SHADOWING == 0) char *p_crp; /* mmu table pointer (really struct _rpr *) */ #else phys_clicks p_shadow; /* set if shadowed process image */ int align; /* make the struct size a multiple of 4 */ #endif int p_nflips; /* statistics */ char p_physio; /* cannot be (un)shadowed now if set */ #if defined(FPP) struct fsave p_fsave; /* FPP state frame and registers */ int align2; /* make the struct size a multiple of 4 */ #endif #endif /* (CHIP == M68000) */ reg_t *p_stguard; /* stack guard word */ int p_nr; /* number of this process (for fast access) */ int p_int_blocked; /* nonzero if int msg blocked by busy task */ int p_int_held; /* nonzero if int msg held by busy syscall */ struct proc *p_nextheld; /* next in chain of held-up int processes */ int p_flags; /* P_SLOT_FREE, SENDING, RECEIVING, etc. */ struct mem_map p_map[NR_SEGS];/* memory map */ pid_t p_pid; /* process id passed in from MM */ clock_t user_time; /* user time in ticks */ clock_t sys_time; /* sys time in ticks */ clock_t child_utime; /* cumulative user time of children */ clock_t child_stime; /* cumulative sys time of children */ clock_t p_alarm; /* time of next alarm in ticks, or 0 */ struct proc *p_callerq; /* head of list of procs wishing to send */ struct proc *p_sendlink; /* link to next proc wishing to send */ message *p_messbuf; /* pointer to message buffer */ int p_getfrom; /* from whom does process want to receive? */ int p_sendto; struct proc *p_nextready; /* pointer to next ready process */ sigset_t p_pending; /* bit map for pending signals */ unsigned p_pendcount; /* count of pending and unfinished signals */ char p_name[16]; /* name of the process */ }; ------ Annex 3: -------- 001 /*===========================================================================* 002 * do_exec * 003 *===========================================================================*/ 004 PUBLIC int do_exec() 005 { 006 /* Perform the execve(name, argv, envp) call. The user library builds a 007 * complete stack image, including pointers, args, environ, etc. The stack 008 * is copied to a buffer inside MM, and then to the new core image. 009 */ 010 011 register struct mproc *rmp; 012 struct mproc *sh_mp; 013 int m, r, fd, ft, sn; 014 static char mbuf[ARG_MAX]; /* buffer for stack and zeroes */ 015 static char name_buf[PATH_MAX]; /* the name of the file to exec */ 016 char *new_sp, *basename; 017 vir_bytes src, dst, text_bytes, data_bytes, bss_bytes, stk_bytes, vsp; 018 phys_bytes tot_bytes; /* total space for program, including gap */ 019 long sym_bytes; 020 vir_clicks sc; 021 struct stat s_buf; 022 vir_bytes pc; 023 /* Do some validity checks. */ 024 rmp = mp; 025 stk_bytes = (vir_bytes) stack_bytes; 026 if (stk_bytes > ARG_MAX) return(ENOMEM); /* stack too big */ 027 if (exec_len <= 0 || exec_len > PATH_MAX) return(EINVAL); 028 029 /* Get the exec file name and see if the file is executable. */ 030 src = (vir_bytes) exec_name; 031 dst = (vir_bytes) name_buf; 032 r = sys_copy(who, D, (phys_bytes) src, 033 MM_PROC_NR, D, (phys_bytes) dst, (phys_bytes) exec_len); 034 if (r != OK) return(r); /* file name not in user data segment */ 035 tell_fs(CHDIR, who, FALSE, 0); /* switch to the user's FS environ. */ 036 fd = allowed(name_buf, &s_buf, X_BIT); /* is file executable? */ 037 if (fd < 0) return(fd); /* file was not executable */ 038 039 /* Read the file header and extract the segment sizes. */ 040 sc = (stk_bytes + CLICK_SIZE - 1) >> CLICK_SHIFT; 041 m = read_header(fd, &ft, &text_bytes, &data_bytes, &bss_bytes, 042 &tot_bytes, &sym_bytes, sc, &pc); 043 if (m < 0) { 044 close(fd); /* something wrong with header */ 045 return(ENOEXEC); 046 } 047 048 /* Fetch the stack from the user before destroying the old core image. */ 049 src = (vir_bytes) stack_ptr; 050 dst = (vir_bytes) mbuf; 051 r = sys_copy(who, D, (phys_bytes) src, 052 MM_PROC_NR, D, (phys_bytes) dst, (phys_bytes)stk_bytes); 053 if (r != OK) { 054 close(fd); /* can't fetch stack (e.g. bad virtual addr) */ 055 return(EACCES); 056 } 057 058 /* Can the process' text be shared with that of one already running? */ 059 sh_mp = find_share(rmp, s_buf.st_ino, s_buf.st_dev, s_buf.st_ctime); 060 061 /* Allocate new memory and release old memory. Fix map and tell kernel. */ 062 r = new_mem(sh_mp, text_bytes, data_bytes, bss_bytes, stk_bytes, tot_bytes); 063 if (r != OK) { 064 close(fd); /* insufficient core or program too big */ 065 return(r); 066 } 067 068 /* Save file identification to allow it to be shared. */ 069 rmp->mp_ino = s_buf.st_ino; 070 rmp->mp_dev = s_buf.st_dev; 071 rmp->mp_ctime = s_buf.st_ctime; 072 073 /* Patch up stack and copy it from MM to new core image. */ 074 vsp = (vir_bytes) rmp->mp_seg[S].mem_vir << CLICK_SHIFT; 075 vsp += (vir_bytes) rmp->mp_seg[S].mem_len << CLICK_SHIFT; 076 vsp -= stk_bytes; 077 patch_ptr(mbuf, vsp); 078 src = (vir_bytes) mbuf; 079 r = sys_copy(MM_PROC_NR, D, (phys_bytes) src, 080 who, D, (phys_bytes) vsp, (phys_bytes)stk_bytes); 081 if (r != OK) panic("do_exec stack copy err", NO_NUM); 082 083 /* Read in text and data segments. */ 084 if (sh_mp != NULL) { 085 lseek(fd, (off_t) text_bytes, SEEK_CUR); /* shared: skip text */ 086 } else { 087 load_seg(fd, T, text_bytes); 088 } 089 load_seg(fd, D, data_bytes); 090 091 #if (SHADOWING == 1) 092 if (lseek(fd, (off_t)sym_bytes, SEEK_CUR) == (off_t) -1) ; /* error */ 093 if (relocate(fd, (unsigned char *)mbuf) < 0) ; /* error */ 094 pc += (vir_bytes) rp->mp_seg[T].mem_vir << CLICK_SHIFT; 095 #endif 096 097 close(fd); /* don't need exec file any more */ 098 099 /* Take care of setuid/setgid bits. */ 100 if ((rmp->mp_flags & TRACED) == 0) { /* suppress if tracing */ 101 if (s_buf.st_mode & I_SET_UID_BIT) { 102 rmp->mp_effuid = s_buf.st_uid; 103 tell_fs(SETUID,who, (int)rmp->mp_realuid, (int)rmp->mp_effuid); 104 } 105 if (s_buf.st_mode & I_SET_GID_BIT) { 106 rmp->mp_effgid = s_buf.st_gid; 107 tell_fs(SETGID,who, (int)rmp->mp_realgid, (int)rmp->mp_effgid); 108 } 109 } 110 111 * Save offset to initial argc (for ps) */ 112 rmp->mp_procargs = vsp; 113 114 /* Fix 'mproc' fields, tell kernel that exec is done, reset caught sigs. */ 115 for (sn = 1; sn <= _NSIG; sn++) { 116 if (sigismember(&rmp->mp_catch, sn)) { 117 sigdelset(&rmp->mp_catch, sn); 118 rmp->mp_sigact[sn].sa_handler = SIG_DFL; 119 sigemptyset(&rmp->mp_sigact[sn].sa_mask); 120 } 121 } 122 123 rmp->mp_flags &= ~SEPARATE; /* turn off SEPARATE bit */ 124 rmp->mp_flags |= ft; /* turn it on for separate I & D files */ 125 new_sp = (char *) vsp; 126 127 tell_fs(EXEC, who, 0, 0); /* allow FS to handle FD_CLOEXEC files */ 128 129 /* System will save command line for debugging, ps(1) output, etc. */ 130 basename = strrchr(name_buf, '/'); 131 if (basename == NULL) basename = name_buf; else basename++; 132 sys_exec(who, new_sp, rmp->mp_flags & TRACED, basename, pc); 133 return(OK); 134 } /**************************************************/ 제목: 프로그램 실행 시 메모리 구도 원제: Memory Layout in Program Execution 저자: Fr??ick Giasson(fred@decatomb.com) 번역 및 편집: vangelis(vangelis@wowhacker.org) 발표일: October 2001 /*************************************************/ 서 문 이 글은 웹 상에 발표한 나의 첫 번째 글이다. 이 글은 초보자, 시스템 관리자, 프로그래머, 커널 개발자, 취미로 공부하는 사람, 또는 다른 컴퓨터를 좋아하는 사람들을 위한 것이다. 영어가 많이 부족하니 만일 문법상 문제가 있다면 지적해주길 바란다. 기꺼이 고치도록 하겠다. 만약 여러분들이 이 글에 대해서 나와 그리고 다른 사람들과 토론하기를 원한다면 다음을 이용하길 바란다. - http://www.decatomb.com/forums/viewforum.php?forum=29 도 입 메모리 관리는 운영체제 개발에서 뜨거운 주제이다. 이것은 시스템의 중요한 자원이며, 주의 깊게 관리될 필요가 있다. 이 글은 메모리 관리 시스템 전체 과정을 다루지는 않을 것이다. 아니, 우리는 이 메모리 관리 시스템에서 사용자의 관점을 알아볼 것이다. 우리는 어떻게 어떤 프로그램 파일이 실행되고, 메모리 속으로 맵핑되는지 알아볼 것이다. 메모리 관리 시스템에는 스와핑(swapping), 가상 메모리(virtual memory), 페이지 대체 알고리즘(page replacement algorithm), 세그멘테이션(segmentation) 등등의 많은 다른 부분들이 있다. 그래서 만약 운여체제에서 메모리 관리 시스템의 전 프로세스를 이해하고자 원한다면 이 문서 뒷부분에 나오는 참고문헌들을 보아라. Linux/Unix 그리고 Minix의 메모리 관리 시스템에 대한 많은 유용한 자료들이 있다. 나는 이 프로세스가 어떻게 작동하는지 설명하기 위해 Minix/Linux 메모리 관리 시스템을 사용할 것이다. 이것은 실제 NetBSD, FreeBSD 등의 다른 ELF 기반의 A-32 운영체제와 같은 스키마이다. 이 문서에서 제시되는 예제 프로그램들은 LInux에서 gcc로 컴파일되며, 어셈블리 코드를 디버그 하기 위해 GDB를 사용할 것이다. 1장 ? 프로그램 실행: 라우터 맵(route map) 어떻게 실행된 프로그램이 메모리에 맵핑 되는지 아는 것은 흥미롭다. 그런데 어떻게 실행되는 것일까? 이 글의 첫 부분에서 나는 어떤 프로그램의 전체 실행 과정이 작용하는지 라우터 맵을 추적함으로서 이야기할 것이다. 출발점은 사용자가 프로그램의 이름을 쉘에 타이핑한 후 를 치면서부터이다. 라우터의 마지막 단계는 프로그램이 메모리에 적재되고 시작될 준비가 되었을 때이다. [Root@Seldon prog]# helloworld < Enter > Hello World! 나는 실행하고자 하는 프로그램 ‘helloworld’의 이름을 타이핑하여 엔터 키를 눌렀다. 내가 엔터 키를 눌렀을 때와 “Hello World!’라는 문자열이 콘솔 화면에 나왔을 때 사이에 무엇이 추가되었는가? 이것은 마술인가? 분명 아니다. 1.1. pseudo-shell 코드 다음은 아주 기본적인 쉘 프로그램의 pseudo-shell 코드이다. #define TRUE 1 ARRAY command ARRAY parameters while(TRUE) { read_command_line(command,parameters); /* 터미널로부터 입력된 것을 읽기 위해 기다림 */ /* 우리의 예에서는, command = "helloworld" */ /* parameters = "" */ pid_t = fork(); /* pid_t는 자식 프로세스의 프로세스 ID를 포함하고 있음 */ if( pid_t != 0 ) /* 만약 PID가 0이 아니라면 그때는... */ { /* Note: PID가 실행의 자식 쓰레드일 때 PID == 0 */ /* Parent code. */ waitpid(-1,&status,0); /* 프로그램은 부모 프로세스를 지속하기 위해 */ /* 자식 프로세스의 실행(-1)의 끝을 기다리고 있음 */ }else{ /* Child Code. */ execve(command,parameters,0); /* 마지막으로, helloworld 프로그램을 실행 */ } } Note 1: execve() 함수는 자식 프로세스(fork() == 0일 때)에서 호출되며, waitpid() 명령은 부모 프로세스(fork() == pid_t 일 때)에서 호출된다. 이해가 되지 않는가? 걱정하지 마라. 나는 이 가짜 쉘 코드의 모든 부분을 아래에서 설명할 것이다. 1.2. 자식 프로세스 만들기 먼저, 프로그램은 우리의 프로그램의 실행을 통제하기 위해 새로운 프로세스를 만들 필요가 있다. 이것을 Minix 그리고 Linux에서 하는 방법들이 있다. Minix: ------ do_fork() Linux: ------ fork() vfork() clone() Linux에서 vfork()와 clone()은 fork()와 같은 기능을 가지고 있지만 프로세스를 관리하는데 있어서는 몇 가지 차이점이 있다. 이 두 함수에 대한 더 많은 정보는 linux 맨페이지를 참고해라. 우리는 fork() 함수에 노력의 초점을 맞출 것이다. fork() 함수는 Minix와 linux에서 같은 일을 한다. 이 함수는 모든 파일 기술, 변수, 레지스터 등을 포함하여 부모 프로세스를 정확하게 복사한다. fork()가 호출된 후 자식 및 부모 프로세스는 분리된 방식을 취한다. 모든 변수들의 값은 fork() 호출 시에는 같으나, 이후는 부모 및 자식 변수의 값은 변할 것이고, 부모 프로세스에서 실행된 것들은 자식 프로세스에서 실행된 것에 영향을 주지 않을 것이다. 부모 및 자식 프로세스 사이에 공유되는 유일한 것은 변경될 수 없는 텍스트 섹션이다. FORK 시스템 호출이 보내지면 자식 프로세스가 만들어진다. 이제 fork() 함수가 끝나기 전에 시스템 호출은 프로그램에 자식 프로세스 확인(PID) 값을 리턴할 것이다. PID는 types.h에 다음과 같이 정의된 정수 변수이다. Note 1: fork() 프로시저는 FORK 시스템 호출을 보낼 것이다. 이 두 개념에 대해 혼동하지 말기를 바란다. ------ Minix:Source: minix/include/sys/types.h -- typedef int pid_t; Linux:Source: /posix/sys/types.h -- ifndef __pid_t_defined typedef int __pid_t pid_t; ------ 1.2.1. FORK 시스템 호출: 9 단계 FORK 시스템 호출이 하는 9단계가 있다. Note 1: Annex 1에 나와 있는 do_fork() 소스 코드에 이 9 단계의 모든 것을 볼 수 있다. Note 2: 리눅스 fork() 함수 코드는 fork.c 파일의 glibc에 있다. Note 3: 다음에 기술된 단계는 Minix에만 적용 가능하며, 리눅스의 경우 기본적인 것은 같다. 실제 다른 것은 프로세스가 커널에 의해 어떻게 만들어지는가이다. 1- 프로세스 테이블이 가득 차 있는지 확인(Annex 1에서 14~16 라인) 프로세스 테이블이란 무엇인가? 프로세스 테이블은 커널의 일부이다. 테이블의 선언은 Annex2에 있다. 이 테이블은 모든 프로세스의 레지스터, 메모리 맵, 계산, 받고 보낸 메시지 등을 포함하고 있다. Note 1: 프로세스 테이블에서 슬롯의 수는 " /include/minix/config.h "에 있는 NR_PROCS에 의해 정의되어 있다. ------ #define NR_PROCS 32 ------ Note 2: Linux에서 프로세스의 최대 수는 태스크 벡터의 크기이며, 디폴트로 512개의 항목을 가지고 있다. 2- 자식 프로세스의 데이터와 스택을 위해 메모리 할당 (Annex 1에서 21 ~ 26 라인) 3- 부모 프로세스의 데이터와 스택을 자식 프로세스의 메모리에 복사 (28 ~34 라인) 4- 여유 있는 프로세스의 슬롯을 찾아 그것에 부모 프로세스의 슬롯을 복사 (36 ~38 라인) 5- 프로세스 테이블에 자식 프로세스의 메모리 맵을 입력 (41~57 라인) 6- 자식 프로세스를 위한 pid 선택 (60 ~69 라인) Note 1: pid_t는 signed 정수라는 것을 기억할 것. 7- 자식 프로세스에 대해 커널과 파일 시스템에 이야기 (71~72 라인) 왜 fork 시스템 호출은 커널과 파일 시스템에 새로 만들어진 프로세스에 대해 ‘이야기’ 하는가? 이유는 Minix에서 프로세스 관리, 메모리 관리, 그리고 파일 관리는 각각 분리된 모듈에 의해 조작되기 때문이다. 그래서 프로세스 테이블은 3 부분으로 나누어져 있으며, 그리고 이 부분의 각각은 그것이 필요로 하는 필더를 가지고 있다. 메모리 관리에서 포함된 프로세스 테이블의 부분은 “/src/mm/mproc.h” 파일에 정의되어 있다. 파일 시스템에 포함된 부분은 “/src/fs/frpoc.h” 파일에 정의되어 있다. 마지막으로 커널에 포함된 것은 Annex 2에 정의되어 있다. 8- 자식 프로세스의 메모리 맵을 커널에 보고한다. (Annex 1에서 라인 74~77) 9- 응답 메시지를 부모 및 자식 프로세스에 보낸다. (Annex 1에서 라인 80~81) Note 1: 자식 프로세스에 대한 리턴 값은 0이며, 부모 프로세스에 대한 리턴 값은 그 자식 프로세스의 PID이다. 우리가 볼 수 있듯이, 쉘로부터 호출된 어떤 프로그램 실행의 첫 부분은 그렇게 간단하지 않다. Fork 시스템 호출은 execve() 명령에 의해 시작된 새로운 프로그램의 실행을 통제하기 위해 새로운 프로세스를 단지 만들 뿐이다.그래서, 프로세스 관리의 전체 프로토콜은 우리가 do_fork() 프로시저를 호출할 때 포함된다. 이 글에서는 이 프로토콜에 대해서는 다루지 않는다. 왜냐하면 이 글의 목적이 아니기 때문이다. 1.3: 프로그램 실행 우리는 새로운 프로세스를 만들었고, 프로그램을 실행하기 위해 이 프로세스를 사용할 것이다. execve() 함수는 "EXEC system call"로 알려진 새로운 시스템 호출을 호출할 것이다. 이 시스템 호출은 무엇을 하는가? 이것은 현재의 메모리 이미지를 새로운 것으로 대체하고, 이 새로운 메모리 이미지를 위해 새로운 스택을 설정한다. 아래는 Minix와 리눅스에서 프로그램을 실행하는 방법이다. Minix: ------ do_exec() Note 1: /src/mm/exec.c 라이브러리에서. /src/fs/misc.c 와 /src/kernel/system.c 라이브러리에는 다른 do_exec() 함수들이 있지만 이것들에 대해서는 나중에 이야기 하겠다. Linux: ------ execve() exec 계열 프로시저들의 다른 변종들도 있는데, 더 많은 정보는 맨 페이지를 참고해라: execl() execlp() execle() execv() execvp() 자, 우리는 메모리에 우리의 새로운 이미지의 크기의 홀이 있다는 것을 고려할 것이다. 나는 먼저 어떻게 이 프로그램이 exec 시스템 호출에 의해 통제되고, 후에 do_exec() 함수가 수행하는 모든 단계를 보여줄 것이다. Fork 시스템 호출과 마찬가지로 다음 설명은 Minix 운영체제에 대해서도 완전히 호환되며, 하지만 기본적인 것은 Linux에서도 마찬가지다. exec 시스템 호출의 통제는 같으며, 리눅스 하에서는 커널, MM, FS는 리눅스 시스템에만 적용되는 많은 다른 기능으로 다른 방식으로 그 문제를 통제할 수 있으며, 하지만 프로세스는 같다. 우리가 “mv hw pg” 명령을 쉘에 건네줄 때 exec의 전체 프로세스를 이해하기 위해 사용할 메모리 구조가 있다. Note 1: 미 명령은 “hw” 파일을 “pr”로 이름을 변경할 것이다. execve()에 건네진 배열 ------------------ 인자 배열 --------------- | 0 | |---------------| | pr | |---------------| | hw | |---------------| | mv | --------------- 표1.0 환경 변수 배열 --------------- | 0 | |---------------| | HOME=/root | --------------- 표1.1 execve()에 의한 스택 빌드: ------------------------- 3 2 1 0 --------------- 40 | \0| t | o | o | |---------------| 36 | r | / | = | E | |---------------| 32 | M | O | H | \0| |---------------| 28 | r | p | \0| w | |---------------| 24 | h | \0| v | m | |---------------| 20 | 0 | |---------------| 16 | 33 | |---------------| 12 | 0 | |---------------| 8 | 30 | |---------------| 4 | 27 | |---------------| 0 | 24 | --------------- 표 1.2 메모리 관리자에 의해 재 할당 후 스택: ------------------------------------ 3 2 1 0 --------------- 6532 | \0| t | o | o | |---------------| 6528 | r | / | = | E | |---------------| 6524 | M | O | H | \0| |---------------| 6520 | r | p | \0| w | |---------------| 6516 | h | \0| v | m | |---------------| 6512 | 0 | |---------------| 6508 | 6525 | |---------------| 6504 | 0 | |---------------| 6500 | 6522 | |---------------| 6496 | 6519 | |---------------| 6492 | 6516 | --------------- 표1.3 실행 시 main()에 나타난 스택: ----------------------------- 3 2 1 0 --------------- 6532 | \0| t | o | o | |---------------| 6528 | r | / | = | E | |---------------| 6524 | M | O | H | \0| |---------------| 6520 | r | p | \0| w | |---------------| 6516 | h | \0| v | m | |---------------| 6512 | 0 | |---------------| 6508 | 6525 | |---------------| 6504 | 0 | |---------------| 6500 | 6522 | |---------------| 6496 | 6519 | |---------------| 6492 | 6516 | |---------------| 6488 | 6508 | <-- envp |---------------| 6484 | 6492 | <-- argv |---------------| 6480 | 3 | <-- argc |---------------| 6476 | return | --------------- 표1.4 나는 이 스택 구현들이 어떻게 작용하는지, 그런 후 메모리에 프로그램이 적재시키기 위해 exec 시스템 호출 단계를 제시할 것이다. Exec 프로세스에는 두 가지 중요한 배열이 있다. 그것은 environment array(표1.0)와 argument array(표 1.1)이다. environment array은 문자열 배열이며, 그것은 environment로써 새로운 프로그램으로 전달된다. argument array는 새로운 프로그램으로 건네진 인자 문자열의 배열이다. 이 두 배열은 NULL 문자(“\0”)로 끝날 필요가 있다. do_exec() 프로시저는 이제 쉘의 주소 공간 내에 초기 스택을 마련할 것이다.(표 1.2, Annex 3의 라인 049-059). 다음으로, 그 프로시저는 MM을 호출하고, 이것은 새로 만들어진 스택을 위해 새로 메모리를 할당하고, 이전 것을 내놓는다.(Annex 3에서 라인 062-066) 그 프로시저가 포인터들(Annex 라인 077)을 수정하면 메모리는 이제 표 1.2로부터 표 1.3의 메모리 모양을 가지게 된다. 마지막으로, 우리는 초기 argc(Annex 3에서 라인 113)에 offset을 저장할 것이다. 이 초기 스택 인자는 메모리 관리 시스템에 있는 프로시저 테이블의 일부이다. "/src/mm/mproc.h" 파일에 MPROC 구조의 초기 스택 위에 포인터가 있다. 메모리는 최종적으로 표 1.4와 같게 된다. 이것은 실행의 시작 시 main() 프로시저에 나타나는 스택 모습이다. 1.3.1: C run-time, start-off procedure: --------------------------------------- 이제 프로그램이 맵핑되어 실행되었다. 하지만 문제가 있다. C 컴파일러에 대해 main()은 단지 다른 하나의 함수이다. 컴파일러는 이 함수가 실행하기 위한 함수의 엔트리 포인터인지 알지 못한다. 그래서 컴파일러는 표준 C 호출 장치를 고려해(마지막 인자를 먼저) 3개의 인자에 접근하기 위해 main() 함수 코드를 컴파일 한다. 이 경우, 리턴 어드레스 앞에 세 개의 인자(하나는 정수, 2개는 포인터)를 가질 것으로 추정되지만 이것은 표 3.1의 경우는 아니다. 이 경우, 어떻게 우리는 3개의 인자를 main() 함수에 전달 할 수 있는가? 우리는 작은 어셈블리어 코드를 만들 것이고, 그것은 프로그램의 앞 헤더에 삽입될 것이다. 이 코드는 C run-time, start-off procedure, CRTSO라고 불리며, 일반적인 목적은 스택에 3개의 dword를 더 추가하고, 표준 호출 명령으로 main() 함수를 호출하는 것이다. -DWord 1: ARGC: 함수에 건네지는 인자의 수 타입: 정수 Note 1: 표 1.4에서 주소 0x6476 -DWord 2: ARGV: 인자 배열 문자열에서의 포인터 타입: 포인터 Note 1: 표 1.4에서 주소 0x6484와 0x6492에서의 포인터 -DWord 3: ENVP: environment 배열 문자열에서 포인터 타입: 포인터 Note 1: 표 1.4에서 주소 0x6488 및 0x6508에서 포인터 These three dwords are represented in the Figure 1.4. Okay, there is an assembly procedure called CRTSO, but what look like this procedure? Let the hunt begin! The GDB hunting ground is now open! Let us first import our test program ("crtso") in GDB. ----- (gdb) file crtso Reading symbols from crtso...done. ----- Okay, now, we don't have any ideas of where to start to find this legend in the ground. In this case, let us start a point 0, this is the only point that we know his existence. ----- (gdb) disassemble main Dump of assembler code for function main: 0x80481e0
: push %ebp ... 0x80481eb : call 0x8048498 End of assembler dump. ----- There is no information about the CRTSO location. I have an idea. We'll track him in the program by following each function addresses -1 dword, in this case, we'll have the address of the previous function. If we do this to each functions, we'll probably find the root procedure, the CRTSO! Let's begin the tracking with this new method. ----- (gdb) disassemble main-1 Dump of assembler code for function init_dummy: 0x80481d0 : push %ebp ... 0x80481da : lea 0x0(%esi),%esi End of assembler dump. ----- We found the frame_dummy function at adress 0x80481d0 -1. ----- (gdb) disassemble init_dummy-1 Dump of assembler code for function frame_dummy: 0x80481a0 : push %ebp ... 0x80481c9 : lea 0x0(%esi,1),%esi End of assembler dump. ----- We found the fini_dummy fonction at 0x80481a0 -1. ----- (gdb) disassemble frame_dummy-1 Dump of assembler code for function fini_dummy: 0x8048190 : push %ebp ... 0x804819a : lea 0x0(%esi),%esi End of assembler dump. ----- We found the __do_global_dtors_aux fonction at 0x8048190 -1 ----- (gdb) disassemble fini_dummy-1 Dump of assembler code for function __do_global_dtors_aux: 0x8048130 <__do_global_dtors_aux>: push %ebp ... 0x804818d <__do_global_dtors_aux+93>: lea 0x0(%esi),%esi End of assembler dump. ----- We found the call_gmon_start fonction at 0x8048130 -1 ----- (gdb) disassemble __do_global_dtors_aux-1 Dump of assembler code for function call_gmon_start: 0x8048104 : push %ebp ... 0x804812f : nop End of assembler dump. ----- We found the _start fonction at 0x8048104 -1 Hummm, that's an interesting function, that's not? We found it! ----- (gdb) disassemble call_gmon_start-1 Dump of assembler code for function _start: 0x80480e0 <_start>: xor %ebp,%ebp 0x80480e2 <_start+2>: pop %esi 0x80480e3 <_start+3>: mov %esp,%ecx 0x80480e5 <_start+5>: and $0xfffffff0,%esp 0x80480e8 <_start+8>: push %eax 0x80480e9 <_start+9>: push %esp 0x80480ea <_start+10>: push %edx 0x80480eb <_start+11>: push $0x808e220 0x80480f0 <_start+16>: push $0x80480b4 0x80480f5 <_start+21>: push %ecx 0x80480f6 <_start+22>: push %esi 0x80480f7 <_start+23>: push $0x80481e0 0x80480fc <_start+28>: call 0x80481f0 <__libc_start_main> 0x8048101 <_start+33>: hlt 0x8048102 <_start+34>: mov %esi,%esi End of assembler dump. ----- The CRTSO will put the three parameters on the stack by performing three push commands: 0x80480e8 <_start+8>: push %eax ! push argc ( integer ) 0x80480ea <_start+10>: push %edx ! push argv ( pointer ) 0x80480f5 <_start+21>: push %ecx ! push envp ( pointer ) after, the CRTSO will execute the __libc_start_main function (visible in the libc.so.6 library). Than, the __libc_start_main will call the __libc_init_first function and this function will call _init. Then it arrange _fini to be called when the program exit. finally, 0x8048101 <_start+33>: hlt, is called to force a trap if exit fails. After this, all parameters will be on the stack and the main() function of our program will have access to these parameters as shown in the Figure 1.4.