🐢 chap4. 프로세스 메모리 구조

⭐ 4.1 프로세스 메모리 레이아웃I

❓프로세스 내부의 메모리 및 메모리 구조를 다루어야 하는 이유?

→ C언어에서 메모리는 수동으로 관리를 해주어야 하므로 메모리 영역을 할당하거나, 더 이상 필요하지 않은 메모리를 해제 하는 일은 개발자만이 담당해주어야 하기 때문입니다.

☑️ 프로세스 = 실행중인 프로그램

→ 메모리에 로딩 (호출)이 되며, 특정 프로세스들을 구별하기 위한 고유번호인 PID (프로세스 식별자)를 가집니다.

→ 프로세스를 생성할 때 운영체제는 먼저 프로세스를 위한 메모리를 할당한 다음 메모리 레이아웃을 적용합니다.

☑️ 메모리 레이아웃

→ 프로세스의 메모리 레이아웃은 여러 부분으로 분할 됩니다. 이때 각 부분은 세그먼트라 합니다.

→ 세그먼트들은 정해진 작업을 수행하며 특정 자료형을 저장하는 메모리 영역입니다.

• 메모리 레이아웃 구조

  

  • 동적 메모리 레이아웃 세그먼트 = 스택 과 힙
  • 정적 메모리 레이아웃 세그먼트 = BSS, DATA, TEXT
  • 모든 메모리 할당과 해제는 이 세그먼트에서 일어납니다.

⭐ 4.2 메모리 구조 알아보기

☑️ 실행 가능한 목적 파일 vs 프로세스

	실행 가능한 목적 파일	프로세스
	기계 명령어를 포함하며 컴파일러에 의해 생성	실행 중인 프로그램이며 실행 가능한 목적 파일에 의해 스폰(프로세서를 호출)된 것
		메인 메모리 영역을 소비하며, CPU는 계속 메모리의 명령어를 가져와서 실행
세그먼트	실행 가능한 목적 파일에 탑재된 세그먼트	프로세스가 로딩되는 동안 만들어지는 세그먼트
	BSS , DATA , TEXT	스택 , 힙

☑️ 정적 메모리 레이아웃 vs 동적 메모리 레이아웃

레이아웃 종류	정적 메모리 레이아웃	동적 메모리 레이아웃
세그먼트	세그먼트의 집합	세그먼트의 집합
	BSS, DATA, TEXT	스택 , 힙
레이아웃 생성	실행 중인 프로세스의 메모리 아웃에서, 토대가 되는 실행 가능한 목적 파일에서 직접 생성	프로세스가 로딩될 때, 프로그램이 실행되는 동안 동적으로 생성
레이아웃 내용	내용은 소스 코드를 컴파일할 때 컴파일러가 실행 가능한 목적 파일에 미리 작성합니다.	내용은 프로그램의 명령어에 따라 작성
		프로그램 명령어 → 변수와 배열에 메모리를 할당하며, 프로그램의 로직에 따라 변수와 배열을 수정
레이아웃 내용을 추측 가능할까?	소스 코드나 컴파일된 목적 파일만 봐도 정적 메모리 레이아웃의 내용을 추측 가능	내용은 프로그램을 실행하지 않으면 결정되지 않으므로 쉽게 알 수 없음. 게다가 같은 실행 파일이더라도 실행할 때마다 내용이 달라짐
		동적 내용은 해당 프로세스마다 다르므로 프로세스가 실행되는 동안 검사가 이루어져야함

⭐ 4.3 정적 메모리 레이아웃 검사하기

☑️ 정적 메모리 레이아웃 검사하기

1. gcc를 사용해 컴파일하기

gcc ExtremeC_examples_chapter4_1.c -o ex4_1-linux.out

 → ex4_1-linux.out이라는 실행가능한 목적 파일이 만들어집니다. 향후 이 실행 파일에 기반해 스폰되는 모든 프로세스에 이 정적 메모리 레이아웃이 존재할 것 입니다.

