[C/C++] 간단한 프로그램 컴파일/링크 과정

References

Advaned C and C++ Compiling

Program's lifetime
Compile Process
Link Process

프로그램의 lifetime은 바이너리의 내부 구조에 의해 결정되는데, 바이너리는 OS loader가 load, unpack, 그리고, 그 내용을 실행하게 됩니다. 여기서 프로그램이 C/C++로 작성되었을 때, 코드부터 실행까지의 과정을 간단히 살펴보겠습니다.

Creating the source code

우선 다음의 3가지 파일을 간단하게 작성하도록 하겠습니다.

function.h

#pragma once

#define FIRST_OPTION
#ifdef FIRST_OPTION
#define MULTIPLIER (3.0)
#else
#define MULTIPLIER (2.0)
#endif

float add_and_multiply(float x, float y);

function.c

#include "function.h"

int nCompletionStatus = 0;

float add(float x, float y)
{
    float z = x + y;
    return z;
}

float add_and_multiply(float x, float y)
{
    float z = add(x, y);
    z *= MULTIPLIER;
    return z;
}

main.c

#include "function.h"
#include <stdio.h>

extern int nCompletionStatus;

int main(int argc, char** argv)
{
    float x = 1.0;
    float y = 5.0;
    float z;

    z = add_and_multiply(x, y);
    printf("%f\n", z);
    nCompletionStatus = 1;
    return 0;
}

간단한 코드이므로, 코드에 대한 내용은 생략하도록 하겠습니다.

Compiling

소스 코드를 작성하고 난 뒤의 첫 번째 단계는 컴파일하는 것입니다. 컴파일에 대해 살펴보기 전에, 몇 가지 용어에 대해 정리하고 시작하도록 하겠습니다.

Translation Unit (TU) - 컴파일러의 입력입니다. 일반적인 translation unit은 소스 코드를 포함하는 텍스트 파일입니다. 프로그램은 수 많은 TU들로 구성되며, 프로젝트의 모든 소스 코드를 하나의 파일에 넣는 것이 가능하지만 일반적으로 그렇게 하지는 않습니다.
Binary Object Files - 컴파일의 결과는 각 TU 마다 하나씩 생성되는 binary object file의 집합입니다. 이 결과만으로는 프로그램을 실행할 수 없고 링킹(linking)이라는 또 다른 과정을 통해 생성된 object file들을 연결시켜주어야 합니다.
Compilation (컴파일) - 넓은 의미에서 컴파일은 어떤 프로그래밍 언어로 작성된 소스 코드를 다른 프로그래밍 언어로 변환하는 과정이라고 정의할 수 있습니다. 컴파일은 컴파일러(compiler)라는 프로그램에 의해 수행됩니다.
엄격한 의미의 컴파일은 고급 언어(high-level language)의 코드를 저수준의 언어(low-level language, 일반적으로 assembler 또는 machine code)의 코드로 변환하는 프로세스를 의미합니다.
Cross-Compilation - 하나의 플랫폼(CPU/OS)에서 컴파일하여 다른 플랫폼(CPU/OS)에서 실행할 코드를 생성하는 경우, 이를 크로스 컴파일이라고 합니다. 일반적으로 데스크탑 OS (windows, linux)를 사용하여 임베디드 또는 모바일 디바이스용 코드를 생성하는 것이 이에 해당됩니다.
Decompilation (disassembling) - 디컴파일 또는 역어셈은 low-level의 코드를 high-level로 변환하는 과정을 의미합니다.
Language Translation - language translation은 한 프로그래밍 언어의 소스 코드를 동일한 수준과 복잡도로 다른 프로그래밍 언어로 변환하는 프로세스입니다.
Language Rewriting - language rewriting은 최적화와 같이 특정 작업에 더 작합한 형식으로 코드를 다시 작성하는 것을 의미합니다.

컴파일은 한 번의 과정으로 결과가 나오는 것이 아니라 여러 단계로 나누어져 있습니다. 크게 pre-processing, linguistic analysis, assembling, optimization, code emission으로 나눌 수 있으며 아래에서 각 단계들을 알아보도록 하겠습니다.

Preprocessing

컴파일의 첫 번째 단계(전처리, preprocessing)에서는 preprocessor라고 불리는 특별한 text processing program을 통해 다음의 작업들을 수행합니다.

#include 키워드로 지정된 파일(include/header file)들을 소스 파일에 포함시킴
#define 문을 사용하여 지정된 값들을 상수로 변환
매크로가 호출되는 곳에서 해당 매크로 정의를 코드로 변환
#if, #elif, #endif 지시문(directives)의 위치에 따라 코드의 특정 부분을 조건부로 포함하거나 제외

