Memory Layout in Program Execution 프로그램 수행 중일 때의 메모리 구조 By Fr??ick Giasson fred@decatomb.com http://www.decatomb.com October 2001 Copyrights, 2001, Fr??ick Giasson 출처 : http://web.textfiles.com/computers/memorylayout.txt ==+==+==+==+==+==+==+==+==+==+==+==+==+==+==+==+==+==+==+==+==+==+==+==+==+==+ 번역 : 김동성(dskim@mail.hau.ac.kr), Network Security Lab(http://nslab.hau.ac.kr) /* 번역상의 문제가 있거나 궁금증이 계신 분은 저에게 멜을 보내주세요 */ 도움 : mutacker, mutacker@mail.hau.ac.kr ==+==+==+==+==+==+==+==+==+==+==+==+==+==+==+==+==+==+==+==+==+==+==+==+==+==+ Table of Contents: ------------------ Preface Introduction Introduction Chapter 1: 1:... Program execution: The route map. 1.1:.... The pseudo-shell code. 1.2:.... Create a child Process. 1.2.1:..... FORKS system call: the nine steps. 1.3:.... Execute the program. 1.3.1:..... C run-time, start-off procedure. 1.3.2:..... EXEC system call, the nine steps. Chapter 2: 2:... Memory layout in executed program. 2.1:.... Dissection of the ELF executable file. Chapter 3: 3:... The Stack and the Heap. 3.1:.... Where are they? 3.2:.... How to know what's the size of the user stack frame at compilation? 3.3:.... Registers. 3.3.1:..... Generals Registers. 3.3.2:..... Segments register. 3.3.3:..... Offsets Registers. 3.4:.... The stack. 3.4.2:..... Stack management during procedure calling. 3.4.2.1:...... The call. 3.4.2.2:...... The Prologue. 3.4.2.3:...... The return. 3.5:.... The Heap. Conclusion Annex 1 Annex 2 Annex 3 Bibliography Preface: -------- 이것은 웹에 출판한 나의 첫 번째 문서이다. 이 문서는 초보자나 중간정도의 시스템 관리자, 프로그래머, 커널 개발자, 취미로 삼는 사람, 또는 이 주제에 관해 관심있는 컴퓨터광을 위한 것이다. 나는 나의 서투른 영어실력에 대해서 유감스럽게 생각하고, 만약 당신이 문법 실수를 발견한다면 기꺼이 나에게 보고하고 알려주신다면, 나는 기쁜 마음으로 그 글월을 수정할 것이다. 만약 나와 또 다른 독자들과 함께 이 문서를 토론하기를 원하다면, 이 문서에 대해서 특별히 만들어진 토론 포럼에 참여하여 주기를 바란다. - http://www.decatomb.com/forums/viewforum.php?forum=29 소개: ----- 메모리 관리는 운영 체제 개발에서 핫 토픽이다. 이것은 시스템의 중요한 자원이며 조심스럽게 다루어져야할 필요가 있다. 이 글은 메모리 관리 시스템의 모든 과정을 다루지 않을 것이다. 아니, 우리는 메모리 관리 시스템에서 사용자의 관점을 볼 것이다. 우리는 프로그램 파일이 어떻게 실행되는지 그리고 메모리로 어떻게 매핑 되는지를 볼 것이다. 물론, 메모리 관리 시스템에 관해 다음과 같이 많은 다른 부분이 있다: 스와핑, 가상 메모리, 페이지 교체 알고리즘, 세그멘테이션 등등. 그래서 당신이 운영체제에서 메모리 관리 시스템의 모든 프로세스(과정)를 이해하기 원한다면, 그러면 이 문서의 끝의 참고문헌을 자세히 살펴 보기를 바란다. 거기에 리눅스/유닉스와 미닉스 메모리 관리 시스템에 관한 많은 유용한 자원들이 있다. 나는 어떻게 이 프로세스가 동작되는지를 설명하기 위해서 미닉스와 리눅스 메모리 관리 시스템을 이용할 것이다. 이것은 실제적으로 NetBSD, FreeBSD 등과 같은 ELF기반 A-32 운영체제와 동일한 스키마이다. 모든 예시 프로그램은 리눅스 하에서의 GCC로 컴파일 될 것이고, 또한 나는 로우(low) 레벨 환경에서 우리의 증명 프로그램이 어떻게 동작하는지를 당신에게 보여주기 위해 우리의 예시 프로그램을 디버그하기 위해서 GDB를 사용할 것이다. Chapter 1: Program execution: The route map: --------------------------------------------- 수행된 프로그램이 어떻게 메모리에 맵핑되는지를 아는 것은 흥미로운 일이다. 그런데 이것(프로그램)은 어떻게 실행되어지는가? 이 글의 첫 번째 부분에서 나는 당신이 경로 맵(route map)을 추척하도록 함으로써 프로그램 동작의 전체 실행 프로세스가 어떻게 되는지를 당신에게 보여줄 것이다. 시작 점은 사용자가 쉘에서 프로그램 이름을 타이핑하고 를 누를 때이다. 경로의 마지막 단계는 프로그램이 메모리에서 매핑되어지고 시작을 준비할 때이다. ------ [Root@Seldon prog]# helloworld < Enter > Hello World! ------ 좋아~, 나는 (helloworld)를 실행하는 나의 프로그램의 이름을 타이핑하였고, Enter 키를 눌렀다. 내가 를 치는 시간과 나의 콘솔 창에 "Hello World" 스트링이 나타난 것 사이에 무엇이 추가되는가? 이것이 마술인가? 절대로 아니다! 1.1: The pseudo-shell code: --------------------------- 매우 기본적인 쉘프로그램의 의사-코드가 있다. : ------ #define TRUE 1 ARRAY command ARRAY parameters while(TRUE) { read_command_line(command,parameters); /* We are waiting to read an input from the terminal. In our example, command = "helloworld" and parameters = "" */ pid_t = fork(); /* pid_t contain the process ID of the child process */ if( pid_t != 0 ) /* If the PID isn't 0 then... { Note: The PID == 0 when it's the child's thread of execution. */ /* Parent code. */ waitpid(-1,&status,0); /* The program is waiting the end of the child execution ( -1 ) to continue the parent process }else{ ( the Shell ) */ /* Child Code. */ execve(command,parameters,0); /* Finally, we execute our helloworld program! */ } } ------ 노트 1: execve() 함수는 자식 프로세스( fork() == 0일 때)에서 호출되고 waitpid() 명령은 부모 프로세스에서 호출된다( fork() == pid_t일 때) ------ 당신은 이해하지 못했는가? 걱정하지 마라. 나는 아래에 의사-쉘 모든 부분을 당신에게 설명할 것이다. 1.2: Create a child process: ---------------------------- 먼저, 프로그램은 우리 프로그램의 실행을 조작하기 위한 새로운 프로세스를 생성하는 것을 필요로 한다. Minix와 리눅스 하에서 이것을 수행하기 위한 방법이 있다. : ------ Minix: ------ do_fork() Linux: ------ fork() vfork() clone() ------ 리눅스 하에서 fork()와 처럼 vfork()와 clone()은 거의 같은 함수이지만, 프로세스 관리면에서 약간의 차이점을 가진다. 이 두 함수에 대한 더 많은 정보를 리눅스 맨페이지에서 보라. (man clone or man vfork). 우리는 우리의 노력을 fork()함수에 집중할 것이다. fork()함수는 미눅스와 리눅스에서 같은 역할을 한다. 이 함수는 모든 파일 설명자(file descriptions), 변수들, 레지스터들, 모든 것들을 포함하는, 부모 프로세스의 정확한 복사물을 생성할 것이다. fork() 호출 후, 자식프로세스와 부모 프로세스는 그들 각자의 분리된 길을 간다. 모든 변수들의 값은 fork()의 호출시에 같지만, 그 후에는, 부모와 자식 변수의 값은 변할 것이고 자식 프로세스는 부모에게, 부모 프로세스는 자식 프로세스에게 영향을 미치지 않을 것이다. 부모와 자식 프로세스 간에 유일하게 공유하는 것은 변하지 않는 텍스트(text) 영역이다. 오케이, FORK 시스템 호출이 보내지면, 자식 프로세스가 생성되어진다. 지금 fork() 함수를 끝내기 전에, 시스템 호출은 자식 프로세스 식별자(PID)의 값을 프로그램에 반환할 것이다. PID는 다음과 같이 types.h에 정의된 부호화된 정수 변수 값이다 : 노트 1: fork() 프로시저는 FORK system call을 보낼 것이다. 이러한 두 개념에 의해 혼동되지 말라. ------ 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: FORKS system call: the nine steps: ----------------------------------------- FORK 시스템 호출이 수행하는 9 단계가 있다: 노트 1: 당신은 부록(Annex) 1에 있는 do_fork()안의 이러한 단계의 모든 것을 찾을 수 있다 노트 2: 리눅스 fork()함수에 대한 코드는 fork.c 파알의 glibc안에 있다 노트 3: 이러한 단계에 대한 설명은 미닉스에 대해서만 적용가능하다. 기본은 리눅스에 대해서도 동일하다. 정말로 유일하게 다른 것은 커널에 의해 어떻게 프로세스가 생성되는가 하는 것이다. 1- 프로세스 테이블이 가득찼는지를 체크하라(부록1의 14줄에서 16줄) 오케이, 프로세스 테이블의 지옥과 같은 상태는 무엇인가? 프로세스 테이블은 커널의 일부분이다. 테이블의 정의는 부록 2에 있다. 이 테이블은 모든 프로세스의 레지스터들, 메모리 맵, 어카운팅(accounting), 그리고 송수신해야 할 메시지들을 포함한다. 노트 1: 프로세스 테이블에서 슬롯의 갯수는 " /include/minix/config.h "에 있는 NR_PROCS에 의해 정의된다. ------ #define NR_PROCS 32 ------ 노트 2: 리눅스에서, 프로세스의 최대 갯수는 태스크 벡터의 사이즈이다, 보통 디폴트로 512 엔트리를 가진다. 2- 자식 프로세스의 데이타와 스택에 대한 메모리를 할당하기 시도한다. 3- 부모의 데이터와 스택을 자식의 메모리로 복사한다. 4- 빈 프로세스 슬롯을 찾고 부모의 슬롯을 그곳에 복사한다. 5- 프로세스 테이블에 자식의 메모리 맵을 넣는다 6- 자식에 대한 PID를 선택한다. 노트 1: 잊지 마라, pid_t는 반드시 부호화된 정수여야 한다 7- 커널과 파일 시스템에 자식에 대해서 말한다 왜 FORK 시스템 호출은 커널과 파일 시스템에 새롭게 생성된 프로세스에 대해서 말해야 하는가? 왜냐하면 미닉스 프로세스 관리, 메모리 관리 그리고 파일 관리는 분리된 모듈에 의해서 각각 관리되기 때문이다. 그래서, 프로세스 테이블은 3부분으로 나눠져있고, 그러한 부분의 각각은 그것이 필요로하는 필드를 가진다. 메모리 관리를 포함하는 프로세스 테이블 부분은 파일 "/src/mm/mproc.h"안에 정의된다 파일 시스템 관리를 포함하는 프로세스 테이블 부분은 파일 "/src/fs/fproc.h"에 정의된다 마지막으로, 커널에 관련된 프로세스 테이블 부분은 부록 2에 정의된다. 8- 자식의 메모리 맵을 커널에 보고한다. 9- 응답 메시지를 부모와 자식에게 보낸다. 노트 1: 자식 프로세스에 대한 리턴 값을 0이고 부모 프로세스에 대한 리턴 값은 자식 프로세스의 PID이다. 우리가 볼 수 있듯이, 어떤 쉘로부터 호출되는 하나의 프로그램 실행의 첫번째 부분은 그렇게 간단하지 않다. FORK 시스템 호출은 execve() 명령에 의해 시작되어지는 우리의 새로운 프로그램의 실행을 다루기 위해서만 새로운 프로세스를 생성할 것이다. 그래서, 프로세스 관리의 전체 프로토콜은, 모든 시스템 레벨(프로세스 관리 시스템, 입출력 태스크, 서버프로세스(파일 시스템, 메모리 관리, 네트워크)에서, 마지막으로 사용자 프로세스들까지)에서 우리가 do_fork() 절차를 호출할 때 연관된다. 나는 이것이 목표가 아니기 때문에 이 프로토콜을 이 장에서 토론하기 않을 것이다. 1.3: Execute the program: ------------------------- 오케이, 우리는 새로운 프로세스를 생성했다. 이제; 우리는 이 프로세스를 우리의 프로그램을 실행하는데 사용할 것이다. execve()함수는 "EXEC system call"로 알려진 새로운 시스템 호출을 호출한다. 이 시스템 호출을 무엇을 수행하는가? 이것은 현재의 메모리 이미지를 새로운 것으로 교체하고 이 새로운 메모리 이미지에 대한 새로운 스택을 셋업시킨다. 미눅스와 리눅스하에서 어떤 프로그램을 실행시키는 방법들이 있다. Minix: ------ do_exec() 노트 1: /src/mm/exec.c 라이브러리안에 있음. /src/fs/misc.c와 /src/kernel/system.c library 안에 다른 do_exec() 함수가 있지만 나는 이 섹션 안에 다른 것에 대해서 이야기할 것이다. Linux: ------ execve() exec 패밀리 프로시저들의 다른 변형이 있다, 더 자세한 정보는 man pages를 보라: execl() execlp() execle() execv() execvp() 오케이, 우리는 메모리에 우리의 새로운 이미지의 크기의 한 구멍이 있다고 고려할 것이다. 나는 먼저 EXEC 시스템 호출에 의해 프로그램이 어떻게 조정되어지는지를 보여줄 것이고, 그 후에 do_exec() 함수가 수행하는 모든 단계를 보여줄 것이다. FOKR 시스템 호출과 마찬가지로, 다음의 설명은 Minix 운영체제에 대해서만 완전히 호환되는 고려 대상이며, 그러나 리눅스 OS하에서도 기본은 같다. EXEC 시스템 호출의 조작은 같지만, 리눅스하에서 커널, 메모리 관리, 파일시스템은 리눅스 시스템에 특정한 많은 다른 특징들과 관련된 문제들은 다른 방법으로 다루어질 수 있지만, 과정은 동일하다. 우리가 우리의 쉘에 "mv hw pg" 명령을 전달할 때의 EXEC의 모든 프로세스를 이해하기 위해 사용될 메모리 스키마가 있다. 노트 1: 이 명령은 파일 "hw"을 "pr"로 이름을 변경할 것이다. Arrays passed to execve() ------------------------- execve()에 전달되는 배열들 Argument Array --------------- | 0 | |---------------| | pr | |---------------| | hw | |---------------| | mv | --------------- 그림 1.0 Environment Array --------------- | 0 | |---------------| | HOME=/root | --------------- 그림 1.1 The stack build by 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 | --------------- Figure 1.2 The stack after relocation by the memory manager: (메모리 관리자에 의한 재할당 후의 스택): ------------------------------------------------- 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 The stack as it appears to main() at the start of execution: (실행의 시작시에 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 프로세스에서의 두 가지 중요한 배열이 있다. 환경 배열(그림1.0) 과 인수 배열 (그림1.1)이다. 환경 배열은 스트링의 배열이고, 이것은 새로운 프로그램에 환경으로써 전달된다. 인수 배열은 새로운 프로그램에 전달되는 인수 스트링의 배열이다. 이러한 두가지 배열은 NULL 문자("\0")와 함께 종료될 필요가 있다. do_exec() 프로시지는 지금 쉘의 주소 공간 안에 초기 스택(그림1.2, 부록 3의 49~56줄)을 만들 것이다. 다음으로, 프로시저는 메모리 관리를 부를 것이고 이것은 새롭게 생성된 스택에 한 새로운 메모리를 할당할 것이며 오래된 것을 해제시킬 것이다.(Annex 3 lines 062 to 066) 프로시저가 포인터를 패치 업(patch up)시킨 후에 (Annex line 077) 그리고 지금 그림1.2의 메모리는 그림 1.3의 메모리 모양을 가진다. 마지막으로, 우리는 초기 인수에 오프셋을 저장한다(Annex line 077). 초기 스택 인수는 메모리 관리 시스템의 프로시저 테이블의 한 부분이다. "/src/mm/mproc.h" 파일안에 MPROC 구조 안에 초기 스택에 대한 포인터가 있다. 메모리는 최종적으로 그림 1.4와 같이 보인다. 이것이 실행의 시작시에 main() 프로시저에 나타날 스택 표현이다. 1.3.1: C run-time, start-off procedure: --------------------------------------- 오케이, 지금, 프로그램은 맵핑되었고 실행되었다. 그러나 우리는 약간의 문제가 있다. C 컴파일러에 대해서, main()은 단지 또다른 함수일 뿐이다. 컴파일러는 main()함수가 실행할 우리의 프로그램의 시작점임을 알지 못한다. 그래서 컴파일러는 main() 함수 코드 표준 C 호출 관례를 고려하여, 마지막 파라미터 첫번째 파라미터 순으로 컴파일한다. 이 경우에, 리턴 주소 전에 3가지 파라미터를 가지는 것으로 예상되고(한 정수와 2개의 포인터), 그러나 이것은 우리의 그림1.3의 경우는 아니다. 이 경우에, 우리는 어떻게 main() 함수에 3개의 파라미터를 전달 할 수 있는가? 우리는 작은 어셈블리 코드를 생성하고, 이것은 우리의 프로그램의 앞 머리 부분에 삽입되어질 것이다. 이 코드는 C 런-타임, 스타트-오프 프로시저, CRTSO로 불려지고, 이 코드의 일반적인 목적은 스택에 3개 이상의 dwords를 두고, main()함수를 표준 호출 명령으로 호출하기 위한 것이다. -DWord 1: ARGC: The number of parameters passed to the function. 함수에 전달되는 파라미터의 수 Type: Integer Note 1: Adress 0x6476 on Figure 1.4 -DWord 2: ARGV: Pointer on parameters array string. 파라미터 배열 스트링에서의 포인터 Type: Pointer Note 1: Adress 0x6484 and pointer on 0x6492 on Figure 1.4 -DWord 3: ENVP: Pointer on the environment array string. 환경 배열 스트링에서의의 포인터 Type: Pointer Note 1: Adress 0x6488 and pointer on 0x6508 on Figure 1.4 이러한 세가지 dwords는 그림 1.4에 표시되어진다. 오케이, CRTSO라고 불려지는 어셈블리 프로시저가 있다. 그러나 이 프로세저는 무엇처럼 보이는가? 사냥하기 시작해보자. GDB 사냥 땅은 지금 열려진다! 먼저 GDB에서 우리의 테스트 프로그램("crtso")을 가져오자. ----- (gdb) file crtso Reading symbols from crtso...done. ----- 오케이, 지금, 우리는 이 땅에서 이 전설을 찾기 위해 어디서부터 시작해야 할지에 대해서 모른다. 이 경우에, 우리는 포인터 0에서 시작하자, 이것이 우리가 그의 존재에 대해서 아는 유일한 점이다. ----- (gdb) disassemble main Dump of assembler code for function main: 0x80481e0
: push %ebp ... 0x80481eb : call 0x8048498 End of assembler dump. ----- CRTSO 위치에 대한 정보가 없다. 나는 아이디어가 있다. 우리는 각각의 함수 주소-1 dword를 따라감으로써 프로그램 안에서 그것을 추적할 것이다. 이 경우에, 우리는 이전 함수의 주소를 가질 것이다. 만약 우리가 각각의 함수에 대해서 이것을 한다면, 우리는 루트 함수, the CRTSO를 아마도 발견할 수 있을 것이다! 이 새로운 방법으로 추적을 시작해보자. ----- (gdb) disassemble main-1 Dump of assembler code for function init_dummy: 0x80481d0 : push %ebp ... 0x80481da : lea 0x0(%esi),%esi End of assembler dump. ----- 우리는 주소 0x80481d0 -1에서 frame_dummy 함수를 발견했다. ----- (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. ----- 우리는 0x80481a0 -1에서 fini_dummy 함수를 발견했다. ----- (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. ----- 우리는 0x8048190 -1에서 the __do_global_dtors_aux 함수를 발견했다. ----- (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. ----- 0x8048130 -1에서 call_gmon_start 함수를 발견했다. ----- (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. ----- 0x8048104 -1에서 _start 함수를 찾았다. 흠..., 이것은 흠미로운 함수이다, 그렇지 않나? 우리는 이것을 발견했다 ! ----- (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. ----- CRTSO는 3개의 푸시 명령을 수행함으로써 스택에 대한 3개의 파라미터를 놓을 것이다.: 0x80480e8 <_start+8>: push %eax ! push argc ( integer ) 0x80480ea <_start+10>: push %edx ! push argv ( pointer ) 0x80480f5 <_start+21>: push %ecx ! push envp ( pointer ) CRTSO가 __libc_start_main function (visible in thelibc.so.6 library) 함수를 실행할 것이다. 그리고, __libc_start_main함수는 the __libc_init_first함수를 호출할 것이고, 이 함수는 _init함수를 호출할 것이다. 그리고나서 프로그램이 나갈 때 불려질 _fini을 정렬한다. 마지막으로, 0x8048101 <_start+33>: hlt, 는 만약 실패가 존재하면 트랩을 강제수행하기 불려진다. 이것 후에, 모든 파라미터들은 스택에 있을 것이고, 우리의 프로그램의 main()함수는 그림 1.4에서 보여진 것처럼 이러한 파라미터들을 액세스할 것이다. 1.3.2: EXEC system call, the nine steps: ---------------------------------------- 지금, 우리는 EXEC system 호출의 모든 단계를 설명할 것이다. 메모리 안에 매핑되고 실행되어지는 프로그램의 9개의 중요한 단계가 있다. 1- 먼저, 메모리와 파일이 실행가능한지를 체크한다.( Lines 24 to 37 in Annex 3 ) 파일 실행은 MM과 관계가 있고, MM은 MM의 작업 디렉토리보다 사용자의 작업로 전환하기 위한 tell_fs() 프로시저에 의해 FS에 알릴 것이다. 프로그램의 실행은 MM allowed 함수에 의해 실행될 것이다. 2- 세그먼트와 총 크기를 얻기 위해 헤더를 읽는다( Lines 40 to 46 in Annex 3 ) 3- 인수들과 호출자로부터의 환경을 페치 한다( Lines 49 to 56 in Annex 3 ) 4- 새로운 메모리를 할당하고 필요없는 옛 메모리를 해제시킨다( Lines 62 to 66 in Annex 3 ) 이것을 하기전에, 우리는 , find_shared() 프로시저와 함께( line 59 in Annex 3 ), 텍스트 버젼이 메모리에 이미 로드되어지지 않았는지와 다른 프로세스와 공유할 수 있는지를 체크할 것이다. 그 다음에, 우리는 new_mem()함수를 호출할 것이다. 이 함수는 메모리에서 우리의 새로운 메모리 이미지(그곳에, 우리의 응용프로그램의 데이터와 스택 섹션, 만약 우리가 메모리에서 공유하는 접근가능한 텍스트 섹션을 찾는다면)에 대해 충분히 큰 빈 공간 찾기 위해 메모리에서 체크할 것이다. 그 다음에, 메모리 맵들은 업데이트되고 sys_newmap() 함수는 커널에 변화를 보고할 것이다. 노트 1: 만약 new_mem() 프로시저가 하나, 둘 혹은 세개의 섹션에 대한 충분히 큰 빈 공간을 발견하지 못하면 프로그램은 실행되지 못할 것이다. 이 프로시저를 증가하기 위한 한가지 방법은 데이터, 코드, 텍스트 섹션을 세개의 다른 공간에 위치시키고 그것들을 함께 링크시키는 것이다. 그러나 이것은 Minix 운영체제의 경우는 아니다. 그러므로, 이것은 리눅스의 경우이다, 먼저, 데이터 섹션과 코드 섹션은 다른 가상 메모리 공간에 놓일 수 있다. 이 사실은 리눅스 하에서 프로세스와 프로세스의 가상 메모리라고 불리는 물리적인 메모리 사이에 중간 메모리 천국 (intermediate memory heaven)이 있다는 것이다. 그것들은 vm_area_struct 구조체로 함께 연결되어져 있다. 이 구조는 mm_struct 구조의 일부분이고 이것은 task_struct (모든 실행중인 프로세스들과 함께하는 vector)의 일부분이다. 그러나, 이 프로시저는 역시 "demand paging"이라 불리는 기술에 의해 업그레이드된다. demand paging은 프로세스의 가상 메모리가 프로세스가 물리적 메모리를 사용하려고 시도할 때만 물리적인 메모리로 옮겨진다. 노트 2: new_mem() 함수는 bss 세그먼트(이 세그먼트는 데이터 세그먼트의 일부분이다. bss는 모든 초기화되지 않은 전역 변수들을 포함한다. 나는 이 세그먼트에 대해서 내가 메모리안에 응용 프로그램의 메모리 레이아웃에 대해서 얘기할 때 아래서 얘기할 것이다.), gap과 스택 세그먼트를 모두 제로화한다. 노트 2.1: gap은 bss와 스택 세그먼트사이의 메모리 세그먼트이고, 이것은 더 많은 메모리를 할당하게 허용할 것이다. 나는 메모리 레이아웃 절에서 이 세그먼트에 대해서도 또한 얘기할 것이다. gap에게 주어진 다른 이름은 사용자 스택 프레임이다. 5- 스택을 새로운 메모리로 복사한다.( lines 74 to 81 in Annex 3 ) 전체 스택은 새로운 메모리 지역, 사용자 메모리 영역에 재 복사될 것이다. 그 이후, patch_ptr()함수 (Line 077 Annex 3)는 새로운 메모리 할당(물리적 메모리에서의 실제 위치와 가상 0이 아님)을 포인터하기 위해 모든 포인터를 패치할 것이다. 지금, 우리는 그림 1.2에서부터 그림 1.3까지 지났다. 6- 데이터(그리고 가능한 텍스트)세그먼트를 새로운 메모리 이미지로 복사한다.( Lines 84 to 89 in Annex 1 ) 텍스트 세그먼트의 복사하는 것은 find_shared() 함수의 리턴 값에 의존할 것이다. 만약 메모리에 이미 실행되는 우리의 것과 대응하는 텍스트 세그먼트가 없다면, 리턴 값은 NULL이 될 것이다. 노트 1: MPROC 구조체는 /src/mm/mproc.h 파일에 정의되어 있다. 노트 2: MPROC구조체안에 포함하는 3 변수는 ; ino_t mp_ino; /* inode number of file */ dev_t mp_dev; /* device number of file system */ time_t mp_ctime; /* inode changed time */ 이 후에, sh_mp 구조(mproc)가 NULL이면, load_seg()는 메모리에 있는 텍스트 세그먼트를 로드할 것이고 load_seg()프로시저 후에 재 호출될 것이고 메모리에 있는 데이터 세그먼트는 로드될 것이다. 7- setuid, setgid 비트를 체크하고 다룬다.( Lines 100 to 109 in Annex 3 ) 8- 프로세스 테이블 엔트리를 fix up(고정)한다. EXEC call은 우리 사용자의 프로세스의 새로운 메모리 할당과 함께 MPROC의 모든 필드를 고정시킬 것이다. 9- 그 프로세스가 현재 실행되는지를 커널에 말한다. 마지막으로 프로세스는 sys_exec()를 조작하는 "/src/kernel/system.c"에 있는 do_exec() 프로시저에 의해 알려질 것이다. SYS_EXEC 메시지는 "/include/minix/com.h"에 정의되어 있다. 이 메시지는 EXEC 시스템 호출 후에 프로그램 카운터(PC)와 스택포인터(SP)를 셋팅할 것이다. shell에 의해 호출된 우리의 응용프로그램(helloworld)은 명확하게 실행되어지고 사용자의 메모리에 매핑되어진다. 다음 절에서는, 나는 어떻게 프로그램이 메모리에 매핑되는지를 보여줄 것이다. Chapter 2: Memory Layout of an executed program: ------------------------------------------------ 하나의 프로그램은 변수들, 지역과 전역, 정적 그리고 동적 변수, 프로시저와 구조체로 구성되어진다. 그러나, 그것들은 메모리에서 어떻게 매핑되어지는가? 어떻게 동작하는가? 노트 1: 이 절의 모든 정보들은 ELF 실행 파일 포맷에 적용가능할(들어 맞을) 것이다. 이 경우에, 아래의 모든 정보는 리눅스 운영 체제와 OpenBSD, NetBSD,기타 등과 같은 다른 IA-32 ELF 기반 운영체제에도 적용가능할 것이다. 메모리에서의 하나의 프로그램의 기본적인 레이아웃이 있다. --------------- | | | Arguments and | | environment | | variables | | | |---------------| | Stack |<--|-- |(grow downward)| | | | |User | | |Stack | | |Frame | | | | (grow upward) | |( Mind the Gap ) | Heap |<--|-- |---------------| | BSS | |---------------| | Data | |---------------| | Code | --------------- Figure 1.5 하나의 C 코드가 있는데, 이것은 어떻게 변수가 메모리 내에서 매핑되는지를 설명할 것이다. varinmem.c ------------------- int iGlobalInit = 1; /* Global Initialized: .data */ int iGlobalUnInit; /* Global Uninitialized: .bss */ char *szGlobalP; /* Global Uninitialized: .bss */ void function(char cArgument) { int iLocalInit = 1; /* Local Initialized: stack */ int iLocalUnInit; /* Local Uninitialized: stack */ char szLocalP[12] = "Hello World!"; /* Local Initialized: stack */ szGlobalP = (char*)malloc( 12 * sizeof(char)); /* Dynamic Variable: heap */ strncpy(szGlobalP,"Hello World!",12); } int main(void) { function(0); /* Function call: new environment */ } ------ 나는 이 코드를 GDB를 위한 디버깅 정보와 함께 컴파일할 것이다. [root@Seldon prog]# gcc -o varinmem -ggdb -static varinmem.c 노트 1: 이 문서의 모든 프로그램은 이러한 파라미터들로 컴파일 될 것이다. 2.1: The dissection of the ELF executable file: ----------------------------------------------- 우리의 varinmem 프로그램의 모든 섹션 헤더들이 있다 : [root@Seldon prog]# readelf -e varinmem ... Table 1: -------- Section Headers: [Nr] Name Type Addr Off Size ES Flg Lk Inf Al [ 0] NULL 00000000 000000 000000 00 0 0 0 [ 1] .init PROGBITS 080480b4 0000b4 000018 00 AX 0 0 4 [ 2] .text PROGBITS 080480e0 0000e0 046220 00 AX 0 0 32 [ 3] .fini PROGBITS 0808e300 046300 00001e 00 AX 0 0 4 [ 4] .rodata PROGBITS 0808e320 046320 00da80 00 A 0 0 32 [ 5] __libc_subinit PROGBITS 0809bda0 053da0 000008 00 A 0 0 4 [ 6] __libc_subfreeres PROGBITS 0809bda8 053da8 00003c 00 A 0 0 4 [ 7] __libc_atexit PROGBITS 0809bde4 053de4 000004 00 A 0 0 4 [ 8] .data PROGBITS 0809ce00 053e00 001220 00 WA 0 0 32 [ 9] .eh_frame PROGBITS 0809e020 055020 000d40 00 WA 0 0 4 [10] .ctors PROGBITS 0809ed60 055d60 000008 00 WA 0 0 4 [11] .dtors PROGBITS 0809ed68 055d68 000008 00 WA 0 0 4 [12] .got PROGBITS 0809ed70 055d70 000010 04 WA 0 0 4 [13] .sbss PROGBITS 0809ed80 055d80 000000 00 W 0 0 1 [14] .bss NOBITS 0809ed80 055d80 000f44 00 WA 0 0 32 [15] .stab PROGBITS 00000000 055d80 0cf030 0c 16 0 4 [16] .stabstr STRTAB 00000000 124db0 059911 00 0 0 1 [17] .comment PROGBITS 00000000 17e6c1 002e9e 00 0 0 1 [18] .debug_aranges PROGBITS 00000000 18155f 000020 00 0 0 1 [19] .debug_pubnames PROGBITS 00000000 18157f 000058 00 0 0 1 [20] .debug_info PROGBITS 00000000 1815d7 000198 00 0 0 1 [21] .debug_abbrev PROGBITS 00000000 18176f 0000c0 00 0 0 1 [22] .debug_line PROGBITS 00000000 18182f 00007e 00 0 0 1 [23] .note.ABI-tag NOTE 08048094 000094 000020 00 A 0 0 4 [24] .note NOTE 00000000 1818ad 001144 00 0 0 1 [25] .shstrtab STRTAB 00000000 1829f1 000103 00 0 0 1 [26] .symtab SYMTAB 00000000 182f54 005aa0 10 27 26d 4 [27] .strtab STRTAB 00000000 1889f4 004b48 00 0 0 1 Key to Flags: W (write), A (alloc), X (execute), M (merge), S (strings) I (info), L (link order), G (group), x (unknown) O (extra OS processing required) o (OS specific), p (processor specific) ... Table 2: -------- Description of most important sections -------------------------------------- 가장 중요한 섹션의 설명 .interp <-----| Path name for a program interpreter 프로그램 해석기에 대한 경로 명 .hash <-----| Symbol hash table 심볼 해시 테이블 .dynsym <-----| Dynamic Linking symbol table 동적 링킹 심볼 테이블 .dynstr <-----| Strings needed for dynamic linking 동적 링킹에 필요한 스트링 .init <-----| Process initialisation code 프로세스 초기화 코드 .plt <-----| Procedure linkage table 프로세스 링키지 테이블 .text <-----| Executable instructions 실행가능한 명령어들 .fini <-----| Process termination code 프로세스 종료 코드 .rodata <-----| read-only data 읽기전용 데이터 .data <-----| Initialised data present in process image 프로세스 이미지에 표시되는 초기화된 데이터 .got <-----| Global offset table 글로벌 오프셋 테이블 .dynamic <-----| Dynamic linking information 동적 링킹 정보 .bss <-----| Uninitialised data present in process image 프로세스 이미지에 표시되는 초기화되지 않은 데이터 .stabstr <-----| Usually names associated with symbol table entries 심볼 테이블 엔트리와 연관된 이름 .comment <-----| Version control informations 버젼 컨트롤 정보 .note <-----| File notes 파일 노트 -------- 우리는 지금 우리의 프로그램을 모든 중요한 섹션의 설명과 함께 모든 섹션을 가진다. 지금, 우리는 이러한 섹션이 무엇을 포함하는지 자세히 살펴볼 것이다. 이것을 위하여 나는 GDB를 사용할 것이다. .init 헤더 섹션부터 시작해보자: ----- [root@Seldon prog]# readelf -x 1 varinmem Hex dump of section '.init': 0x080480b4 0000dbe8 90000000 45e808ec 83e58955 U......E........ 0x080480c4 c3c90004 61b6e800 ...a.... ----- readelf 프로그램은 우리에게 우리의 varinmem 프로그램의 .init 섹션의 16진수 덤프를 보여주준다. 오케이, 이러한 정보들은 이진 파일로부터 직접적으로 추출되어진다. 그런, 우리는 이러한 16진수 세그먼트가 무엇을 숨기는지를 발견할 수 있을까? 우리가 시작 주소에서 .init 섹션의 어셈블리 코드에 우리가 접근할 수 있는지 없는지를 GDB를 사용하여 볼 것이다: 0x080440b4 ----- (gdb) file varinmem Reading symbols from varinmem...done. (gdb) disassemble 0x080480b4 Dump of assembler code for function _init: 0x80480b4 <_init>: push %ebp 0x80480b5 <_init+1>: mov %esp,%ebp 0x80480b7 <_init+3>: sub $0x8,%esp 0x80480ba <_init+6>: call 0x8048104 0x80480bf <_init+11>: nop 0x80480c0 <_init+12>: call 0x80481a0 0x80480c5 <_init+17>: call 0x808e280 <__do_global_ctors_aux> 0x80480ca <_init+22>: leave 0x80480cb <_init+23>: ret End of assembler dump. ----- 우리는 알아냈다! .init 헤더 세그먼트는 _init 함수로 구성되어진다. 잊지말라, 이것은 CRTSO가 아니며, 이 루틴은 우리의 프로그램을 초기화할 것이지 시작하게 하지 않는다. 이 경우에, 어느 세그먼트에 _start 프로시저가 위치해 있는가? ----- (gdb) disassemble _start Dump of assembler code for function _start: 0x80480e0 <_start>: xor %ebp,%ebp ... 0x8048102 <_start+34>: mov %esi,%esi End of assembler dump. ----- _start 함수 코드는 주소0x80480e0에서 시작된다. 지금, 우리의 헤더 섹션(표2)에 돌아와서 이 주소에 어디에 위치하는지 보라: ----- [Nr] Name Type Addr Off Size ES Flg Lk Inf Al [ 2] .text PROGBITS 080480e0 0000e0 046220 00 AX 0 0 32 ----- 흠, 시작하는 주소가 같다! 우리는 발견했다! CRTSO 프로시저는 .text 섹션의 첫번째 프로시저이다. 지금, 우리는 .data 세그먼트를 살펴볼 것이다. 그곳에 프로세스 이미지안의 모든 초기화된 데이터가 있을 것으로 추측된다. ----- [root@Seldon prog]# readelf -x 8 varinmem Hex dump of section '.data': 0x0809ce00 00000000 0809ed6c 00000000 00000000 ........l....... 0x0809ce10 00000000 00000000 0809edc0 00000001 ................ ... 0x0809e010 00000000 0000003f 3f783020 65707974 type 0x??....... ----- (gdb) disassemble 0x0809ce10 Dump of assembler code for function iGlobalInit: 0x809ce10 : add %eax,(%eax) 0x809ce12 : add %al,(%eax) End of assembler dump. ----- 만약 우리가 .data 섹션의 첫번째 주소를 역어셈블리한다면, 우리는 data_start 프로시저를 볼 수 있을 것이다. 그런, 만약 다음 주소로( 0x809ce12 ) 계속 한다면, 우리는 흥미로운 것들을 보게 될 것이다. 거기에 1(memorylayout.c를 보라)에 초기화된 우리의 iGlobalInit 변수가 있는가? 그렇다! 우리는 우리의 프로그램의 모든 초기화된 전역 변수들이 놓여져있는 위치를 바로 발견하였다! 오케이, 그러나, 어디에 우리의 iGlobalInit과 zGlobalP 변수들이 있는가? ..Tap...Tap...Tap...Tap...Arg...Tap...Tap...cant find it...Tap...Tap... many many time later... Tap...Tap...Tap........ ..Tap...Tap...Tap...Tap...Arg...Tap...Tap...그것을 발견할 수없다...Tap...Tap... 한참 뒤에 .... ..Tap...Tap...Tap........ ..Tap...Tap...Tap.....Tap...Tap...Tap... 흠흠흠 no를 찾기 힘든가? 당신에 연구에서 당신을 도울 수 있는 GDB의 또다른 특성이 있다: ----- (gdb) file varinmem Reading symbols from varinmem...done. (gdb) list 1 1 int iGlobalInit = 1; 2 int iGlobalUnInit; 3 char *szGlobalP; ----- (gdb) print &szGlobalP $1 = (char **) 0x809f7a4 ----- (gdb) info symbol 0x809f7a4 szGlobalP in section .bss ----- (gdb) disassemble 0x809f7a4 Dump of assembler code for function szGlobalP: 0x809f7a4 : add %al,(%eax) 0x809f7a6 : add %al,(%eax) End of assembler dump. ----- (gdb) disassemble 0x809f7a4-1 Dump of assembler code for function iGlobalUnInit: 0x809f7a0 : add %al,(%eax) 0x809f7a2 : add %al,(%eax) End of assembler dump. ----- 우리는 알아냈다! 첫째, 나는 나의 전역 변수들을 보기 위해 우리의 프로그램의 소스코드를 나열하였다. 나는 프로그램에서 szGlobalP 포인터의 메모리 참조를 얻기위해 "&" 심볼과 함께 print GDB 명령을 사용하였다.(print 명령에 대한 보다 자세한 정보는 "help print"를 사용하라)그 이후에, 나는 나의 변수가 임의의 심볼에 표시되는지 아닌지를 알기 위하여 "info symbol" 명령을 사용하였다. 나는 szGlobalP가 .bss 헤더 섹션에 나타나는지를 발견하였다. 그 이후에 나는 szGlobalP 주소에 코드를 그곳에 어떤 것이 있는지 없는지 보기위하여 역어셈블하였다. 나는 나의 szGlobalP 포인터의 선언을 발견하였다! 그 이후에,나는 이 주소전에 무엇이 선언되었는지를 알기 원하였다. szGlobalP 포인터의 주소의 시작전에 내가 그 주소를 디스 어셈블하였기 때문이다. 놀랍게도, 나는 나의 iGlobalUnInit 비초기화된 변수 선언을 발견하였다! 오케이, 나는 다음 장으로 점프할 시간이라고 생각한다. 결론적으로, 만약 당신이 다른 헤더 섹션들을 발견하기를 원한다면, 망설이지 말고 위에 사용된 방법으로 계속하여라. 모든 세그먼트가 어디서 시작하고 멈추는지를 알기위해 "readelf"프로그램을 사용하고 그 이후 GDB로 당신의 프로그램(그 프로그램은 GDB를 위한 디버그 정보와 함께 컴파일되어져야 할 필요가 있다) 을 열어보고 세그먼트들의 주소를 디스어셈블하라! 나는 이와같이 그 코드들을 우려냄으로써 많은 흥미로운 점들을 발견할 수 있을 것으로 확신한다. Chapter 3: The Stack and the Heap: ---------------------------------- 지금 두가지 문제가 있다. 지역 변수들과 동적 변수들. 이러한 두 문제의 해결책은 사용자 스택 프로그램의 두 부분이다. 스택과 힙 영역들.(당신은 gap을 기억하는가?) 왜 초기화된 지역변수들과 비초기화된 지역변수들은 전역변수들의 컴파일땔 때처럼 각각 .data와 .bss에 위치하지않는가? 이것은 왜 리눅스가 프로그램 실행시 메모리 모든 프로시저 를 로드시키지 않는가와 같은 이유때문이다.(1.3절-EXEC step 4 -노트 4를 보라) 만약 당신이 각각 많은 지역 변수들을 가진 수 백의 프로시저들로 실행되는 거대한 프로그램을 가진다면, 많은 지역 변수를 가진 각각의 프로시저 중에, 당신 단지 이러한 프로시저들의 10 혹은 20개만 사용한다. 이 경우에 수천개의 초기화된 변수들이 있을 것이고, 이것들은 프로그램 실행 중에 결도 사용되지 않을 것이다. 당신은 하나의 실행된 프로그램에 대한 메모리 공간의 중요한 분실을 기억하는가? 워크스테이션에서 5 혹은 10개의 프로그램에 대해 이것을 보고해 보라 그러면 이것은 미친 짓이 될 것이다! 이것이 이러한 지역변수들에 대해서 컴파일러가 메모리를 할당하지 않는 주된 이유이다. 이 경우에, 지역변수들은 어디에 위치하게 되는가? 이것이 이 장의 주제이다. 우리는 함수(인자, 지역변수를 가진)와 동적 변수들이 메모리에 어떻게 매핑되는지를 살펴볼 것이다. 나는 먼저 포인터와 동적 변수들에 대해서 약간 설명할 것이다. 사실, 포인터는 전형적인 IA-32 PC워크스테이션의 메모리에서 32비트 주소를 표시한다. 이 경우에, 동적 변수는 포인터에 의해 지시되는 메모리 영역을 표시하고, 포인터는 주소이다! 나는 GDB를 이용한 다음 증명에 의해 포인터와 동적변수들이 어떻게 동작하는지를 보일 것이다. ----- (gdb) list 8 int iLocalUnInit; 9 char szLocalP[12] = "Hello World!"; 10 11 szGlobalP = (char*)malloc( 12 * sizeof(char)); 12 strncpy(szGlobalP,"Hello World!",12); 13 } (gdb) break 13 Breakpoint 1 at 0x8048231: file memorylayout.c, line 13. ----- 나는 먼저 나의 동적 변수가 초기화된 것을 가지기 위해 어디에 브레이크포인트를 지정할 필요가 있는지 알기 위해 소스라인을 표시하였다. 그 후에, 라인 13에 브레이크포인터를 두었다. ----- (gdb) run Starting program: /root/prog/varinmem Breakpoint 1, function (cArgument=0 '\000') at varinmem.c:13 13 } ----- 프로그램을 실행한 후에, 프로그램은 브레이크포인트에서 정지되었다. ----- (gdb) print szGlobalP $1 = 0x809ff88 "Hello World!" ----- 오케이, 나는 나의 "Hello World!" 스트링을 주소 0x809ff88에 가진다. 지금 나는 이 메모리 영역 이 어디에 선언되는지 알기 위해 체크할 것이다. ----- (gdb) info symbol 0x809ff88 No symbol matches 0x809ff88. ----- 웁스, 이 주소에 정의된 심볼이 없다! ----- (gdb) print &szGlobalP $2 = (char **) 0x809f7a4 ----- 오케이, 나는 나의 포인터 주소를 발견했다. ----- (gdb) info symbol 0x809f7a4 szGlobalP in section .bss ----- 나의 포인터는 항상 .bss 세그먼트에 있다. 지금 우리는 0x809ff88주소가 "Hello World!" 스트링이 있는 클러스터이라는 것을 안다. 그것은 이것(Hello world)이 정의된 심볼이 아니기 때문이다. 이것은 동적 변수가 포인터에 의해 지시되는 메모리 영역임을 말할 수 있는 이유이고, 포인터는 이 주소에 있다. 노트 1: 섹션3.5에서 보게될 것처럼, 이러한 메모리 클러스터는 사용자 스택 프레임의 힙 섹센에 할당되어 있다. 3.1: Where are they? -------------------- 당신이 알다시피, 지역 및 동적 변수는 "사용자 스택 프레임"이라고 불리는 예약된 메모리 영역에 위치하게 된다. 이 영역은 동적으로 관리되어진다. 사실, 이 영역의 어떤 부분은 생성될 것이고 하나의 함수가 종료되거나 동적변수의 내용이 변경될 때마다 위부분(스택)과 바닥(힙)에서 가라않게될 것이다. 호출된 함수의 환경은, 인자와 변수를 포함해서, USF의 스택 영역에 생성되어진다. USF 영역의 반대편에, 동적 변수들은 힙 섹션에 생성되어진다. 3.2: How to know what's the size of the user stack frame at compilation? ------------------------------------------------------------------------ 만약 당신이 8088보다 새로운 프로세서를 사용하고 있다면, 하드웨어에 스택 오버플로우를 방지하기 위한 트랩 시스템이 있다. 사실, 프로그램은 사용자 스택 프레임에 어떤 양만큼의 공간을 할당할 거시고 그러나 스택이 이 양이상 자란다면, 운영체제에 대해 트랩이 발생할 것이고, 만약 가능하다면 운영체제는 스택에 또다른 메모리 영역을 할당하려고 시도할 것이다. 3.3: Registers: --------------- 스택과 힙의 설명으로 점프하기 전에, 나는 레지스터들의 기능을 일일히 간단하게 당신에게 열거할 것이다. 레지스터는 프로세서의 한 부분으로, 유일한 역할은 많은 형태의 값들을 저장하는 것이다. 그것들은 프로세서와 메모리사이에 직접적인 링크이다. 3.3.1: General Registers: ----------------------- 이러한 레지스터들은 데이터를 저장하고 조작하기 위해서 사용되어질수 있지만 그들중에 어떤 것은 어떤 태스크를 위해 전용되어진다. A 32bit general registers representation: (32비트 범용 레지스터 표현) ---------------------------------------- ------------------------------------------ | Low | High | | | | | | | 8 | 8 | | | Bits | Bits | | | | | | ------------------------------------------ ^ ^ ^ | First 16 bits | Extended 16 Bits | Figure 1.6 %EBX 표현 예: ---------------------------- ------------------------------------------ | %BL | %BH | | |------------------------------------------| | %BX | | |------------------------------------------| | %EBX | ------------------------------------------ 그림 3.0 새로운 32비트 마이크로 프로세서를 가진 인텔386의 등장과 함께 홈 컴퓨팅 기술에 혁명이 있었다. 과거 16비트 프로세서들은 16비트(%BX)의 길이를 가진 범용 레지스터를 가졌다. 이러한 16비트는 두 8비트 세분으로 구성되어진다. 하위 8비트(%BL)와 상위 8비트(%BH)가 있다. 그러나, 속도의 괴물의 새로운 등장으로, 범용 레지스터들은 새로운 16비트로 확장되어졌고 전체 레지스터는 지금 %EBX로 불리운다. "E"는 "Extended"를 의미한다. %EAX: No specialisation. 특성화되지 않음. %EBX: Specialized for the index addressing management. 인덱스 어드레싱 관리에 특성화 %ECX: Specialized for loops management. 루프 관리에 특성화 EX: MOV %ECX,10 EXLOOP: ADD %EAX,10 LOOP EXLOOP ;ECX = ECX-1; The loop will stop when %EXC == 0 %EDX: Specialized in multiplication/division of unsigned numbers. 부호없는 수의 곱셈/나눗셈에 특성화 3.3.2: Segments registers: -------------------------- %CS: 이것은 코드 세그먼트이다. 이것은 실행중인 응용프로그램의 실행가능한 코드에 대한 참조이다. 이것의 값은 CALL, JMP, Jxx 혹은 POP %CS 명령에 의해 변경될수 있다. %SS: 이것은 스택 세그먼트이다. 이 세그먼트는 SP와 BP세그먼트와 관련되어있다. 이 레지스터는 이 레지스터는 함수 호출의 경우에 마이크로프로세서의 모든 데이터를 일시적으로 저장할 것이다. %ES: 이것은 엑스트라 세그먼트이다. 이것은 스트링 관리를 위해 프로세서에 의해 사용되어진다. 이 경우에, ES와 DI는 목적지 주소를 지시할 것이다. %DS: 이것은 데이터 세그먼트로 SP, BP, IP를 제외한 다른 모든 세그먼트와 연결된다. %FS: ES와 같다. %GS: ES와 같다. (역주: 이러한 레지스터들은 Context switch에 Selector로 사용되어진다. 리눅스 커널부분에 참조하기 바람) 3.3.3: Offset Registers: ------------------------ %ESP: 확장된 스택 포인터, 이것은 우리의 스택의 젤 윗부분이다. %EBP: 확장된 베이스 포인터, 함수의 지역 환경의 시작을 가리킬 것이다. %EDI: 확장된 목적지 인덱스, 메모리 블록의 사용하는 오퍼레이션에서 오프셋을 저장한다. %ESI: 확장된 소스 인덱스, 오퍼레이션이 이것을 사용할 때 메모리 블록의 시작부분을 지시할 것이다. %EIP: 확장된 인스트럭션(명령) 포인터, 실행한 다음 명령의 주소를 가리킨다. 3.4: The stack: --------------- 함수가 호출될때마다, 우리는 스택에 함수에 대한 새로운 환경을 생성해야할 필요가 있을 것이다. 우리는 파라메터와 지역 변수값들을 저장할 공간을 생성할 것이다. 실제로, 함수의 핵심은 값이 저장되고 변경되는 이러한 스택의 작은 부분이다. 함수의 나머지(모든 명령어)은 .text 헤더 섹션에 있다. 나는 함수, 포인터 혹은 동적 변수가 호출될 때 스택과 힙의 관리의 모든 측면을 설명하기 위해 아래의 코드를 사용할 것이다. funcinmem.c ----------- int iGlobalInit = 1; int iGlobalUnInit; char *szGlobalP; void function(char *cParameter, int iParameter) { int iLocalInit = 1; int iLocalUnInit; char szHelloString[12] = "Hello World!"; char *szLocalP; iParameter = 5; iLocalUnInit = iParameter; iGlobalUnInit = iLocalUnInit+1; szGlobalP = (char*)malloc( 12 * sizeof(char)); strncpy(szGlobalP,"Hello World!",12); szLocalP = (char*)malloc( 12 * sizeof(char)); strncpy(szLocalP,"Hello World!",12); return; } int main(int argc, char **argv) { int iMainLocalInit = 2; function("test",0); iMainLocalInit += 1; iGlobalInit += iMainLocalInit; printf("iMainLocalInit = %d\n",iMainLocalInit); } ------ 3.4.2: Stack management when calling a procedure: ------------------------------------------------- 함수는 3개의 기본적인 부분들로 나누어진다: 1- 함수 호출: 모든 파라미터들은 스택에 푸시되고 명령어 포인터(IP)는 우리의 함수 호출이 끝난후에 명령어 프로세싱을 계속하기 위해 저장되어진다. 2- 프롤로그: 함수 시작시에, 우리는 함수가 시작하기 전에 나타났던 것같은 스택의 상태를 저장할 것이다. 그 이후에, 우리는 우리의 더 많은 함수 호출에 대한 메모리중의 상태를 비축할 것이다. 3- 함수 리턴: 함수가 호출되기 이전에 나타났던 것처럼 모든 것을 놓는다. 지금, main()과 function()프로시저를 디스어셈블하자 노트1: 나는 이 장에서 이러한 경청(listening)을 항상 언급할 것이다. 그것들은 살펴보는데 주저하지 마라 ------ (gdb) disassemble main Dump of assembler code for function main: 0x8048270
: push %ebp 0x8048271 : mov %esp,%ebp 0x8048273 : sub $0x8,%esp 0x8048276 : movl $0x2,0xfffffffc(%ebp) 0x804827d : sub $0x8,%esp 0x8048280 : push $0x0 0x8048282 : push $0x808e3d5 0x8048287 : call 0x80481e0 0x804828c : add $0x10,%esp 0x804828f : lea 0xfffffffc(%ebp),%eax 0x8048292 : incl (%eax) 0x8048294 : mov 0xfffffffc(%ebp),%eax 0x8048297 : add %eax,0x809cef0 0x804829d : sub $0x8,%esp 0x80482a0 : pushl 0xfffffffc(%ebp) 0x80482a3 : push $0x808e3da 0x80482a8 : call 0x804872c 0x80482ad : add $0x10,%esp 0x80482b0 : leave 0x80482b1 : ret End of assembler dump. ------ ------ (gdb) file funcinmem Reading symbols from funcinmem...done. (gdb) disassemble function Dump of assembler code for function function: 0x80481e0 : push %ebp 0x80481e1 : mov %esp,%ebp 0x80481e3 : push %edi 0x80481e4 : push %esi 0x80481e5 : sub $0x30,%esp 0x80481e8 : movl $0x1,0xfffffff4(%ebp) 0x80481ef : lea 0xffffffd8(%ebp),%edi 0x80481f2 : mov $0x808e3c8,%esi 0x80481f7 : cld 0x80481f8 : mov $0x3,%ecx 0x80481fd : repz movsl %ds:(%esi),%es:(%edi) 0x80481ff : movl $0x5,0xc(%ebp) 0x8048206 : mov 0xc(%ebp),%eax 0x8048209 : mov %eax,0xfffffff0(%ebp) 0x804820c : mov 0xfffffff0(%ebp),%eax 0x804820f : inc %eax 0x8048210 : mov %eax,0x809f8c4 0x8048215 : sub $0xc,%esp 0x8048218 : push $0xc 0x804821a : call 0x8048d78 <__libc_malloc> 0x804821f : add $0x10,%esp 0x8048222 : mov %eax,%eax 0x8048224 : mov %eax,0x809f8c8 0x8048229 : sub $0x4,%esp 0x804822c : push $0xc 0x804822e : push $0x808e3c8 0x8048233 : pushl 0x809f8c8 0x8048239 : call 0x804cbdc 0x804823e : add $0x10,%esp 0x8048241 : sub $0xc,%esp 0x8048244 : push $0xc 0x8048246 : call 0x8048d78 <__libc_malloc> 0x804824b : add $0x10,%esp 0x804824e : mov %eax,%eax 0x8048250 : mov %eax,0xffffffd4(%ebp) 0x8048253 : sub $0x4,%esp 0x8048256 : push $0xc 0x8048258 : push $0x808e3c8 0x804825d : pushl 0xffffffd4(%ebp) 0x8048260 : call 0x804cbdc 0x8048265 : add $0x10,%esp 0x8048268 : lea 0xfffffff8(%ebp),%esp 0x804826b : pop %esi 0x804826c : pop %edi 0x804826d : pop %ebp 0x804826e : ret End of assembler dump. ------ 3.4.2.1: The call: ------------------ 이것은 우리의 함수 호출의 어셈블리 코드이다: ----------------------------------------------- 0x8048280 : push $0x0 0x8048282 : push $0x808e3d5 0x8048287 : call 0x80481e0 ------ 함수호출 프로시저는 호출되어진 함수에게 모든 아큐먼트들을 전달할 것이고 호출된 함수가 된 후에 정상적인 프로그램 수행을 계속하기 위해서 호출되어진 함수를 저장하는 주소메모리(%EIP)를 저장할 것이다. 오케이, GDB 락을 걸어보자: ------ (gdb) break *0x8048280 Breakpoint 1 at 0x8048280: file funcinmem.c, line 30. (gdb) run Starting program: /root/prog/funcinmem Breakpoint 1, 0x08048280 in main (argc=1, argv=0xbffffa84) at funcinmem.c:30 warning: Source file is more recent than executable. 30 function("test",0); (gdb) info register esp esp 0xbffffa08 0xbffffa08 (gdb) stepi 0x08048282 30 function("test",0); (gdb) info register esp esp 0xbffffa04 0xbffffa04 (gdb) stepi 0x08048287 30 function("test",0); (gdb) info register esp esp 0xbffffa00 0xbffffa00 ------ 먼저, 나는 우리의 레지스터 상태를 얻기위한 시간을 가지기 위한 어셈블리 명령의 실행전에 GDB를 멈추기 위한 "push $0x0"에 브레이크포인터를 두었다. 그 이후, 우리의 "functinmem" 프로그램을 실행하였다. "call"명령전의 두 "push"명령어들은 우리의 아큐먼트들을 스택에 놓을 것이다. %ESP 레지스터는 그리고나서 스택의 2 dword만큼 아래쪽으로 옮겨질 것이다. | | | | | | | | | | | | |---------------| |---------------| X | | <-- %ebp 0xbffffa18| | <-- %ebp |---------------| |---------------| | | | | | | | | | | | | |---------------| |---------------| Y | | 0xbffffa08| | |---------------| |---------------| | 0 | 0xbffffa04| 0x0 | |---------------| |---------------| | test | <-- %esp 0xbffffa00| 0x808e3d5 | <-- %esp |---------------| |---------------| | | | | | | | | | | | | ------ 그림 3.1 ------ (gdb) x/4c 0x808e3d5 0x808e3d5 <_IO_stdin_used+17>: 116 't' 101 'e' 115 's' 116 't' (gdb) info symbol 0x808e3d5 _IO_stdin_used + 17 in section .rodata ------ 나는 메모리에 이 주소가 궁금했다. 그것은 내가 이 주소에서 메모리를 검사했고 메모리에 "test" 아규먼트 스트링을 저장하는 장소가 있다는 것을 확인했기 때문이다. 나는 또한 이 스트링이 ELF 실행 파일 포맷의 .rodata(read only dat) 헤더 섹션에 있다는 것을 발견했다! ------ (gdb) stepi function (cParameter=0x1
, iParameter=-1073743228) at funcinmem.c:6 6 { (gdb) info register esp esp 0xbffff9fc 0xbffff9fc (gdb) info register eip eip 0x80481e0 0x80481e0 (gdb) info register esp esp 0xbffff9fc 0xbffff9fc (gdb) x 0xbffff9fc 0xbffff9fc: 0x0804828c (gdb) x 0x0804828c 0x804828c : 0x8d10c483 (gdb) disassemble main+28 ... 0x8048287 : call 0x80481e0 0x804828c : add $0x10,%esp ... ------ 지금, 우리는 "call 0x80481e0 "명령을 실행하였다. %EIP는 "function" 프로시저 리턴후에 우리의 프로그램의 정상 실행을 계속하기 위해 스택에 푸시되었다. 그 이후, 우리 프로시저 (0x80481e0 (push %ebp))의 첫번째 명령은 %EIP에 놓여졌다. 그 이후, 그것에 의해 이 명령은 실행되었다. %ESP는 메모리 다른 dword 아래방향으로 옮겨졋는데, 왜? 나는 주소 0xbffff9fc에서 우리의 %ESP 레지스터의 메모리 주소를 검사하였다. 나는 0x8d10c483 메모리 주소에서 이 주소 포인터를 발견했다. 나는 마지막으로 이 주소가 우리의 메인 함수의 "add $0x10,%esp" 명령의 주소임을 발견하기 위해 이 메모리를 디스어셈블하였다. 알아냈다! 이것은 우리의 "function" 프로시저의 리턴 후에 실행되어질 다음 명령의 주소이다! %EIP 레지스터는 0x80481e0에 할당되기 전에 "call"명령에 의해 스택에 명시적으로 푸시되어진다. | | | | | | | | | | | | |---------------| |---------------| X | | <-- %ebp 0xbffffa18| | <-- %ebp |---------------| |---------------| | | | | | | | | | | | | |---------------| |---------------| Y | | 0xbffffa08| | |---------------| |---------------| | 0 | 0xbffffa04| 0x0 | |---------------| |---------------| | test | 0xbffffa00| 0x808e3d5 | |---------------| |---------------| | Z | <-- %esp 0xbffff9fc| 0x0804828c | <-- %esp |---------------| |---------------| | | | | | | | | z= 프로그램의 정상 실행을 계속하기 위한 프로시저 호출 후의 팝(pop)하기 위한 주소 ------ 그림 3.2 ------ 3.4.2.2: The Prologue: ---------------------- 이것은 우리의 프롤로그의 어셈블리 코드이다: ------------------------------------------ 0x80481e0 : push %ebp 0x80481e1 : mov %esp,%ebp 0x80481e3 : push %edi 0x80481e4 : push %esi 0x80481e5 : sub $0x30,%esp ------ 오케이, GDB 락을 걸어보자: ------ (gdb) break *0x80481e0 Breakpoint 1 at 0x80481e0: file funcinmem.c, line 6. (gdb) run Starting program: /root/prog/funcinmem Breakpoint 1, function (cParameter=0x1
, iParameter=-1073743228) at funcinmem.c:6 6 { ------ 먼저, 나는 우리의 프롤로그 어셈블리 코드의 첫번째라인에 브레이크포인트를 두었고 프로그램을 시작했다. 프로그램 실행은 우리의 첫번째 브레이크포인트에서 멈췄다, "push %ebp"명령(기억하라, 푸시 명령은 이 시점에서 호출되지 않고, 브레이크포인트는 푸시 명령 후에 호출되어진다) ------ (gdb) info register ebp ebp 0xbffffa18 0xbffffa18 (gdb) info register esp esp 0xbffff9fc 0xbffff9fc ------ 우리의 X 메모리 주소에 %EBP 레지스터 포인터와 Y 메모리 주소에 %ESP가 있다. ------ | | | | | | | | | | | | |---------------| |---------------| X | | <-- %ebp 0xbffffa18| | <-- %ebp |---------------| |---------------| | | | | | | | | | | | | |---------------| |---------------| Y | | <-- %esp 0xbffff9fc| | <-- %esp |---------------| |---------------| | | | | | | | | | | | | | | | | | | | | ------ Figure 3.3 ------ (gdb) stepi 0x080481e1 6 { (gdb) info register ebp ebp 0xbffffa18 0xbffffa18 (gdb) info register esp esp 0xbffff9f8 0xbffff9f8 ------ 우리는 "stepi" GDB 명령과 함께 마지막 명령(push %ebp)을 실행하였다. 우리는 스택 현재 %EBP 위치에 푸시함으로써 현재 환경을 저장할 것이다. 그리고 나서, %ESP 레지스터는 한 dword 감소할 것인데 왜냐하면 %EBP를 스택에 푸시했기 때문이다. 이것은 "push %ebp" 명령 호출후에 %ESP 레지스터 위치의 변화를 볼 수 있기 때문이다: 0xbffff9fc - 0xbffff9f8 ---------- 0x00000004 ( A dword ) ------ | | | | | | | | | | | | |---------------| |---------------| X | | <-- %ebp 0xbffffa18| | <-- %ebp |---------------| |---------------| | | | | | | | | | | | | |---------------| |---------------| Y | | 0xbffff9fc| | |---------------| |---------------| | X | <-- %esp 0xbffff9f8| 0xbffffa18 | <-- %esp |---------------| |---------------| | | | | | | | | | | | | ------ Figure 3.4 ------ (gdb) stepi 0x080481e3 in function (cParameter=0x808e3d5 "test", iParameter=0) at funcinmem.c:6 6 { (gdb) info register ebp ebp 0xbffff9f8 0xbffff9f8 (gdb) info register esp esp 0xbffff9f8 0xbffff9f8 ------ "stepi" GDB 명령을 호출함으로써 "mov %esp,%ebp" 어셈블리 명령을 실행되었다. 이것은 %EBP 레지스터를 %ESP 레지스터로 옮길 것이다. 이것은 우리의 호출된 프로시저에 대해 새로운 환경을 생성할 것이다. %ESP와 %EBP 포인터 둘다 동일한 과거 환경 주소상에서 새로운 환경을 생성할 것이다. ------ | | | | | | | | | | | | |---------------| |---------------| X | | 0xbffffa18| | |---------------| |---------------| | | | | | | | | | | | | |---------------| |---------------| Y | | 0xbffff9fc| | |---------------| |---------------| | X | <-- %esp 0xbffff9f8| 0xbffffa18 | <-- %esp |---------------| |-%ebp |---------------| |-%ebp | | | | | | | | | | | | ------ Figure 3.5 ------ (gdb) stepi 0x080481e4 6 { (gdb) info register esp esp 0xbffff9f4 0xbffff9f4 (gdb) stepi 0x080481e5 6 { (gdb) info register esp esp 0xbffff9f0 0xbffff9f0 ------ 우리는 %EDI와 %ESI을 스택에 푸시함으로써 그것들의 상태를 저장한다. | | | | | | | | | | | | |---------------| |---------------| X | | 0xbffffa18| | |---------------| |---------------| | | | | | | | | | | | | |---------------| |---------------| Y | | 0xbffff9fc| | |---------------| |---------------| | X | <-- %ebp 0xbffff9f8| 0xbffffa18 | <-- %ebp |---------------| |---------------| | V | 0xbffff9f4| 0x1 | |---------------| |---------------| | W | <-- %esp 0xbffff9f0| 0xbffffa84 | <-- %esp |---------------| |---------------| | | | | | | | | | | | | | | | | ------ V = %EDI W = %ESI Figure 3.6 ------ 아래는 모든 지역과 동적 변수 선언들과 스택 프레임을 널값 dword로 패딩함으로써 컴파일러에 의해 정렬된 후에 스택 레이아웃이다. (gdb) break *0x8048265 Breakpoint 3 at 0x8048265 (gdb) run Starting program: /root/prog/funcinmem Breakpoint 1, 0x08048265 in function (cParameter=0x808e3d5 "test", iParameter=5) at funcinmem.c:21 21 strncpy(szLocalP,"Hello World!",12); (gdb) info register ebp ebp 0xbffff9f8 0xbffff9f8 (gdb) info register esp esp 0xbffff9b0 0xbffff9b0 (gdb) x 0xbffff9f8 0xbffff9f8: 0xbffffa18 ------ 우리의 main()함수의 저장된 환경 ------ (gdb) x 0xbffff9f4 0xbffff9f4: 0x00000001 ------ Saved %EDI 저장된 %EDI ------ (gdb) x 0xbffff9f0 0xbffff9f0: 0xbffffa84 ------ 저장된 %ESI ------ (gdb) x 0xbffff9ec 0xbffff9ec: 0x00000001 ------ iLocalInit ------ (gdb) x 0xbffff9e8 0xbffff9e8: 0x00000005 ------ iLocalUnInit = iParameter; ------ (gdb) x 0xbffff9e4 0xbffff9e4: 0x00000000 ------ Padding ------ (gdb) x 0xbffff9e0 0xbffff9e0: 0x00000000 ------ Padding ------ (gdb) x 0xbffff9dc 0xbffff9dc: 0x00000000 ------ Padding ------ (gdb) x 0xbffff9d8 0xbffff9d8: 0x21646c72 ------ szHelloString ( First DWord ) ------ (gdb) x 0xbffff9d4 0xbffff9d4: 0x6f57206f ------ szHelloString ( Second DWord ) ------ (gdb) x 0xbffff9d0 0xbffff9d0: 0x6c6c6548 ------ szHelloString ( Last DWord ) ------ (gdb) x 0xbffff9cc 0xbffff9cc: 0x080a00d8 ------ szLocalP ------ (gdb) x 0xbffff9c8 0xbffff9c8: 0x00000000 ------ Padding ------ (gdb) x 0xbffff9c4 0xbffff9c4: 0x00000000 ------ Padding ------ (gdb) x 0xbffff9c0 0xbffff9c0: 0x00000000 ------ Padding ------ 위는 모든 지역과 동적 변수 선언들과 스택 프레임을 널값 dword로 패딩함으로써 컴파일러에 의해 정렬된 후에 스택 매핑이다. 0x80481e5 : sub $0x30,%esp 이 명령에 의해, 우리는 우리의 지역 변수들은 넣기 위한 스택에 12 dword를 비축할 것이다. 잊지마라, 스택은 dword(4바이트 혹은 32비트)로 관리되어진다. 만약 dword가 채워지지 않으면, 사용되지 않은 바이트에 대해 0x0 값이 할당되어진다. | | | | | | | | | | | | |---------------| |---------------| X | | 0xbffffa18| | |---------------| |---------------| | | | | | | | | | | | | |---------------| |---------------| Y | | 0xbffff9fc| | |---------------| |---------------| | X | <-- %ebp 0xbffff9f8| 0xbffffa18 | <-- %ebp |---------------| |---------------| | V | 0xbffff9f4| 0x1 | |---------------| |---------------| | W | 0xbffff9f0| 0xbffffa84 | |---------------| |---------------| | Allocated | 0xbffff9ec| | |---------------| |---------------| | Allocated | 0xbffff9e8| | |---------------| |---------------| | Allocated | 0xbffff9e4| | |---------------| |---------------| | Allocated | 0xbffff9e0| | |---------------| |---------------| | Allocated | 0xbffff9dc| | |---------------| |---------------| | Allocated | 0xbffff9d8| | |---------------| |---------------| | Allocated | 0xbffff9d4| | |---------------| |---------------| | Allocated | 0xbffff9d0| | |---------------| |---------------| | Allocated | 0xbffff9cc| | |---------------| |---------------| | Allocated | 0xbffff9c8| | |---------------| |---------------| | Allocated | 0xbffff9c4| | |---------------| |---------------| | Allocated | <-- %esp 0xbffff9c0| | <-- %esp |---------------| |---------------| V = %EDI W = %ESI ------ Figure 3.7 그 이후, 메모리 할당, 우리는 그것들안에 우리의 변수의 값을 넣을 것이다. 메모리의 현재 모습은 다음과 같다: | | | | | | | | | | | | |---------------| |---------------| X | | 0xbffffa18| | |---------------| |---------------| | | | | | | | | | | | | |---------------| |---------------| Y | | 0xbffff9fc| | |---------------| |---------------| | X | <-- %ebp 0xbffff9f8| 0xbffffa18 | <-- %ebp |---------------| |---------------| | V | 0xbffff9f4| 0x1 | |---------------| |---------------| | W | 0xbffff9f0| 0xbffffa84 | |---------------| |---------------| | iLocalInit | 0xbffff9ec| 0x00000001 | |---------------| |---------------| | iLocalUnInit | 0xbffff9e8| 0x00000005 | |---------------| |---------------| | [Padding] | 0xbffff9e4| 0x00000000 | |---------------| |---------------| | [Padding] | 0xbffff9e0| 0x00000000 | |---------------| |---------------| | [Padding] | 0xbffff9dc| 0x00000000 | |---------------| |---------------| | szHelloString | 0xbffff9d8| 0x21646c72 | "!dlr" |---------------| |---------------| | szHelloString | 0xbffff9d4| 0x6f57206f | "oW o" |---------------| |---------------| | szHelloString | 0xbffff9d0| 0x6c6c6548 | "lleH" |---------------| |---------------| | szLocalP | 0xbffff9cc| 0x080a00d8 | |---------------| |---------------| | [Padding] | 0xbffff9c8| 0x00000000 | |---------------| |---------------| | [Padding] | 0xbffff9c4| 0x00000000 | |---------------| |---------------| | [Padding] | <-- %esp 0xbffff9c0| 0x00000000 | <-- %esp |---------------| |---------------| V = %EDI W = %ESI ------ Figure 3.8 오케이, 거기에 우리의 약간의 설명이 필요하다. 우리는 이러한 지역 변수들을 가진다: ------ int iLocalInit = 1; /* Will take 1 dword in the stack */ int iLocalUnInit; /* Will take 1 dword in the stack */ char szHelloString[12] = "Hello World!"; /* Will take 4 dwords in the stack In reality, 3 dwords + 1 byte but, don't forgot, the stack is devised in dwords not in bytes. */ char *szLocalP; /* Will take 1 dword in the stack */ ------ 이 경우에, %ESP는 단지 12가 아니라 7 dword만큼 감소되어질 것으로 예상된다. 이것은 이론적인 경우이지 실제로는 이렇지 않다. 스택 할당 길이는 컴파일러, 운영체제, 구조에 따라 변화할 것이다. 사실, 컴파일러는 적절한 내부 정렬을 위해 스택 프레임을 패딩할 것이다. 이것은 우리가 0x00000000으로 패딩된 5 dwords를 가지기 때문이다. 예에 의해: 만약 stdint.h에 부호화된 인터져가 32비트(int32_t)가 아니라 16비트(int16_t)로 정의되어지고, 당신은 우리의 예제와 같지 않게 하나의 dword안에 2개의 부호화된 인티저를 놓을 수 있을 것이다. 3.4.2.3: The return: -------------------- 리턴 프로시저는 우리의 프로그램 함수 호출이전에 표현되었던 환경을 복귀할 것이다. 우리의 예제에서, 우리의 main() 프로시저의 환경은 function() 프로시저 호출이전과 같이 같은 값들로 복귀되어질 것이다. 리턴 프로시저에 대한 어셈블리 코드가 있다: --------------------------------------------------- 0x8048268 : lea 0xfffffff8(%ebp),%esp 0x804826b : pop %esi 0x804826c : pop %edi 0x804826d : pop %ebp 0x804826e : ret ------ 오케이, 또 다른 시간에 GDB 락을 걸어보자! ------ (gdb) break *0x8048268 Breakpoint 1 at 0x8048268: file funcinmem.c, line 24. (gdb) run Starting program: /root/prog/funcinmem Breakpoint 1, function (cParameter=0x808e3d5 "test", iParameter=5) at funcinmem.c:24 warning: Source file is more recent than executable. 24 } (gdb) info register ebp ebp 0xbffff9f8 0xbffff9f8 (gdb) info register esp esp 0xbffff9c0 0xbffff9c0 ------ 먼저, 나는 "lea 0xfffffff8(%ebp),%esp" 명령어에 브레이크포인트를 걸었다. 그 이후 나는 이 명령의 실행 이전의 %ESP와 %EBP 레지스터 상태를 체크하였다. ------ (gdb) stepi 0x0804826b 24 } (gdb) info register ebp ebp 0xbffff9f8 0xbffff9f8 (gdb) info register esp esp 0xbffff9f0 0xbffff9f0 ------ 나는 "stepi" gdb 명령을 사용하여 "lea" 명령을 실행하였다. 그 다음에 나는 %ESP와 %EBP레지스터 의 상태를 다시 체크하였다. %ESP는 변했다. 그 값은 스택에서 증가하였다. 지금 스택은 다음과 같이 보인다: | | | | | | | | | | | | |---------------| |---------------| X | | 0xbffffa18| | |---------------| |---------------| | | | | | | | | | | | | |---------------| |---------------| Y | | 0xbffff9fc| | |---------------| |---------------| | X | <-- %ebp 0xbffff9f8| 0xbffffa18 | <-- %ebp |---------------| |---------------| | V | 0xbffff9f4| 0x1 | |---------------| |---------------| | W | <-- %esp 0xbffff9f0| 0xbffffa84 | <-- %esp |---------------| |---------------| | iLocalInit | 0xbffff9ec| 0x00000001 | |---------------| |---------------| | iLocalUnInit | 0xbffff9e8| 0x00000005 | |---------------| |---------------| | [Padding] | 0xbffff9e4| 0x00000000 | |---------------| |---------------| | [Padding] | 0xbffff9e0| 0x00000000 | |---------------| |---------------| | [Padding] | 0xbffff9dc| 0x00000000 | |---------------| |---------------| | szHelloString | 0xbffff9d8| 0x21646c72 | "!dlr" |---------------| |---------------| | szHelloString | 0xbffff9d4| 0x6f57206f | "oW o" |---------------| |---------------| | szHelloString | 0xbffff9d0| 0x6c6c6548 | "lloH" |---------------| |---------------| | szLocalP | 0xbffff9cc| 0x080a00d8 | |---------------| |---------------| | [Padding] | 0xbffff9c8| 0x00000000 | |---------------| |---------------| | [Padding] | 0xbffff9c4| 0x00000000 | |---------------| |---------------| | [Padding] | 0xbffff9c0| 0x00000000 | |---------------| |---------------| V = %EDI W = %ESI ------ Figure 3.9 오케이, 우리는 %ESP를 스택의 12 dwords만큼 놓았다! 우리는 스택을 그것의 전의 레이아웃, 동적과 지역 변수들에 대한 메모리 할당전과 같이, 으로 회복한다. ------ (gdb) info register edi edi 0xbffff9dc -1073743396 (gdb) info register esi esi 0x808e3d4 134800340 (gdb) info register esp esp 0xbffff9f0 0xbffff9f0 (gdb) stepi 0x0804826c 24 } (gdb) info register edi edi 0xbffff9dc -1073743396 (gdb) info register esi esi 0xbffffa84 -1073743228 (gdb) info register esp esp 0xbffff9f4 0xbffff9f4 (gdb) stepi 0x0804826d 24 } (gdb) info register edi edi 0x1 1 (gdb) info register esi esi 0xbffffa84 -1073743228 (gdb) info register esp esp 0xbffff9f8 0xbffff9f8 ------ 먼저, %ESI는 스택으로부터 팝되었고, 그리고나서, %ESP는 스택에서 한 dword만큼 증가되었다. 그 다음에, %EDI는 또한 스택에서 팝되어지고, 그리고 나서, %ESP는 또다른 dword만큼 스택에서 증가되었다. 그래서, %ESI와 %EDI는 지금 function() 프로시저 호출이전에 main() 프로시저의 환경에 있던 이전 값을 가진다. 스택은 다음과 같이 보인다: | | | | | | | | | | | | |---------------| |---------------| X | | 0xbffffa18| | |---------------| |---------------| | | | | | | | | | | | | |---------------| |---------------| Y | | 0xbffff9fc| | |---------------| |---------------| | X | <-- %ebp 0xbffff9f8| 0xbffffa18 | <-- %ebp |---------------| |%esp |---------------| |%esp | V | 0xbffff9f4| 0x1 | |---------------| |---------------| | W | 0xbffff9f0| 0xbffffa84 | |---------------| |---------------| | iLocalInit | 0xbffff9ec| 0x00000001 | |---------------| |---------------| | iLocalUnInit | 0xbffff9e8| 0x00000005 | |---------------| |---------------| | [Padding] | 0xbffff9e4| 0x00000000 | |---------------| |---------------| | [Padding] | 0xbffff9e0| 0x00000000 | |---------------| |---------------| | [Padding] | 0xbffff9dc| 0x00000000 | |---------------| |---------------| | szHelloString | 0xbffff9d8| 0x21646c72 | "!dlr" |---------------| |---------------| | szHelloString | 0xbffff9d4| 0x6f57206f | "oW o" |---------------| |---------------| | szHelloString | 0xbffff9d0| 0x6c6c6548 | "lloH" |---------------| |---------------| | szLocalP | 0xbffff9cc| 0x080a00d8 | |---------------| |---------------| | [Padding] | 0xbffff9c8| 0x00000000 | |---------------| |---------------| | [Padding] | 0xbffff9c4| 0x00000000 | |---------------| |---------------| | [Padding] | 0xbffff9c0| 0x00000000 | |---------------| |---------------| V = %EDI W = %ESI ------ Figure 3.10 ------ (gdb) info register ebp ebp 0xbffff9f8 0xbffff9f8 (gdb) info register esp esp 0xbffff9f8 0xbffff9f8 (gdb) stepi 0x0804826e in function (cParameter=0x1
, iParameter=-1073743228) at funcinmem.c:24 24 } (gdb) info register ebp ebp 0xbffffa18 0xbffffa18 (gdb) info register esp esp 0xbffff9fc 0xbffff9fc ------ %ESP와 %EBP 레지스터는 동일한 메모리 주소에 있다. 그 다음에 %EBP가 스택으로부터 팝되어진다. 이 팝핑의 결과는 %EBP는 현재 그것의 과거 메모리 위치를 가리키는 것이다. 이 팝 명령어에 의해서, %ESP 레지스터는 메모리에서 1 dword만큼 증가되면서 지금 이것은 그것의 이전 메모리 주소를 또한 가리킨다! ------ (gdb) info register esp esp 0xbffff9fc 0xbffff9fc (gdb) info register eip eip 0x804826e 0x804826e (gdb) stepi 0x0804828c in main (argc=1, argv=0xbffffa84) at funcinmem.c:30 30 function("test",0); (gdb) info register esp esp 0xbffffa00 0xbffffa00 (gdb) info register eip eip 0x804828c 0x804828c ------ 만약 섹션 3.4.2.1에서 기억한마면, 호출 명령은 %EIP를 스택에 푸시한다. 그래서, "ret" 명령은 명시적으로 스택의 %EIP 레지스터를 "pop"할 것이다. 그리고나서, %ESP는 메모리 스택에서 또다른 dword만큼 증가되고 function() 프로시저의 이전 첫번째 파라미터에 지금 포인팅되고 있다. 마지막으로, %EIP는 main()프로시저의 다음 명령을 실행하기 위해 준비되어진다. | | | | | | | | | | | | |---------------| |---------------| X | | <-- %ebp 0xbffffa18| | <-- %ebp |---------------| |---------------| | | | | | | | | | | | | |---------------| |---------------| Y | | 0xbffffa08| | |---------------| |---------------| | 0 | 0xbffffa04| 0x0 | |---------------| |---------------| | test | 0xbffffa00| 0x808e3d5 | <-- %esp |---------------| |---------------| | Z | <-- %esp 0xbffff9fc| 0x0804828c | |---------------| |---------------| | | | | | | | | ------ Figure 3.11 3.5: The Heap: -------------- 힙은 응용프로그램에 의해 동적으로 할당되는 메모리 영역이다. 우리가 알다시피, 초기화되지 않은 전역 변수는 .bss ELF 헤더 섹션에 정의되어진다. 반대로, 초기화되지 않은 지역변수는 스택에 정의되어진다(우리가 위에서 보았듯이). 힙은 만약 할당되어야 할 메모리 영역의 길이가 컴파일시에 알려지지 않는다면 나타날 것이다. 사실, 정수의 길이는 컴파일시에 알려진다. stdint.h에 그것의 정의의 의존하며, x86 구조에서 정수의 길이는 32비트가 될 것이다. 그래서, 비초기화된 전역 정수의 값은 .bss세그먼트에 저장되어질 것이고 비초기화된 지역 정수는의 경우에, 그 값은 스택에 저장되어질 것이다. 그러나, 이것은 동적 변수에 대한 경우는 아니다. 동적 변수의 정의를 기억하라: 동적 변수는 포인터에 의해 지시되는 메모리 영역이다. 만약 우리가 이러한 두가지 정의를 함께 사용한다면, 동적변수는 힙에 놓이게 될 것이고, 왜냐하면 동적 변수는 프로그램의 실행 중에 동적으로 변할 수 있고, 힙은 힙영역에 언제든지 메모리를 동적으로 할당할 수도록 구조화되어있기 때문이다. 그러나 잊지마라, 포인터는 메모리 블리이 메모리에 있는 곳의 주소이고, 포인터의 길이는 이 경우에, 컴파일시에(32비트) 알려지고, 전역과 지역 변수는 항상 각각 .bss와 스택 영역(정수와 같은)에 정의되어질 것이다. 우리의 지역과 전역 변수들 초기화된 후에 .bss 섹션이 무엇처럼 생겼는지가 있다. | | | Heap | 0x809fe04|---------------| | | <---- /// /// | | | | |---------------| | 0x809f8c8| szGlobalP | | BSS |---------------| | Segment 0x809f8c4| iGlobalUnInit | | |---------------| | | | | /// /// | | | <---- 0x809ee80|---------------| | Data | | | ------ Figure 3.12 우리의 두 비초기화된 전역 변수는 지금 .bss 헤더 섹션에 있다. 그러나 지금, 우리는 function()프로시저에 우리의 동적 변수의 초기화 후에 힙이 무엇과 같이 보일 것인지를 알기를 원한다. 예스, 다른 타임에 GDB 락을 걸어보자: 계속하기 전에, 당신은 힙은 사용자 스택 프레임이 스택과 같이 아래로 자라지 않고 위로 자란다는 것을 염두에 둘 필요가 있다. ------ (gdb) info symbol &szGlobalP szGlobalP in section .bss (gdb) print &szGlobalP $1 = (char **) 0x809f8c8 (gdb) print szGlobalP $2 = 0x80a00c8 "Hello World!\021" (gdb) x/4c 0x80a00c8 0x80a00c8: 72 'H' 101 'e' 108 'l' 108 'l' (gdb) x/4c 0x80a00cc 0x80a00cc: 111 'o' 32 ' ' 87 'W' 111 'o' (gdb) x/4c 0x80a00d0 0x80a00d0: 114 'r' 108 'l' 100 'd' 33 '!' (gdb) x/4c 0x80a00d4 0x80a00d4: 17 '\021' 0 '\000' 0 '\000' 0 '\000' (gdb) info symbol &szLocalP No symbol matches &szLocalP. (gdb) print &szLocalP $5 = (char **) 0xbffff9cc (gdb) print szLocalP $6 = 0x80a00d8 "Hello World!!\017" (gdb) x/4c 0x80a00d8 0x80a00d8: 72 'H' 101 'e' 108 'l' 108 'l' (gdb) x/4c 0x80a00dc 0x80a00dc: 111 'o' 32 ' ' 87 'W' 111 'o' (gdb) x/4c 0x80a00e0 0x80a00e0: 114 'r' 108 'l' 100 'd' 33 '!' (gdb) x/4c 0x80a00e4 0x80a00e4: 33 '!' 15 '\017' 0 '\000' 0 '\000' ------ 노트 1: szLocalP에 대해 정의된 어떤 심볼도 없는데 이는 이것이 스택에 정의되어 있기 때문이다. 마지막으로, 힙은 function() 프로시저의 실행 후에 이와 같이 보인다. 3 2 1 0 | | | Stack | |---------------| | | /// /// | | |---------------| 0x80a00e4|0x0|0x0|0x0|017| <--|-- |---------------| | 0x80a00e0| ! | d | l | r | | |---------------| | szLocalP 0x80a00dc| o | W |\32| o | | |---------------| | 0x80a00d8| l | l | e | H | <--|-- |---------------| 0x80a00d4|0x0|0x0|0x0|021| <--|-- |---------------| | 0x80a00d0| ! | d | l | r | | |---------------| | szGlobalP 0x80a00cc| o | W |\32| o | | |---------------| | 0x80a00c8| l | l | e | H | <--|-- |---------------| | | /// /// | | 0x809fe08|---------------| | BSS | | | ------ Figure 3.13 힙은 브레이크 포인트로써 언급되어진다. 만약 당신이 더 많은 동적인 메모리를 공유하는 것이 필요하다면, 당신은 브레이크 포인트를 옮겨야 할 필요가 있을 것이다. 시스템 호출은 응용프로그램이 더 많은 동적인 메모리를 필요로 한다는 것을 커널에게 말하는데 사용되어진다. 그리고나서, 커널은 약간의 루틴을 수행할 것인데, BRK 시스템 호출을 받은 후에, 이것은 더 많은 메모리를 할당하기 위해 사용자 스택 프레임에서 브레이크포인트를 위로 옮길 수 있는지를 알기 위해서이다. 만약 연산이 성공적이면, 커널은 모든 프로세스 테이블을 새로운 정보로 바꿀 것이고 힙 크기는 사용자 스택 프레임에서 증가할 것이다. 만약 BRK에 의해 요청된 할당에 대한 충분한 메모리가 없다면, 그러면 커널은 -1을 리턴하고 그 응용 프로그램은 동적인 변수에 대해서 메모리 할당을 할 수 없을 것이다. The Conclusion: -------------------------- 마지막으로, 나는 당신이 내가 해야만 했던 것들을 읽는 동일한 재미를 가지기를 바란다. 나는 프로그램이 메모리에 어떻게 맵핑되는지와 어떻게 수행되는지를 이해하기 많은 돕는 섹션과 또한 어떻게 프로그래밍의 기본 개념이 상위 레벨 프로그래밍 언어에서 동작되는지를 이해하기 위한 돕는 섹션이 있다. 나는 역시 "정밀조사"에 의한 이 방법이 개념을 이해하는데 가장 시각적이라고 생각한다. 위에서 사용된 방법들은 어떻게 상위 레벨 프로그램 언어가 동작하는지, 어떻게 어떤 컴파일러가 동작하는지 그리고 어떻게 구조가 동작하는지를 쉽게 이해하는데 사용될어진다. 예를 들어, 우리는 전역 변수가 메모리에서 매핑되는 것을 이해함으로써 시스템에서 전역변수의 효과를 쉽게 이해할 수 있다. 우리는 또한 응용프로그램을 디버깅하고 헤더에 정의된 변수가 어느 심볼에 있는지 검색함으로써 시스템에서 어떻게 C 변수 타입이 동작하는지를 이해할 수 있다. 또 우리는 만약 그 크기가 정적 혹은 동적인지, 먄약 변수가 전역 혹은 지역, 기타인지를 알 것이다. 프로그램이 메모리에 어떻게 매핑되는지를 이해하는것은 프로그램이 어떻게 실제로 동작하는지를 이해하는 것이다. 만약 어떤 질문, 코멘트, 첨가 혹은 알려주고 싶은 에러가 있다면, fred@decatomb.com 으로 이메일을 보내주기 바란다. 나의 서투른 영어에 대해 유감스럽게 생각하지만, 만약 당신이 문법 에러나 그것들에 대해 기꺼이 보고해주기 원하면, 나에게 연락해주기 바라고 텍스트를 기쁜 마음으로 변경할 것이다. ================================================================================ ================================================================================ 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 } ------ Bibliography: ------------- -Andrew S. Tanenbaum and Albert S. Woodhull, "Operating System, Design and Implementation. Second Edition", Prentice Hall, Upper Saddle River, New Jersy 07458, 1997, p.939. -David A Rusling, "The Linux Kernel", http://www.linuxdoc.org/LDP/tlk/tlk-title.html, 1999. -George F. Corliss,"Minix_book",http://www.mscs.mu.edu/~georgec/Classes/207.1998/14Minix_book/, 1998. Minix source snippets are: Copyright (c) 1987,1997, Prentice Hall. All rights reserved. (c) Copyright 2001 Fr??ick Giasson, All Rights Reserved