1. size 명령어

• 실행 가능한 목적 파일의 정적 메모리 레이아웃을 출력할 때 사용합니다.

• 예제 4-1 linux.out의 정적 세그먼트를 살펴보는 사이즈 명령어의 사용

  size ex4_1-linux.out
  

  • 예제 4-1의 linux.out의 정적 세그먼트

    int main(int argc, char** argv) {
      return 0;
    }
    
    /*********************************************************
    text    data     bss     dec     hex filename
    110       0       0     110      6e ex4_1-linux.out
    *********************************************************/
    -> 표시된 숫자는 바이트 단위입니다.
    

☑️ BSS 세그먼트

BSS란 → 심벌로 시작되는 블록이라는 뜻

기본적으로 초기화되지 않은 전역 변수나 0으로 설정한 전역 변수에 BSS 세그먼트를 사용합니다.

역시적으로는 이 이름은 초기화되지 않은 워드를 위해 예약된 영역을 나타내고자 사용

• 예제 4-2 초기화되지 않았거나 0으로 설정된 전역 변수 몇 개를 갖는 프로그램

  int global_var1;
  int global_var2;
  int global_var3 = 0;
  
  int main(int argc, char** argv) {
    return 0;
  }
  
  /******************************************************
  text    data     bss     dec     hex filename
  110       0      12     122      7a ex4_2-linux.out
  ******************************************************/
  

  • 이때 golbal_var1, 2, 3는 초기화 되지않은 전역 변수

  • 아래 나와있는 값은 size 명령어를 사용

  gcc ExtremeC_example.chapter4_2.c -o ex4_2-linux.out
  
  size ex4_2-linux.out
  

  • 예제 4-1과 비교했을 때 BSS 세그먼트의 값의 크기가 바뀌었음을 알 수 있음 → BSS값이 12바이트가 증가한 이유는 초기화되지 않은 전역 변수 3개가 총 12바이트이 므로 12바이트가 증가했음 → 초기화되지 않았거나 0으로 설정한 전역 변수를 선언하면 BSS 세그먼트에 추가되는데 이러한 전역 변수들은 정적 레이아웃에 속하게 됩니다. → 프로세서가 로딩될 때 미리 할당 되고, 프로세스가 살아있는 한 절대로 할당이 해제되지 않음

☑️ 데이터 세그먼트

❓데이터 세그먼트를 사용하는 이유?

• 0이 아닌 값으로 설정되어 초기화된 전역 변수를 저장하기 위해 사용합니다.

• 초기화된 것과 초기화되지 않은 전역 변수를 가지는 프로그램

  int global_var1;
  int global_var2;
  int global_var3 = 0;
  
  double global_var4 = 4.5;
  char global_var5 = 'A';
  
  int main(int argc, char** argv) {
    return 0;
  }
  
  /*******************************************************
  text    data     bss     dec     hex filename
  110       9      12     131      83 ex4_3-linux.out
  *******************************************************/
  

  • 데이터 세그먼트에 저장되는 다양한 종류의 전역 변수를 알아보고자 0이 아닌 값으로 초기화된 전역 변수 2개를 예제 4-2에 추가했음

  gcc ExtremeC_examples_chapter4_3.c -o ex4_3-linux.out
  
  size ex4_3-linux.out
  

  • 예제 4-2와 예제 4-3을 비교했을 때 데이터 세그먼트가 9바이트로 증가한 것을 볼 수 있음 → 9바이트는 새로 추가된 전역 변수 2개(double- 8바이트 , char-1바이트) 8바이트와 1바이트를 더한 값입니다.

❓size 명령어는 세그먼트의 크기만을 보여줄 뿐 내용을 보여주지 않음

• 목적 파일에 있는 세그먼트의 내용을 검사할 때 사용하는 명령어를 사용합니다.

  ex) in Linux _ ELF 파일의 내용을 보는 redelf와 objdump 명령어를 사용해 목적 파일 내부의 정적 메모리 레이아웃을 이용합니다.