Preprocessor의 출력은 C/C++ 코드의 최종 형태이며, 이렇게 처리된 코드가 다음 단계(syntax analysis)로 전달됩니다.

위에서 작성한 function.c 소스 파일을 gcc 컴파일러를 통해 아래의 커맨드로 preprocessing 단계를 수행할 수 있습니다.

gcc -E function.c -o function.i

저의 경우, 다음과 내용을 포함하는 출력 파일이 생성되었습니다.

# 1 "function.c"
# 1 "<built-in>"
# 1 "<command-line>"
# 31 "<command-line>"
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 32 "<command-line>" 2
# 1 "function.c"
# 1 "function.h" 1
       
# 10 "function.h"
float add_and_multiply(float x, float y);
# 2 "function.c" 2

int nCompletionStatus = 0;

float add(float x, float y)
{
    float z = x + y;
    return z;
}

float add_and_multiply(float x, float y)
{
    float z = add(x, y);
    z *= (3.0);
    return z;
}

출력 파일(function.i)에서 add_and_multiply 함수 내부 코드를 보면 매크로로 정의된 MULTIPLIER가 모두 정의된 상수로 변경된 것을 볼 수 있습니다.

결과를 조금 더 컴팩트하게 보려면, '-P' 옵션을 추가하면 다음의 내용을 담고 있는 결과 파일을 볼 수 있습니다.

       
float add_and_multiply(float x, float y);
int nCompletionStatus = 0;
float add(float x, float y)
{
    float z = x + y;
    return z;
}
float add_and_multiply(float x, float y)
{
    float z = add(x, y);
    z *= (3.0);
    return z;
}

Linguistic Analysis

이 단계에서는 C/C++ 코드를 처리하는데 더 적합한 포맷으로 변환합니다 (주석, 불필요한 공간 등). 이렇게 최적화되고 압축된 형태의 소스 코드는 작성된 프로그래밍 언어의 syntax rule을 만족시키는지 여부를 확인하기 위해 분석됩니다. 문법과 다른 부분이 감지되면 에러 또는 경고를 출력합니다.

이 단계에서는 3개의 하위 단계(lexical analysis, parsing/syntax analysis, semantic analysis)가 있는데, 자세히 다루지는 않겠습니다. Linguistic analysis 단계에서는 실제로 컴파일하는 것은 아니고, 오타나 문법적 오류에 대해 체크한다고 볼 수 있습니다.

Assembling

이전 단계에서 syntax error가 없으면, 이 단계를 수행할 수 있습니다. 이 단계에서 컴파일러는 standard language construct를 실제 CPU instruction sets의 constructs로 변환합니다. CPU마다 기능도 다르고, 사용 가능한 명령어, 레지스터, 인터럽트 등이 다르므로 프로세서마다 다양한 컴파일러가 해당 환경들을 지원합니다.

아래의 커맨드로 어셈블리어로 변환한 파일(ASCII text file)을 생성할 수 있습니다.

gcc -S function.c [-o function.s]

아직까지 실행할 수 있는 파일은 아니며, 단지 사람이 읽을 수 있는 형태의 어셈블러 명령어들을 담고 있는 텍스트 파일에 불과합니다.

Optimization

오지리날 소스 코드에 대한 첫 번째 어셈블러 코드가 생성될 때, 레지스터의 사용을 최소화하는 최적화 작업이 시작됩니다. 이때, 실제로 실행할 필요가 없는 부분은 제거됩니다.

Code Emission

마지막으로 각 TU (translation unit)에 대해 하나씩 object file을 생성합니다. 사람이 읽을 수 있는 ASCII 코드로 작성된 어셈블리 명령어는 이 단계에서 machine instructions (opcodes)를 나타내는 binary value로 변환되고, object files의 특정 위치에 쓰여지게 됩니다.

Object file은 바이너리 파일이기 때문에 전처리된 출력이나 어셈블리 프로세스에서의 출력과 상당히 다릅니다. Hex editor를 통해 살펴본 object file은 다음과 같습니다.

이렇게 작성된 object file은 disassembling 이라는 과정을 통해 사람이 읽을 수 있는 형태로 다시 역변환할 수 있습니다.

gcc 컴파일러는 ELF format 형태의 binary object file을 생성할 수 있습니다. 일반적인 overhead (header, tables,..)와 모든 관련된 section (.text, .code, .bss 등)이 포함됩니다.

위에서 작성한 function.c 파일에 대해 object file을 생성하려면 다음의 커맨드를 사용합니다.

gcc -c function.c [-o function.o]