• 함수 내부에는 전역 변수 외에도 정적 변수도 존재하기 하고, 정적 변수는 플랫폼 및 초기화 여부에 따라 데이터 세그먼트 또는 BSS 세그먼트에 저장될 수 있음

• 초기화된 것과 초기화되지 않은 정적 변수 2개 선언

  void func (){       //정적 변수 j, i
  static int i;       //초기화되지 않은 i
  static int j = 1;   //초기화된 j
  }
  

  • 런타임 시에 func() 함수는 데이터 세그먼트와 BSS세그먼트에 위치한 두 변수로 접근합니다.

  • 정적 변수 i는 초기화 되지 않았으므로 BSS세그먼트에 존재하고, 정적 변수 J는 초기화 되었으므로 데이터 세그먼트내에 존재 해야합니다.

• 데이터 세그먼트에 작성된 초기화된 전역 변수

  int     x = 33;            // 0x00000021
  int     y = 0x12153467;
  char z[6] = "ABCDE";
  
  int main(int argc, char**argv) {
    return 0;
  }
  
  /********************************************************
  ex4_4.out:     file format elf64-x86-64
  
  Contents of section .data:
   4000 00000000 00000000 08400000 00000000  .........@......
   4010 21000000 67341512 41424344 4500      !...g4..ABCDE.
  *********************************************************/
  

  • BSS 세그먼트의 내용을 검사하는 두번째 명령어는 objdump입니다.

  gcc ExtremeC_examples_chapter4_4.c -o ex4_4.out
  
  objdump -s -j .data ex4_4.out
  

  • 왼쪽 첫 번째 열은 주소 열입니다.
  • 다음 4개의 열은 내용이며, 각각은 4바이트 크기의 데이터를 나타냅니다.(한 행에 16)
  • 오른쪽에 보이는 마지막 열은 중간 열에서 보이는 바이트와 같은 크기의 아스키 표현을 나타냅니다. 중간마다 보이는 점은 알파벳이나 숫자로 나타낼 수 없는 문자를 뜻합니다.
  • 주소 0x004010에서는 데이터 세그먼트의 내용을 나타냅니다. 첫번째 열은 변수 에 저장된 값, 두번째는 y에 저장된 값, 세번째는 z에 저장된 값입니다.
  • 변수 x 값인 33은 16진수로 0x00000021이 아닌 0x21000000으로 표현되었고 변수 y의 값인 0x12153467이 0x67341512로 되어있는것이 보입니다. → 이는 엔디언 개념으로 가장 작은 바이트인 67이 먼저 오므로 0x67341412로 표현이 됩니다. → 엔디언은 cpu의 속성이며, cpu가 다르면 최종 목적 파일에서 바이트 순서가 달라집니다. 이러한 이유로 다른 엔디언이 있는 하드웨어에서는 실행 가능한 목적 파일을 실행 할 수 없음
  • objdump에서 -s 옵션은 섹션의 모든 내용을 출력합니다.
  • objdump에서 -j .data옵션은 .data 섹션의 내용을 모두 출력하도록 합니다.

☑️ 텍스트 세그먼트 또는 코드 세그먼트

• 텍스트 세그먼트 또는 코드 세그먼트 프로그램의 모든 기계 수준 명령어를 포함

• 이는 실행 가능한 목적 파일에 위치해야 하고 명령어를 프로세서가 가져와서 프로세스가 실행될 때 함께 실행

• 예제 4-5 실제 실행 가능한 목적 파일의 텍스트 세그먼트 확인

  int main(int agrc, char** argv) {
    return 0;
  }
  
  /*******************************************************************
  여러 부분을 덤프하기 위해 objdump를 사용하였고
  하단의 결과는 실해 가능한 목적 파일에 존재하는 다양한 섹션의 내용을 추출하는 것을 예시로 나왔음
  
  실행 가능한 목적 파일은 여러 함수가 있지만 main함수만 나타내었습니다.
  
  ex4_5.out:     file format elf64-x86-64
  
  Disassembly of section .init:
  
  0000000000001000 <_init>:
      1000:       f3 0f 1e fa             endbr64
      1004:       48 83 ec 08             sub    $0x8,%rsp
      1008:       48 8b 05 d9 2f 00 00    mov    0x2fd9(%rip),%rax        # 3fe8 <__gmon_start__@Base>
      100f:       48 85 c0                test   %rax,%rax
      1012:       74 02                   je     1016 <_init+0x16>
      1014:       ff d0                   call   *%rax
      1016:       48 83 c4 08             add    $0x8,%rsp
      101a:       c3                      ret
  
  Disassembly of section .plt:
  
  0000000000001020 <.plt>:
      1020:       ff 35 a2 2f 00 00       push   0x2fa2(%rip)        # 3fc8 <_GLOBAL_OFFSET_TABLE_+0x8>
      1026:       f2 ff 25 a3 2f 00 00    bnd jmp *0x2fa3(%rip)        # 3fd0 <_GLOBAL_OFFSET_TABLE_+0x10>
      102d:       0f 1f 00                nopl   (%rax)
  
  Disassembly of section .plt.got:
  
  0000000000001030 <__cxa_finalize@plt>:
      1030:       f3 0f 1e fa             endbr64
      1034:       f2 ff 25 bd 2f 00 00    bnd jmp *0x2fbd(%rip)        # 3ff8 <__cxa_finalize@GLIBC_2.2.5>
      103b:       0f 1f 44 00 00          nopl   0x0(%rax,%rax,1)
  
  Disassembly of section .text:
  
  0000000000001040 <_start>:
      1040:       f3 0f 1e fa             endbr64
      1044:       31 ed                   xor    %ebp,%ebp
      1046:       49 89 d1                mov    %rdx,%r9
      1049:       5e                      pop    %rsi
      104a:       48 89 e2                mov    %rsp,%rdx
      104d:       48 83 e4 f0             and    $0xfffffffffffffff0,%rsp
      1051:       50                      push   %rax
      1052:       54                      push   %rsp
      1053:       45 31 c0                xor    %r8d,%r8d
      1056:       31 c9                   xor    %ecx,%ecx
      1058:       48 8d 3d ca 00 00 00    lea    0xca(%rip),%rdi        # 1129 <main>
      105f:       ff 15 73 2f 00 00       call   *0x2f73(%rip)        # 3fd8 <__libc_start_main@GLIBC_2.34>
      1065:       f4                      hlt
      1066:       66 2e 0f 1f 84 00 00    cs nopw 0x0(%rax,%rax,1)
      106d:       00 00 00
  
  0000000000001070 <deregister_tm_clones>:
      1070:       48 8d 3d 99 2f 00 00    lea    0x2f99(%rip),%rdi        # 4010 <__TMC_END__>
      1077:       48 8d 05 92 2f 00 00    lea    0x2f92(%rip),%rax        # 4010 <__TMC_END__>
      107e:       48 39 f8                cmp    %rdi,%rax
      1081:       74 15                   je     1098 <deregister_tm_clones+0x28>
      1083:       48 8b 05 56 2f 00 00    mov    0x2f56(%rip),%rax        # 3fe0 <_ITM_deregisterTMCloneTable@Base>
      108a:       48 85 c0                test   %rax,%rax
      108d:       74 09                   je     1098 <deregister_tm_clones+0x28>
      108f:       ff e0                   jmp    *%rax
      1091:       0f 1f 80 00 00 00 00    nopl   0x0(%rax)
      1098:       c3                      ret
      1099:       0f 1f 80 00 00 00 00    nopl   0x0(%rax)
  
  00000000000010a0 <register_tm_clones>:
      10a0:       48 8d 3d 69 2f 00 00    lea    0x2f69(%rip),%rdi        # 4010 <__TMC_END__>
      10a7:       48 8d 35 62 2f 00 00    lea    0x2f62(%rip),%rsi        # 4010 <__TMC_END__>
      10ae:       48 29 fe                sub    %rdi,%rsi
      10b1:       48 89 f0                mov    %rsi,%rax
      10b4:       48 c1 ee 3f             shr    $0x3f,%rsi
      10b8:       48 c1 f8 03             sar    $0x3,%rax
      10bc:       48 01 c6                add    %rax,%rsi
      10bf:       48 d1 fe                sar    %rsi
      10c2:       74 14                   je     10d8 <register_tm_clones+0x38>
      10c4:       48 8b 05 25 2f 00 00    mov    0x2f25(%rip),%rax        # 3ff0 <_ITM_registerTMCloneTable@Base>
      10cb:       48 85 c0                test   %rax,%rax
      10ce:       74 08                   je     10d8 <register_tm_clones+0x38>
      10d0:       ff e0                   jmp    *%rax
      10d2:       66 0f 1f 44 00 00       nopw   0x0(%rax,%rax,1)
      10d8:       c3                      ret
      10d9:       0f 1f 80 00 00 00 00    nopl   0x0(%rax)
  
  00000000000010e0 <__do_global_dtors_aux>:
      10e0:       f3 0f 1e fa             endbr64
      10e4:       80 3d 25 2f 00 00 00    cmpb   $0x0,0x2f25(%rip)        # 4010 <__TMC_END__>
      10eb:       75 2b                   jne    1118 <__do_global_dtors_aux+0x38>
      10ed:       55                      push   %rbp
      10ee:       48 83 3d 02 2f 00 00    cmpq   $0x0,0x2f02(%rip)        # 3ff8 <__cxa_finalize@GLIBC_2.2.5>
      10f5:       00
      10f6:       48 89 e5                mov    %rsp,%rbp
      10f9:       74 0c                   je     1107 <__do_global_dtors_aux+0x27>
      10fb:       48 8b 3d 06 2f 00 00    mov    0x2f06(%rip),%rdi        # 4008 <__dso_handle>
      1102:       e8 29 ff ff ff          call   1030 <__cxa_finalize@plt>
      1107:       e8 64 ff ff ff          call   1070 <deregister_tm_clones>
      110c:       c6 05 fd 2e 00 00 01    movb   $0x1,0x2efd(%rip)        # 4010 <__TMC_END__>
      1113:       5d                      pop    %rbp
      1114:       c3                      ret
      1115:       0f 1f 00                nopl   (%rax)
      1118:       c3                      ret
      1119:       0f 1f 80 00 00 00 00    nopl   0x0(%rax)
  
  0000000000001120 <frame_dummy>:
      1120:       f3 0f 1e fa             endbr64
      1124:       e9 77 ff ff ff          jmp    10a0 <register_tm_clones>
  
  0000000000001129 <main>:
      1129:       f3 0f 1e fa             endbr64
      112d:       55                      push   %rbp
      112e:       48 89 e5                mov    %rsp,%rbp
      1131:       89 7d fc                mov    %edi,-0x4(%rbp)
      1134:       48 89 75 f0             mov    %rsi,-0x10(%rbp)
      1138:       b8 00 00 00 00          mov    $0x0,%eax
      113d:       5d                      pop    %rbp
      113e:       c3                      ret
  
  Disassembly of section .fini:
  
  0000000000001140 <_fini>:
      1140:       f3 0f 1e fa             endbr64
      1144:       48 83 ec 08             sub    $0x8,%rsp
      1148:       48 83 c4 08             add    $0x8,%rsp
      114c:       c3
  
  ***********************************************************************/
  

  gcc ExtremeC_example.chapter4_5.c -o ex4_5.out
  
  objdump -S ex4_5.out
  

  • .text , .init, .plt와 같은 다양한 섹션은 모두 프로그램이 로드 및 실행될 수 있도록 해줌
  • 이는 모두 실행 가능한 목적 파일 내부에 있는 정적 메모리 레이아웃에 나타나는 동일한 텍스트 세그먼트에 속함
  • main 함수가 c프로그램에서 호출되는 첫 번째 함수가 아니라는 점 그리고 main 함수 전후로 실행되는 로직도 있음
  • 이러한 함수는 보통 리눅스에선 glibc라이브러리에서 빌려 오며, 링커가 이들을 모두 합쳐서 최종 실행 가능한 목적 파일을 형성