생성된 파일은 위에서 본 것처럼 0과 1로 구성되어 있으므로 hex editor와 같은 프로그램을 통해서 살펴볼 수 있습니다. 다만, 이 값들을 살펴보는 것만으로는 거의 아무것도 알아낼 수 없습니다.

따라서, 사람이 읽을 수 있는 형태로 다시 역변환해야 하는데, 리눅스에서는 objdump라는 프로그램을 사용하면 역변환이 가능합니다.

objdump -D function.o

위 커맨드를 입력하면 다음과 같은 내용을 출력합니다.

Object Files

컴파일의 출력은 하나 이상의 binary object files 입니다. 나중에 다룰 예정인데, object file의 구조에는 프로그램을 이해하는데 중요한 세부 내용들이 많이 포함되어 있습니다. 간단히 요약하면 다음과 같습니다.

Object file은 해당되는 원본 소스 파일을 번역한 결과이며, 컴파일의 결과는 프로젝트에 있는 소스 파일의 수만큼의 object files 입니다.
Object file의 기본 구성 요소는 심볼(symbols - 프로그램 또는 데이터 메모리에서 메모리 주소에 대한 참조)과 섹션(sections) 입니다. Object file에서 가장 자주 발견되는 섹션에는 .text (코드), .data (초기화된 데이터), .bss (초기화되지 않은 데이터) 등이 있습니다.
프로그램 빌드에서의 궁극적인 의도는 각 소스 파일을 컴파일하여 얻은 섹션들을 binary execution file로 결합(tiled)하는 것입니다. 이러한 바이너리 파일에는 개별 파일의 섹션을 결합한 동일한 유형의 섹션들이 포함됩니다. 단, object file의 내부에는 각 섹션들이 프로그램 메모리 맵에서의 궁극적인 메모리 위치를 가지고 있지 않습니다. 각 object file의 각 섹션의 주소는 0부터 시작하며, 프로그램 메모리 맵에 상주할 실제 주소는 컴파일 이후 단계(링크)에서 결정됩니다.
위와 같은 이유로 object file의 각 섹션을 결합하는데 가장 중요한 매개변수는 섹션의 길이, 즉, 섹션의 주소 범위입니다.

일반적으로 object file의 정보는 바이너리 포맷 사양의 형태의 특정 rule에 따라 저장되며, 세부적인 내용은 플랫폼마다 다릅니다. Linux에서는 ELF (Executable and Linkable Format)이 사용되고, Windows에서는 일반적으로 PE/COFF 포맷이 사용됩니다.

Link

Compilation Process Limitations

지금까지 컴파일 단계에서는 원본 소스 파일을 바이너리 object file들로 변환한다는 것을 알아봤습니다. 각 object file에는 섹션들이 포함되어 있으며, 각 object들은 아래 그림과 같이 궁극적으로 프로그램 메모리 맵의 일부로 결합됩니다.

Object file을 생성한 이후에는 각 object file에 저장된 섹션들을 프로그램 메모리 맵으로 결합해야 하며, 이 작업은 링킹(linking)이라는 프로세스에서 수행됩니다.

단순히 생각하면 컴파일 단계에서 위 그림과 같이 단순히 모으기만 하면, 링킹이라는 프로세스가 필요없는 것 아니냐라고 질문할 수도 있습니다. 하지만, 이렇게 프로세스가 나누어져 있는 데에는 중요한 이유들이 있는데 그중 몇 가지 이유는 다음과 같습니다.

먼저, 섹션 (특히 code section)을 결합하는 것이 항상 간단한 것이 아닙니다. 다만, 프로그램 빌드 과정을 한 단계로 완료할 수 있는 프로그래밍 언어도 많습니다.
둘째, 빌드 프로세스에 적용된 code reuse principle을 위해 C/C++ 빌드를 2단계(컴파일과 링크)로 구현하기로 결정했습니다 (정확히 code reuse principle 때문에 2단계로 나누었는지는 확실하지 않습니다.. !)

그렇다면 각 섹션을 결합하는 것이 복잡한 이유는 무엇일까요 ?

대부분의 경우, 소스 코드를 binary object file로 변환하는 것은 상당히 간단한 프로세스라고 합니다. 코드 라인은 코드 명령어로 변환되며, 초기화된 변수를 위한 공간이 reserved 되어 있고 초기 값이 이곳에서 기록됩니다. 초기화되지 않은 변수를 위한 공간 또한 reserved 되어 있으며, 0으로 채워지게 됩니다.