⭐ 4.4 동적 메모리 레이아웃 검사하기

✅ 동적 메모리 레이아웃

• 프로세스의 런타임 메모리runtime memory, 프로세스가 실행되는 동안 존재

• 실행 중인 프로세스의 메모리 레이아웃에는 5개의 세그먼트가 존재

  • 실행 가능한 목적 파일에 있는 정적 레이아웃에서 직접 복제된 세그먼트 3개
  • 스택과 힙 세그먼트 2개: 동적 세그먼트, 프로세스가 실행 중일 때만 존재
    • 스택 세그먼트: 변수가 저장되는 기본 메모리 영역, 크기 제한, 큰 객체x
    • 힙 세그먼트: 조정 가능한 큰 메모리 영역, 큰 객체나 변수, 고유 API 필요

• 5개의 세그먼트는 메인 메모리에 속하는 부분을 참조

  → 실행 중인 프로세스에 이미 할당된allocated, 전용dedicated and private 메모리

• 런타임 시 내용이 항상 변하므로 동적, 프로세스 실행 동안 세그먼트가 계속 수정됨

4.4.1 메모리 매핑

• 예제 4-6

  #include <unistd.h> // 윈도우처럼 POSIX 규격이 아닌 경우에는 windows.h를 대신 포함해야 함
  
  int main(int argc, char** argv) {
    // Infinite loop
    while (1) {
      sleep(1); // Sleep 1 second
    };
    return 0;
  }
  

  무한히 실행되는 예제로 프로세서가 계속 돌아가는 동안 메모리 구조를 검사 가능

  //1.예제 4-6 컴파일하기
  gcc ExtremeC_examples_chapter4_6.c -o ex4_6.out
  
  //2.백그라운드에서 예제 4-6 실행하기
  ./ex4_6.out &
  
  //kill 명령어로 프로세스 종료하기
  kill -9 402
  
  //3.procfs로 실행 중인 프로세스의 메모리 구조 확인하기
  ls -l /proc/402
  
  //4.maps의 내용을 덤프하기
  cat /proc/402/maps
  

  • 주소 범위address range
  • 허가permission
  • 오프셋offset
  • 장치device
  • 아이노드inode
  • 경로명 및 설명pathname or description

4.4.2 스택 세그먼트

✅ 스택 세그먼트

• 변수가 할당되는 기본 메모리 지역
• 메모리 매핑에서 [stack]이라고 적힌 부분
• 메모리 바이트를 읽기 위해 gdb와 같은 디버거 필요

✅ 스택 오버플로

• 스택 세그먼트가 가득 찼을 때 발생하는 오류, 프로세스가 운영체제에 의해 종료됨
• 함수에서 변수를 선언하면 기본적으로 스택 세그먼트 사용, 할당이 이루어지는 첫번째 장소
• 지역 변수는 스택 세그먼트의 가장 윗부분에 할당한 엔트리는 그 위의 엔트리가 제거되지 않으면 꺼낼 수 없음
• 스택의 크기는 제한적→작은 변수를 선언하는 편이 가장 좋음, 무한한 재귀나 함수 호출 지양
• 신중하게 작업→실행 프로세스가 방해받거나 충돌이 발생하기도 함
• 메모리의 스택 부분은 전용 데이터private data를 포함하며 민감할 수 있음
• 스택은 해당 프로세스 전용→다른 프로세스가 읽거나 수정 불가

4.4.3 힙 세그먼트

• 예제 4-7

  #include <unistd.h> // Needed for sleep function
  #include <stdlib.h> // Needed for malloc function
  #include <stdio.h> // Needed for printf
  
  int main(int argc, char** argv) {
    void* ptr = malloc(1024); // 힙에서 1KB 할당하기
    printf("Address: %p\n", ptr);
    fflush(stdout); // 강제로 출력하기
    // Infinite loop
    while (1) {
      sleep(1); // Sleep 1 second
    };
    return 0;
  }
  

  무한 루프에 들어가기 전에 힙 세그먼트에서 다수의 바이트를 할당

  //1.예제 4-7을 컴파일하고 실행하기
  g++ ExtremeC_examples_chapter4_7.c -o ex4_7.out
  ./ex4_7.out &
  
  //2.maps의 내용을 덤프하기
  cat /proc/3451/maps
  

  malloc 사용→새로운 매핑 [heap]이 추가, 0x21000바이트 할당됨 힙 세그먼트가 메모리와 시간 오버헤드를 갖기 때문 힙 메모리는 포인터를 통해서만 접근 가능