다만, 전체적으로 살펴보면 몇 가지 문제가 발생할 수 있습니다. 동일한 프로그램의 일부라는 것은 상호 연결이 존재해야 한다는 것을 의미합니다. 실제로 개별 코드 간의 연결은 일반적으로 두 가지 옵션을 통해 설정됩니다.

기능적으로 분리된 code bodies 간의 함수 호출 - 예를 들면, application의 GUI 관련 소스 파일에 있는 함수는 TCP/IP 네트워크 소스 파일에 있는 함수를 호출할 수 있음
External variables - 다른 소스 파일에서 광범위하게 사용되는 변수는 하나의 소스 파일에서 전역 변수로 선언되고 다른 모든 소스 파일에서 extern 변수로 참조 (예를 들면, standard C 라이브러리에서 마지막으로 발생한 오류의 값을 저장하기 위해 사용되는 errno 변수가 있음)

함수나 외부 변수 (일반적으로 이들을 심볼이라고 부름)에 액세스하려면 해당되는 주소를 알아야 합니다. 하지만, 실제 주소는 개별 섹션들이 해당 프로그램의 섹션에 통합되기 전까지는 알 수 없습니다. 따라서, 통합되기 전까지는 함수와 caller 간의 의미있는 연결 또는 외부 변수에 대한 액세스를 설정하는 것이 불가능하며 둘 다 unresolved references로 출력됩니다. 동일한 소스 파일에서 참조되는 경우에는 이 문제가 발생하지 않으며, 서로에 대한 상대적인 위치를 알고 있으므로 이러한 정보들은 프로그램 섹션으로 통합되기 전에 알 수 있습니다. 이러한 경우에는 섹션으로 통합되면 상대적인 메모리 주소가 구체화됩니다.

다만, 이러한 종류의 문제를 해결하기 위해서 빌드 단계를 두 단계로 나누어야 하는 것은 아니며, 실제로 다른 언어들은 하나의 프로세스 단계로 빌드합니다. 그러나 프로그램을 빌드하는 데 적용된 reuse 개념은 궁극적으로 프로그램 빌드를 두 단계로 나누도록 했다고 합니다.

Linking

링킹은 프로그램 빌드 과정의 두 번째 단계입니다. 링킹 프로세스에 대한 입력은 컴파일 단계에서 생성된 object file들이 됩니다. 각 object file은 개별 소스 파일들에 대한 섹션들의 정보를 저장하는 저장소로 볼 수 있습니다. 링커(Linker)가 수행하는 작업은 개별적으로 저장된 섹션들을 사용하여 최종 프로그램 메모리 맵 섹션을 구성하고 모든 reference를 해결하는 것입니다. 이때 가상 메모리 개념을 사용하여 링커는 0부터 시작하는 주소 범위를 갖는다고 가정하여 이러한 작업을 조금 단순화시킵니다. 실제 주소 범위는 런타임에서 OS에 의해 제공됩니다.

링킹도 컴파일처럼 여러 단계로 나누어져 있는데, relocation, reference resolving 단계로 나눌 수 있습니다.

Relocation

링킹의 첫 번째 단계는 각 섹션을 결합하여 프로그램의 메모리 맵 섹션을 만드는 프로세스입니다.

이 작업을 완료하기 위해서, object file에서 0으로 시작했던 주소 범위가 프로그램 메모리 맵에서 보다 구체적으로 지정됩니다. '보다 구체적으로'라고 말한 것은 이 과정에서 실제 메모리 주소가 결정되는 것이 아니기 때문이며, 프로그램의 실제 물리적 주소는 OS에 의해서 런타임에 결정됩니다.

이러한 relocation 단계가 완료되면 프로그램 메모리 맵의 대부분이 생성됩니다 (전부는 아님).

Resolving References

이전의 relocation 작업은 섹션을 선택하고 주소 범위를 프로그램 메모리 맵의 주소 범위로 변환하는데, 이 작업은 상당히 쉬운 작업입니다. 다음 단계인 resolving references에서는 코드의 다양한 부분들 사이에 필요한 연결을 설정하는데, 이 작업은 어려운 작업입니다.

이전 단계들(컴파일과 relocation)이 성공적으로 완료된 이후에는 어떤 문제가 남아있을까요?

링킹 문제의 근본적인 원인은 매우 간단합니다. 코드 조각들은 다른 TU(즉, 소스 파일)에서 서로 참조하려고 하지만 서로가 메모리의 어디에 위치할 지 알 수 없습니다. Object file은 프로그램 메모리 맵에 바둑판식으로 배열되는데, 대부분의 문제의 원인이 되는 코드의 구성 요소는 program memory(function entry points)와 data memory variables(global/static/extern)에 밀접하게 연관되어 있는 구성 요소들입니다.