• 예제 4-8

  #include <stdio.h>   // For printf function
  #include <stdlib.h>  // For malloc and free function
  
  void fill(char* ptr) {
    ptr[0] = 'H';
    ptr[1] = 'e';
    ptr[2] = 'l';
    ptr[3] = 'l';
    ptr[5] = 0;
  }
  
  int main(int argc, char** argv) {
    void* gptr = malloc(10 * sizeof(char));
    char* ptr = (char*)gptr;
    fill(ptr);
    printf("%s!\n", ptr);
    free(ptr);
    return 0;
  }
  

  gptr과 ptr은 지역 포인터 변수→스택에 할당 포인터가 가리키는 주소→힙 세그먼트 내부 fill 함수 내 ptr포인터와 main 함수 내 ptr포인터는 다른 것 접근 불가능한 힙 메모리를 할당→메모리 누수memory leak 메모리 누수가 증가→허용된 메모리 공간 모두 사용→프로세스 종료 free함수 호출→힙 메모리 블록 해제

⭐ 4.5 마무리

✅ 메모리

• 실행 프로세스의 동적 메모리 구조뿐만 아니라 실행 가능한 목적 파일의 정적 메모리 구조도 설명했습니다.
• 데이터 세그먼트는 초기화된 전역 변수를 저장하는데 사용된다고 설명했습니다.

• size와 objdump 명령어로 목적 파일의 내부를 검사했습니다.

  목적 파일의 내부에서 세그먼트를 찾기 위해 readelf 같은 목적 파일 덤퍼를 사용할 수 있습니다.

✅ 동적 메모리 레이아웃

• 프로세스의 동적 메모리 레이아웃을 검사 했습니다.

  프로세스의 모든 세그먼트는 정적 메모리 레이아웃에서 동적 메모리로 복제됨을 이해했습니다.

  하지만 동적 메모리 레이아웃에는 새로운 세그먼트가 2가지 스택과 힙 세그먼트가 존재했습니다.

• 스택 세그먼트는 할당에 필요한 기본 메모리 영역이라고 설명했습니다.
• 지역 변수는 언제나 스택 영역의 맨 위에 할당된다고 학습했습니다.
• 또한 스택 세그먼트 내에 함수 호출에 대한 비밀과 그 작동 방식을 살펴봤습니다.

• 힙 메모리 영역을 할당 및 해제하려면 특정 API 또는 함수 집합을 사용해야 한다는 점을 알게 되었습니다.

  이 API는 C의 표준 라이브러리가 제공합니다.

• 메모리 누수를 설명했으며 메모리 누수가 힙 메모리 지역에서 어떻게 발생하는지도 알아봤습니다.