우리가 처음 작성한 function.c와 main.c를 가지고 살펴봅시다.

add_and_multiply 함수는 동일한 소스 파일(즉, 동일한 object file)에 있는 add 함수를 호출합니다. 이 경우, 함수 add()의 프로그램 메모리에 있는 주소는 function.o의 code section의 상대적인 오프셋으로 표현될 수 있습니다.

main.c 파일의 main 함수는 add_and_multiply 함수를 호출하고 외부 변수 nCompletionStatus를 참조합니다. 하지만 이들의 실제 프로그램 메모리 주소를 알아내는 데에 큰 문제가 있습니다. 사실, 이 두 심볼 모두 미래의 어느 시점에서 프로세스 메모리 맵의 어딘가에 위치할 것이라고 가정할 수 있습니다만, 메모리 맵이 형성되기 전에는 unresolved references 입니다.

이러한 문제를 해결하기 위해서는 references를 해결하는 링킹 단계가 필요합니다. 위와 같은 상황에서 링커가 해야하는 작업은 다음과 같습니다.

프로그램 메모리 맵에서 타일링된 섹션들을 검사
코드의 어느 부분이 원래 섹션의 외부에서 호출되는지 확인
코드의 reference 부분이 정확히 메모리 맵의 어느 주소에 있는지 파악
machine instructions의 더미 주소를 프로그램 메모리 맵의 실제 주소로 교체하여 unresolved 해결

링킹 단계가 완료되면 다음과 같이 참조를 해결하게 됩니다.

위에서 작성한 코드들을 가지고, 컴파일하고 링크하려면 다음의 두 단계의 커맨드를 순차적으로 입력하면 됩니다.

gcc -c function.c main.c

gcc function.o main.o -o demoApp

다음과 같이 하나의 커맨드로 컴파일러와 링커를 호출하여 위의 작업을 수행할 수도 있습니다.

gcc function.c main.c -o demoApp

objdump를 통해 main.o 파일을 역어셈한 결과는 다음과 같습니다.

Line 3c를 살펴보면, 자신에게 점프하는 call instruction을 사용하고 있습니다. 반면 Line 5e는 0x0 주소에 있는 변수에 액세스하려고 합니다. 이 이상한 값들은 링커에 의해 의도적으로 삽입된 것입니다.

하지만, 출력 파일의 역어셈 결과를 보면, main.o object file의 내용이 11bf로 시작하는 주소 범위로 relocation 되었고, 위의 두 가지 문제가 링커에 의해 해결되었음을 확인할 수 있습니다 (Line 11fb, 121d 참조).

objdump는 정말 유용하게 사용될 수 있는데, 다음의 커맨드를 입력하면

objdump -x -j .bss demoApp

nCompletionStatus 변수가 0x4014에 상주하고 있다는 것을 알 수 있습니다.

Linker's Viewpoint

사실 링커는 컴파일러와 달리 작성된 코드의 세부 사항에는 관심이 없는 도구입니다. 대신 아래 그림처럼 더 넓은 프로그램 메모리 맵의 관점에서 object file들을 프로그램 맵에 결합해야되는 집합으로 취급합니다.

실행 파일로 링킹하는 것이 아닌 dynamic libraries와 dynamic linking도 있는데, 추후에 executable과 dynamic library와의 차이점과 같이 살펴보도록 하겠습니다.

'프로그래밍 > C & C++' 카테고리의 다른 글

[C/C++] Static vs Dynamic 라이브러리 (0)	2022.11.08
[C/C++] Program Execution (0)	2022.11.04
[C++] std::string 최적화 (1)	2022.04.24
[C++] Error Handling (2) (0)	2022.03.06
[C++] Error Handling (1) (0)	2022.03.06

별준

[C/C++] 간단한 프로그램 컴파일/링크 과정

References

Contents

Creating the source code

Compiling

Preprocessing

Linguistic Analysis

Assembling

Optimization

Code Emission

Object Files

Link

Compilation Process Limitations

Linking

Relocation

Resolving References

Linker's Viewpoint

'프로그래밍 > C & C++' 카테고리의 다른 글

댓글

티스토리툴바

[C/C++] 간단한 프로그램 컴파일/링크 과정

References

Contents

Creating the source code

Compiling

Preprocessing

Linguistic Analysis

Assembling

Optimization

Code Emission

Object Files

Link

Compilation Process Limitations

Linking

Relocation

Resolving References

Linker's Viewpoint

'프로그래밍 > C & C++' 카테고리의 다른 글

관련글

댓글

티스토리툴바