이미지 로딩 중...
AI Generated
2025. 11. 13. · 2 Views
Rust로 만드는 나만의 OS 크로스 컴파일 설정 완벽 가이드
베어메탈 환경에서 실행될 OS를 개발하기 위한 크로스 컴파일 환경 구축 방법을 다룹니다. 타겟 트리플 설정부터 링커 스크립트 작성까지 실무에 필요한 모든 과정을 담았습니다.
목차
- 크로스 컴파일 타겟 트리플 설정 - 베어메탈 환경을 위한 첫걸음
- no_std 환경 설정 - 표준 라이브러리로부터의 독립
- 링커 스크립트 작성 - 메모리 레이아웃의 정확한 제어
- Cargo 빌드 설정 - 자동화된 크로스 컴파일
- 멀티부트 헤더 구현 - 부트로더와의 통신
- 부트스트랩 어셈블리 - CPU 초기화와 Rust로의 전환
- 빌드 스크립트 통합 - 어셈블리와 Rust의 결합
- QEMU 테스트 환경 - 빠른 개발 사이클
- 크로스 컴파일 도구 체인 검증 - 빌드 환경 테스트
- 최소 바이너리 검증 - 부팅 가능한 첫 커널
1. 크로스 컴파일 타겟 트리플 설정 - 베어메탈 환경을 위한 첫걸음
시작하며
여러분이 Rust로 운영체제를 만들려고 할 때 가장 먼저 마주치는 문제가 무엇일까요? 바로 일반적인 Rust 컴파일러는 표준 라이브러리와 운영체제를 전제로 하기 때문에 베어메탈 환경에서는 작동하지 않는다는 것입니다.
일반적인 애플리케이션 개발과 달리, OS 개발은 운영체제가 없는 하드웨어 위에서 직접 실행되어야 합니다. 이는 표준 라이브러리의 많은 기능을 사용할 수 없고, 메모리 할당자도 직접 구현해야 한다는 의미입니다.
바로 이럴 때 필요한 것이 커스텀 타겟 트리플 설정입니다. 타겟 트리플을 통해 Rust 컴파일러에게 우리가 만들 프로그램이 어떤 환경에서 실행될지 정확히 알려줄 수 있습니다.
개요
간단히 말해서, 타겟 트리플은 컴파일러에게 '어떤 아키텍처', '어떤 벤더', '어떤 OS'를 위한 코드를 생성할지 알려주는 식별자입니다. 베어메탈 OS 개발에서는 기존의 타겟(예: x86_64-unknown-linux-gnu)을 사용할 수 없습니다.
왜냐하면 이러한 타겟들은 운영체제의 존재를 가정하고 있기 때문입니다. 예를 들어, 파일 시스템, 네트워킹, 스레드 관리 등 모든 것을 OS가 제공한다고 생각합니다.
기존에는 호스트 시스템의 타겟으로 컴파일했다면, 이제는 완전히 독립적인 커스텀 타겟을 정의하여 컴파일할 수 있습니다. 타겟 트리플의 핵심 특징은 다음과 같습니다.
첫째, JSON 형식으로 세밀하게 제어 가능하며, 둘째, 표준 라이브러리 의존성을 제거할 수 있고, 셋째, 링커 동작과 코드 생성 방식을 완전히 커스터마이징할 수 있습니다. 이러한 특징들이 베어메탈 프로그래밍을 가능하게 만듭니다.
코드 예제
// x86_64-unknown-none.json - 커스텀 타겟 트리플 정의
{
"llvm-target": "x86_64-unknown-none",
"data-layout": "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128",
"arch": "x86_64",
"target-endian": "little",
"target-pointer-width": "64",
"target-c-int-width": "32",
"os": "none",
"linker-flavor": "ld.lld",
"linker": "rust-lld",
"executables": true,
"features": "-mmx,-sse,+soft-float",
"disable-redzone": true,
"panic-strategy": "abort"
}
설명
이것이 하는 일은 Rust 컴파일러에게 운영체제가 없는 x86_64 환경을 위한 코드를 생성하도록 지시하는 것입니다. 각 필드는 컴파일러가 어떻게 코드를 생성할지 결정하는 중요한 정보를 담고 있습니다.
첫 번째로, "llvm-target"과 "data-layout"은 LLVM 백엔드가 사용할 기본 아키텍처 정보를 제공합니다. "os": "none"은 가장 중요한 설정으로, 이것이 운영체제가 없는 베어메탈 환경임을 명시합니다.
이로 인해 컴파일러는 OS에 의존하는 어떤 기능도 사용하지 않게 됩니다. 그 다음으로, "features": "-mmx,-sse,+soft-float"가 실행되면서 하드웨어 부동소수점 연산을 비활성화합니다.
이는 부팅 초기에 SSE 레지스터가 초기화되지 않았을 수 있기 때문입니다. "disable-redzone": true는 스택 관리를 안전하게 만들어 인터럽트 핸들러에서 문제가 발생하지 않도록 합니다.
마지막으로, "panic-strategy": "abort"가 패닉 발생 시 스택 언와인딩 없이 즉시 중단하도록 설정하여 최종적으로 더 작고 예측 가능한 바이너리를 만들어냅니다. "linker": "rust-lld"는 Rust와 함께 제공되는 LLD 링커를 사용하도록 지정합니다.
여러분이 이 설정을 사용하면 표준 라이브러리 없이도 컴파일 가능한 완전히 독립적인 바이너리를 얻을 수 있습니다. 이는 부팅 가능한 OS 커널을 만드는 첫 번째 단계이며, 모든 의존성을 제거한 순수한 코드베이스를 구축할 수 있게 해줍니다.
실전 팁
💡 타겟 파일은 프로젝트 루트에 배치하고 --target 플래그로 지정하세요. .cargo/config.toml에 기본 타겟으로 설정하면 매번 지정할 필요가 없습니다.
💡 "features"에서 하드웨어 기능을 비활성화할 때는 신중해야 합니다. 나중에 OS가 안정화되면 일부 기능을 다시 활성화하여 성능을 향상시킬 수 있습니다.
💡 "panic-strategy": "abort"를 사용하면 libunwind 의존성이 제거되어 바이너리 크기가 크게 줄어듭니다. 베어메탈 환경에서는 언와인딩이 불가능하므로 항상 이 옵션을 사용하세요.
💡 타겟 파일을 수정한 후에는 cargo clean을 실행하여 이전 빌드 아티팩트를 제거해야 합니다. 그렇지 않으면 캐시된 결과가 사용될 수 있습니다.
💡 LLVM 타겟 트리플 문서를 참조하여 "data-layout" 문자열의 의미를 이해하세요. 잘못된 설정은 런타임에 미묘한 버그를 일으킬 수 있습니다.
2. no_std 환경 설정 - 표준 라이브러리로부터의 독립
시작하며
여러분이 cargo build --target x86_64-unknown-none.json을 실행했을 때 수많은 컴파일 에러가 발생한다면? 대부분은 표준 라이브러리의 기능을 사용하려고 시도했기 때문입니다.
Rust의 표준 라이브러리는 운영체제가 제공하는 서비스를 전제로 합니다. 파일 시스템, 네트워크 스택, 스레드 스케줄러 등이 모두 그 예입니다.
베어메탈 환경에서는 이런 것들이 아직 존재하지 않습니다. 바로 이럴 때 필요한 것이 no_std 속성입니다.
이를 통해 표준 라이브러리 대신 core 라이브러리만 사용하는 환경을 만들 수 있습니다.
개요
간단히 말해서, no_std는 Rust 프로그램이 표준 라이브러리(std) 없이 컴파일되도록 하는 속성입니다. 표준 라이브러리 대신 core 라이브러리를 사용하는 이유는 명확합니다.
core는 운영체제에 의존하지 않는 순수한 Rust 기능만 제공합니다. 예를 들어, Option, Result, Iterator 같은 타입들과 메모리 조작 함수들은 모두 사용 가능합니다.
기존에는 std 프렐루드가 자동으로 임포트되었다면, 이제는 core 프렐루드만 사용할 수 있습니다. 하지만 걱정하지 마세요.
대부분의 중요한 타입과 트레이트는 core에도 포함되어 있습니다. no_std의 핵심 특징은 다음과 같습니다.
첫째, 힙 할당이 기본적으로 불가능하며(alloc 크레이트로 추가 가능), 둘째, 파일 I/O나 네트워킹 같은 OS 서비스를 사용할 수 없고, 셋째, 패닉 핸들러를 직접 구현해야 합니다. 이러한 제약들이 오히려 OS 개발자에게 완전한 제어권을 제공합니다.
코드 예제
// src/main.rs - no_std 환경 기본 설정
#![no_std] // 표준 라이브러리 사용 안 함
#![no_main] // 일반적인 main 진입점 사용 안 함
use core::panic::PanicInfo;
// 패닉 핸들러 - 패닉 발생 시 호출됨
#[panic_handler]
fn panic(_info: &PanicInfo) -> ! {
loop {} // 무한 루프로 시스템 정지
}
// 커스텀 진입점 정의
#[no_mangle]
pub extern "C" fn _start() -> ! {
loop {} // 부팅 후 무한 루프
}
설명
이것이 하는 일은 Rust 프로그램을 완전히 독립적인 베어메탈 바이너리로 만드는 것입니다. 운영체제의 도움 없이 하드웨어 위에서 직접 실행될 수 있는 코드를 생성합니다.
첫 번째로, #![no_std] 속성이 표준 라이브러리를 비활성화합니다. 이제 Vec, String, HashMap 같은 타입은 사용할 수 없지만, Option, Result, 기본 산술 연산 등은 여전히 가능합니다.
#![no_main]은 Rust의 표준 런타임 시작 코드를 사용하지 않겠다는 의미입니다. 그 다음으로, #[panic_handler] 함수가 정의됩니다.
표준 라이브러리가 제공하던 기본 패닉 핸들러가 없으므로 직접 구현해야 합니다. 현재는 단순히 무한 루프로 시스템을 정지시키지만, 나중에는 에러 메시지를 화면에 출력하는 등의 기능을 추가할 수 있습니다.
마지막으로, #[no_mangle]과 extern "C"가 적용된 _start 함수가 실제 진입점이 됩니다. #[no_mangle]은 Rust 컴파일러가 함수 이름을 변경하지 못하게 하여 링커가 정확히 _start라는 심볼을 찾을 수 있게 합니다.
extern "C"는 C 언어의 호출 규약을 사용하도록 지정합니다. 여러분이 이 코드를 사용하면 운영체제 없이 부팅 가능한 최소한의 Rust 프로그램을 만들 수 있습니다.
이는 아직 아무 기능도 없지만, 모든 OS 개발의 시작점이 되며, 여기에 하드웨어 초기화, 메모리 관리, 인터럽트 처리 등을 추가해 나갈 수 있습니다.
실전 팁
💡 core 라이브러리는 항상 사용 가능하지만, alloc 크레이트는 메모리 할당자를 구현한 후에만 사용할 수 있습니다. 개발 초기에는 alloc 없이 진행하세요.
💡 패닉 핸들러에서 화면에 에러를 출력하려면 VGA 버퍼를 먼저 구현해야 합니다. 초기에는 간단히 무한 루프만 사용하고 나중에 개선하세요.
💡 _start 함수의 반환 타입 !(never type)는 이 함수가 절대 반환하지 않음을 나타냅니다. 베어메탈 환경에서는 반환할 곳이 없기 때문입니다.
💡 디버깅 중에 패닉이 발생하면 QEMU의 -d int 옵션을 사용하여 CPU 상태를 확인할 수 있습니다.
💡 core::fmt 모듈을 활용하면 표준 라이브러리 없이도 포맷팅 기능을 구현할 수 있습니다. 커스텀 출력 라이터를 만들어 println! 매크로를 재구현할 수 있습니다.
3. 링커 스크립트 작성 - 메모리 레이아웃의 정확한 제어
시작하며
여러분이 OS 바이너리를 만들었는데 부팅이 안 되거나 이상한 주소에서 실행된다면? 링커가 코드와 데이터를 적절한 메모리 위치에 배치하지 못했기 때문입니다.
일반적인 프로그램은 운영체제가 메모리를 관리하므로 링커가 임의의 주소를 사용해도 괜찮습니다. 하지만 OS 커널은 특정 물리 메모리 주소에 로드되어야 하며, 부트로더가 기대하는 위치에 정확히 배치되어야 합니다.
바로 이럴 때 필요한 것이 커스텀 링커 스크립트입니다. 링커 스크립트를 통해 코드, 데이터, BSS 섹션이 정확히 어디에 위치할지 바이트 단위로 제어할 수 있습니다.
개요
간단히 말해서, 링커 스크립트는 링커에게 프로그램의 각 부분을 메모리의 어느 주소에 배치할지 알려주는 설정 파일입니다. 베어메탈 OS에서 링커 스크립트가 필요한 이유는 명확합니다.
부트로더(예: GRUB)는 커널이 특정 주소(보통 1MB 위치)에 로드되기를 기대합니다. 또한 멀티부트 헤더는 바이너리의 시작 부분에 정확히 배치되어야 부트로더가 인식할 수 있습니다.
예를 들어, 멀티부트2 사양은 헤더가 첫 8KB 내에 있어야 한다고 명시합니다. 기존에는 링커가 기본 링커 스크립트를 사용했다면, 이제는 완전히 커스터마이징된 메모리 맵을 정의할 수 있습니다.
링커 스크립트의 핵심 특징은 다음과 같습니다. 첫째, SECTIONS 명령으로 각 섹션의 시작 주소를 지정할 수 있고, 둘째, ALIGN 명령으로 페이지 경계에 맞출 수 있으며, 셋째, KEEP 명령으로 사용되지 않는 것처럼 보이는 섹션도 보존할 수 있습니다.
이러한 기능들이 정확한 메모리 레이아웃을 보장합니다.
코드 예제
/* linker.ld - 커널용 링커 스크립트 */
ENTRY(_start) /* 진입점 심볼 */
SECTIONS
{
/* 커널을 1MB에 로드 - 부트로더 규약 */
. = 1M;
/* 텍스트 섹션 - 실행 코드 */
.text : ALIGN(4K) {
*(.multiboot_header) /* 부트 헤더가 맨 앞에 */
*(.text .text.*)
}
/* 읽기 전용 데이터 */
.rodata : ALIGN(4K) {
*(.rodata .rodata.*)
}
/* 읽기-쓰기 데이터 */
.data : ALIGN(4K) {
*(.data .data.*)
}
/* BSS - 초기화되지 않은 데이터 */
.bss : ALIGN(4K) {
*(.bss .bss.*)
}
}
설명
이것이 하는 일은 링커에게 커널의 각 섹션을 정확히 어디에 배치할지 지시하는 것입니다. 이는 부팅 가능한 OS를 만드는 데 필수적입니다.
첫 번째로, ENTRY(_start)는 프로그램의 진입점을 지정합니다. 부트로더는 이 심볼로 점프하여 커널 실행을 시작합니다.
. = 1M은 위치 카운터를 1MB(0x100000)로 설정합니다.
이는 x86 아키텍처에서 확장 메모리의 시작 주소이며, 대부분의 부트로더가 커널을 로드하는 표준 위치입니다. 그 다음으로, .text 섹션이 정의됩니다.
ALIGN(4K)는 이 섹션을 4KB 경계에 정렬하여 페이징을 사용할 때 효율적입니다. *(.multiboot_header)는 모든 입력 파일의 .multiboot_header 섹션을 맨 앞에 배치합니다.
이는 매우 중요한데, 부트로더가 바이너리 시작 부분에서 멀티부트 매직 넘버를 찾기 때문입니다. .rodata, .data, .bss 섹션도 각각 4KB 경계에 정렬되어 배치됩니다.
.rodata는 문자열 리터럴 같은 읽기 전용 데이터를 담고, .data는 초기화된 전역 변수를, .bss는 초기화되지 않은 전역 변수를 담습니다. 각 섹션의 정렬은 나중에 페이지 테이블을 설정할 때 권한(실행, 읽기, 쓰기)을 정확히 제어할 수 있게 해줍니다.
여러분이 이 링커 스크립트를 사용하면 부트로더가 인식하고 로드할 수 있는 정확한 형식의 커널 바이너리를 생성할 수 있습니다. 모든 섹션이 예측 가능한 위치에 배치되어 디버깅이 쉬워지며, 페이지 경계 정렬 덕분에 나중에 가상 메모리를 구현할 때도 유리합니다.
실전 팁
💡 링커 스크립트에서 심볼을 정의할 수 있습니다(예: _kernel_start = .;). Rust 코드에서 이 심볼의 주소를 읽어 커널 크기나 경계를 알 수 있습니다.
💡 KEEP() 명령을 사용하여 .multiboot_header 같은 섹션이 최적화로 제거되지 않도록 보호하세요: KEEP(*(.multiboot_header))
💡 4KB 정렬은 x86 페이징의 기본 페이지 크기와 일치합니다. 큰 페이지(2MB)를 사용하려면 정렬을 2M으로 변경할 수 있습니다.
💡 링커 스크립트 수정 후 cargo clean을 실행하지 않아도 변경사항이 적용됩니다. 하지만 이상한 동작이 보이면 클린 빌드를 시도해보세요.
💡 ld --verbose 명령으로 기본 링커 스크립트를 확인할 수 있습니다. 이를 참고하여 커스텀 스크립트를 작성하면 도움이 됩니다.
4. Cargo 빌드 설정 - 자동화된 크로스 컴파일
시작하며
여러분이 매번 cargo build --target x86_64-unknown-none.json -Zbuild-std=core -Zbuild-std-features=compiler-builtins-mem 같은 긴 명령을 타이핑하는 것에 지쳤다면? 이런 반복적인 작업은 실수를 유발하고 개발 속도를 늦춥니다.
Cargo는 강력한 빌드 도구이지만, 베어메탈 개발을 위해서는 많은 비표준 옵션이 필요합니다. 타겟 지정, 표준 라이브러리 재빌드, 링커 스크립트 전달 등 매번 기억하기 어려운 설정들이 많습니다.
바로 이럴 때 필요한 것이 .cargo/config.toml 파일입니다. 이 설정 파일을 통해 프로젝트별 기본값을 정의하여 간단한 cargo build만으로 모든 것이 올바르게 작동하게 만들 수 있습니다.
개요
간단히 말해서, .cargo/config.toml은 Cargo의 동작을 프로젝트별로 커스터마이징하는 설정 파일입니다. OS 개발에서 이 파일이 필요한 이유는 여러 가지입니다.
기본 타겟을 설정하여 매번 --target을 지정할 필요가 없고, 링커 인자를 자동으로 전달하며, 빌드 플래그를 미리 정의할 수 있습니다. 예를 들어, core 라이브러리를 소스에서 재빌드하는 불안정한 기능도 이 파일에 명시할 수 있습니다.
기존에는 명령줄에서 모든 옵션을 지정했다면, 이제는 한 번 설정 파일을 작성하면 팀 전체가 동일한 빌드 환경을 공유할 수 있습니다. .cargo/config.toml의 핵심 특징은 다음과 같습니다.
첫째, 프로젝트 루트에 위치하여 버전 관리에 포함되고, 둘째, 타겟별로 다른 설정을 지정할 수 있으며, 셋째, 환경 변수로 오버라이드 가능합니다. 이러한 유연성이 복잡한 빌드 워크플로우를 단순화합니다.
코드 예제
# .cargo/config.toml - Cargo 빌드 설정
[build]
# 기본 타겟 지정
target = "x86_64-unknown-none.json"
[unstable]
# core/alloc 재빌드 활성화
build-std = ["core", "compiler_builtins"]
build-std-features = ["compiler-builtins-mem"]
[target.'cfg(target_os = "none")']
# 링커 인자 전달
rustflags = [
"-C", "link-arg=-T/home/dev-cardnews/linker.ld",
"-C", "link-arg=--gc-sections",
]
# 별칭 정의로 빌드 간소화
[alias]
kbuild = "build --release"
krun = "run --release"
설명
이것이 하는 일은 복잡한 크로스 컴파일 명령을 단순한 cargo build로 바꾸는 것입니다. 모든 필요한 설정이 자동으로 적용됩니다.
첫 번째로, [build] 섹션의 target 필드가 기본 타겟을 지정합니다. 이제 --target 플래그 없이 빌드해도 자동으로 우리의 커스텀 타겟이 사용됩니다.
파일 경로는 프로젝트 루트에 상대적이므로 x86_64-unknown-none.json이 루트에 있어야 합니다. 그 다음으로, [unstable] 섹션이 실험적 기능을 활성화합니다.
build-std는 core와 compiler_builtins를 소스에서 재빌드하도록 지시합니다. 이는 우리의 커스텀 타겟에 맞게 이 라이브러리들을 최적화하기 위함입니다.
build-std-features는 컴파일러 내장 함수(memcpy, memset 등)를 포함시킵니다. [target.'cfg(target_os = "none")'] 섹션은 OS가 "none"인 타겟에만 적용되는 설정입니다.
rustflags에 링커 인자를 전달합니다. -T 플래그는 링커 스크립트를 지정하고, --gc-sections는 사용되지 않는 섹션을 제거하여 바이너리 크기를 줄입니다.
절대 경로를 사용하거나 프로젝트 루트 기준 상대 경로를 사용해야 합니다. 마지막으로, [alias] 섹션은 자주 사용하는 명령의 단축키를 정의합니다.
cargo kbuild는 릴리스 빌드를, cargo krun은 QEMU에서 실행하는 명령을 단순화합니다. 이런 별칭은 개발 워크플로우를 크게 개선합니다.
여러분이 이 설정을 사용하면 복잡한 빌드 옵션을 외우지 않아도 되고, 팀원들과 일관된 빌드 환경을 공유할 수 있습니다. 새로운 팀원이 프로젝트를 클론하고 cargo build만 실행하면 모든 것이 자동으로 올바르게 작동합니다.
CI/CD 파이프라인에서도 동일한 설정이 적용되어 "내 컴퓨터에서는 되는데" 문제를 방지합니다.
실전 팁
💡 build-std를 사용하려면 나이틀리 러스트가 필요합니다. rustup override set nightly로 프로젝트별로 나이틀리를 설정하세요.
💡 링커 스크립트 경로는 절대 경로를 사용하는 것이 안전합니다. 상대 경로는 작업 디렉토리에 따라 다르게 해석될 수 있습니다.
💡 --gc-sections는 Dead Code Elimination을 활성화합니다. panic 핸들러가 제거되지 않도록 주의하세요(사용하지 않는 것처럼 보일 수 있음).
💡 환경 변수 RUSTFLAGS로 설정을 오버라이드할 수 있지만, config.toml의 설정을 교체하므로 추가가 아닙니다. 추가하려면 cargo rustc를 사용하세요.
💡 여러 타겟을 지원해야 한다면 [target.x86_64-unknown-none] 형식으로 타겟별 섹션을 만들 수 있습니다. 조건부 컴파일과 결합하면 멀티 아키텍처 OS를 구축할 수 있습니다.
5. 멀티부트 헤더 구현 - 부트로더와의 통신
시작하며
여러분이 완벽하게 컴파일된 커널 바이너리를 GRUB으로 부팅하려 했는데 "not a valid kernel" 에러가 발생한다면? 부트로더가 여러분의 바이너리를 커널로 인식하지 못했기 때문입니다.
부트로더와 커널 사이에는 일종의 "악수(handshake)" 프로토콜이 필요합니다. GRUB 같은 부트로더는 멀티부트 규격을 사용하여 커널을 식별합니다.
바이너리에 특정 매직 넘버와 정보가 포함되어 있지 않으면 부트로더는 이를 무시합니다. 바로 이럴 때 필요한 것이 멀티부트 헤더입니다.
이 헤더를 바이너리의 시작 부분에 정확히 배치하면 부트로더가 커널을 인식하고 로드할 수 있습니다.
개요
간단히 말해서, 멀티부트 헤더는 커널 바이너리에 포함된 메타데이터로, 부트로더에게 "나는 유효한 커널이며, 이렇게 로드해주세요"라고 알려주는 역할을 합니다. 멀티부트 헤더가 필요한 이유는 명확합니다.
부트로더는 여러 종류의 바이너리(부트 섹터, ELF 실행 파일, PE 이미지 등)를 구분해야 합니다. 멀티부트 매직 넘버(0x1BADB002 또는 Multiboot2의 0xE85250D6)를 찾아서 유효한 커널인지 확인합니다.
예를 들어, GRUB은 바이너리의 첫 8KB를 스캔하여 이 매직 넘버를 찾습니다. 기존에는 어셈블리로 부트 코드를 작성했다면, 이제는 Rust의 global_asm! 매크로를 사용하여 안전하게 작성할 수 있습니다.
멀티부트 헤더의 핵심 특징은 다음과 같습니다. 첫째, 매직 넘버로 커널을 식별하고, 둘째, 플래그로 요청 사항(메모리 정보, 프레임버퍼 등)을 명시하며, 셋째, 체크섬으로 헤더의 무결성을 검증합니다.
이러한 정보들이 부트로더와 커널 간의 안전한 전환을 보장합니다.
코드 예제
// src/boot.rs - 멀티부트2 헤더
use core::arch::global_asm;
// 멀티부트2 헤더를 별도 섹션에 배치
global_asm!(
".section .multiboot_header",
"header_start:",
" .long 0xe85250d6", // 매직 넘버
" .long 0", // i386 보호 모드
" .long header_end - header_start", // 헤더 길이
" .long -(0xe85250d6 + 0 + (header_end - header_start))", // 체크섬
// 태그: 종료 태그
" .short 0", // 타입
" .short 0", // 플래그
" .long 8", // 크기
"header_end:"
);
설명
이것이 하는 일은 부트로더가 읽을 수 있는 표준화된 헤더를 바이너리에 삽입하는 것입니다. GRUB이 이 헤더를 발견하면 커널을 메모리에 로드하고 제어를 전달합니다.
첫 번째로, .section .multiboot_header 지시어가 이 코드를 특별한 섹션에 배치합니다. 링커 스크립트에서 이 섹션을 .text의 맨 앞에 배치했던 것을 기억하세요.
이렇게 하면 헤더가 바이너리의 시작 부분에 위치하게 됩니다. 매직 넘버 0xe85250d6은 멀티부트2 규격의 식별자입니다.
부트로더는 바이너리를 스캔하면서 이 값을 찾습니다. 두 번째 필드 0은 아키텍처를 나타내며, 0은 i386 보호 모드를 의미합니다(x86_64도 이 모드로 시작합니다).
세 번째 필드는 헤더의 전체 길이입니다. 그 다음으로, 체크섬이 계산됩니다.
체크섬은 -(매직 넘버 + 아키텍처 + 헤더 길이)로 계산되며, 이 네 값(매직, 아키텍처, 길이, 체크섬)을 모두 더하면 0이 되어야 합니다. 이는 헤더가 손상되지 않았음을 검증하는 간단한 방법입니다.
마지막으로, 종료 태그가 추가됩니다. 멀티부트2는 태그 기반 형식으로, 요청하는 기능마다 태그를 추가합니다.
타입 0, 크기 8인 태그는 "더 이상 태그가 없다"는 의미의 종료 태그입니다. 메모리 맵이나 프레임버퍼 정보가 필요하면 종료 태그 전에 해당 태그들을 추가할 수 있습니다.
여러분이 이 헤더를 사용하면 GRUB이나 다른 멀티부트2 호환 부트로더로 커널을 부팅할 수 있습니다. 부트로더는 커널을 메모리에 로드하고, CPU를 보호 모드(또는 롱 모드)로 전환하며, 멀티부트 정보 구조체의 주소를 레지스터에 담아 _start 함수로 점프합니다.
이 정보 구조체에는 메모리 맵, 커널 명령줄, 부트 모듈 등 유용한 데이터가 포함되어 있습니다.
실전 팁
💡 멀티부트2 대신 멀티부트1을 사용하려면 매직 넘버를 0x1BADB002로 변경하세요. 하지만 멀티부트2가 더 현대적이고 기능이 풍부합니다.
💡 프레임버퍼를 요청하려면 타입 5 태그를 추가하세요. 이렇게 하면 부트로더가 그래픽 모드를 설정해줍니다: .short 5, .short 0, .long 20, .long 1024, .long 768, .long 32
💡 멀티부트 정보 구조체는 부트로더가 제공하는 메모리에 있습니다. 이 메모리를 덮어쓰지 않도록 주의하세요. 필요한 정보는 커널 초기화 단계에서 복사해두는 것이 좋습니다.
💡 체크섬 계산이 복잡하다면 빌드 스크립트에서 자동으로 계산하도록 만들 수 있습니다. build.rs에서 헤더를 생성하고 const로 포함시키는 방법도 있습니다.
💡 QEMU로 테스트할 때 -kernel 옵션을 사용하면 GRUB 없이도 멀티부트 커널을 직접 로드할 수 있습니다. 개발 초기 단계에서 부팅 시간을 단축하는 데 유용합니다.
6. 부트스트랩 어셈블리 - CPU 초기화와 Rust로의 전환
시작하며
여러분이 멀티부트 헤더까지 완벽하게 작성했는데 Rust 코드가 전혀 실행되지 않는다면? CPU가 부팅 직후의 원시적인 상태에서 Rust 코드를 실행하기에 적합한 환경이 아니기 때문입니다.
부트로더는 커널을 메모리에 로드하고 제어를 전달하지만, CPU는 여전히 불안정한 상태입니다. 스택이 설정되지 않았고, 세그먼트 레지스터가 유효하지 않으며, SSE/AVX 같은 확장 기능도 비활성화되어 있습니다.
이 상태에서 Rust 코드를 실행하면 즉시 크래시가 발생합니다. 바로 이럴 때 필요한 것이 부트스트랩 어셈블리입니다.
어셈블리로 최소한의 환경을 구축한 후 Rust의 _start 함수로 안전하게 전환할 수 있습니다.
개요
간단히 말해서, 부트스트랩 어셈블리는 CPU를 초기화하고 Rust 코드 실행을 위한 런타임 환경을 설정하는 저수준 코드입니다. 부트스트랩 코드가 필요한 이유는 여러 가지입니다.
가장 중요한 것은 스택 설정입니다. Rust 함수는 스택을 사용하여 로컬 변수와 반환 주소를 저장하는데, 부팅 직후에는 스택 포인터가 유효한 메모리를 가리키지 않습니다.
예를 들어, 함수 호출 시 push 명령이 실행되면 잘못된 메모리에 쓰기를 시도하여 트리플 폴트가 발생합니다. 기존에는 C 런타임이 이런 초기화를 담당했다면, 이제는 우리가 직접 모든 것을 제어할 수 있습니다.
부트스트랩 어셈블리의 핵심 특징은 다음과 같습니다. 첫째, 스택 공간을 BSS 섹션에 예약하고 스택 포인터를 설정하며, 둘째, 필요한 CPU 기능을 활성화하고, 셋째, Rust 함수로 제어를 안전하게 전달합니다.
이러한 초기화가 안정적인 실행 환경을 만듭니다.
코드 예제
// src/boot.s (어셈블리 파일로 저장)
.section .bss
.align 16
stack_bottom:
.skip 16384 // 16KB 스택
stack_top:
.section .text
.global _start
_start:
// 스택 포인터 설정
mov $stack_top, %esp
// EFLAGS 레지스터 초기화
push $0
popf
// Rust 진입점 호출
call rust_main
// rust_main이 반환하면 무한 루프
halt_loop:
cli
hlt
jmp halt_loop
// src/main.rs에서 참조할 심볼
.global rust_main
설명
이것이 하는 일은 CPU를 "원시 부팅 상태"에서 "Rust 코드 실행 가능 상태"로 전환하는 것입니다. 이는 모든 베어메탈 프로그래밍의 필수 단계입니다.
첫 번째로, .bss 섹션에 스택 공간이 예약됩니다. .skip 16384는 16KB의 0으로 초기화된 메모리를 예약합니다.
stack_bottom과 stack_top 레이블은 이 영역의 경계를 표시합니다. x86에서 스택은 아래로 자라므로 stack_top이 실제로는 높은 주소입니다.
.align 16은 스택을 16바이트 경계에 정렬하여 SSE 명령어와의 호환성을 보장합니다. 그 다음으로, _start 함수가 실행됩니다.
부트로더는 이 심볼로 점프했습니다. mov $stack_top, %esp는 스택 포인터(%esp)를 우리가 예약한 스택의 상단으로 설정합니다.
이제 push, pop, call 명령어를 안전하게 사용할 수 있습니다. push $0; popf는 EFLAGS 레지스터를 0으로 초기화하여 알 수 없는 플래그 상태를 제거합니다.
call rust_main은 Rust로 작성된 메인 함수를 호출합니다. 이 함수는 #[no_mangle] extern "C" fn rust_main() -> !으로 정의되어야 합니다.
호출 후 제어가 Rust 코드로 넘어가며, 이제 안전하게 Rust의 모든 기능을 사용할 수 있습니다. 마지막으로, rust_main이 반환하면(절대 반환해서는 안 되지만 방어적으로) halt_loop로 진입합니다.
cli는 인터럽트를 비활성화하고, hlt는 CPU를 정지시킵니다. jmp halt_loop는 외부 인터럽트가 CPU를 깨우면 다시 정지하도록 합니다.
여러분이 이 부트스트랩 코드를 사용하면 Rust의 모든 기능을 안전하게 활용할 수 있습니다. 함수 호출, 로컬 변수, 패턴 매칭 등 모든 것이 정상적으로 작동합니다.
스택이 제대로 설정되었으므로 재귀 호출도 가능하며, 나중에 인터럽트를 활성화할 때도 스택이 준비되어 있습니다.
실전 팁
💡 16KB 스택은 초기 개발에 충분하지만, 복잡한 OS에서는 부족할 수 있습니다. 나중에 각 태스크마다 독립적인 스택을 할당하게 됩니다.
💡 64비트 롱 모드로 전환하려면 페이징을 먼저 활성화해야 합니다. 이는 더 복잡한 부트스트랩 코드가 필요하므로 별도 단계로 구현하세요.
💡 어셈블리 파일을 프로젝트에 포함하려면 build.rs를 작성하여 cc 크레이트로 어셈블해야 합니다. 또는 global_asm!을 사용하여 Rust 파일 내에 인라인으로 포함시킬 수도 있습니다.
💡 디버깅 시 GDB에서 info registers로 레지스터 상태를 확인하세요. 특히 %esp가 유효한 범위(stack_bottom과 stack_top 사이)를 가리키는지 확인하는 것이 중요합니다.
💡 멀티코어 시스템에서는 부트스트랩 프로세서(BSP)만 _start를 실행합니다. 다른 프로세서(AP)는 별도의 진입점과 스택이 필요하므로 SMP 구현 시 고려해야 합니다.
7. 빌드 스크립트 통합 - 어셈블리와 Rust의 결합
시작하며
여러분이 어셈블리 파일을 작성했는데 Cargo가 이를 인식하지 못한다면? Cargo는 기본적으로 Rust 파일만 처리하므로, 어셈블리 파일은 별도로 컴파일하고 링크해야 합니다.
복잡한 OS 프로젝트에서는 여러 언어와 도구가 함께 사용됩니다. 어셈블리 부트 코드, Rust 커널 로직, 링커 스크립트 등이 모두 조화롭게 작동해야 합니다.
수동으로 이들을 컴파일하고 링크하는 것은 오류가 발생하기 쉽고 비효율적입니다. 바로 이럴 때 필요한 것이 Cargo 빌드 스크립트(build.rs)입니다.
이 스크립트를 통해 빌드 프로세스를 자동화하고 모든 컴포넌트를 올바르게 통합할 수 있습니다.
개요
간단히 말해서, build.rs는 Cargo가 메인 컴파일을 시작하기 전에 실행하는 Rust 프로그램으로, 코드 생성, 외부 도구 실행, 빌드 설정 변경 등을 수행합니다. OS 개발에서 빌드 스크립트가 필요한 이유는 명확합니다.
어셈블리 파일을 어셈블러로 컴파일하고, 생성된 오브젝트 파일을 Cargo에 알려주며, 링커 스크립트 경로를 전달하고, 외부 도구(nasm, gcc 등)를 호출해야 합니다. 예를 들어, boot.s 파일을 boot.o로 어셈블하고 이를 최종 바이너리에 링크하는 과정을 자동화할 수 있습니다.
기존에는 Makefile을 사용했다면, 이제는 Rust로 작성된 빌드 스크립트로 플랫폼 독립적인 빌드 시스템을 구축할 수 있습니다. 빌드 스크립트의 핵심 특징은 다음과 같습니다.
첫째, Cargo와 완전히 통합되어 의존성 관리를 활용할 수 있고, 둘째, 크로스 플랫폼으로 작동하며, 셋째, 증분 빌드를 지원하여 변경된 파일만 재컴파일합니다. 이러한 기능들이 복잡한 빌드를 간단하게 만듭니다.
코드 예제
// build.rs - Cargo 빌드 스크립트
use std::env;
use std::path::PathBuf;
fn main() {
// 어셈블리 소스 경로
let asm_file = "src/boot.s";
// 출력 디렉토리 가져오기
let out_dir = PathBuf::from(env::var("OUT_DIR").unwrap());
let obj_file = out_dir.join("boot.o");
// GNU 어셈블러로 컴파일
let status = std::process::Command::new("as")
.args(&["--32", asm_file, "-o"])
.arg(&obj_file)
.status()
.expect("어셈블러 실행 실패");
assert!(status.success(), "어셈블리 컴파일 실패");
// Cargo에 오브젝트 파일 링크 지시
println!("cargo:rustc-link-arg={}", obj_file.display());
// 파일 변경 감지
println!("cargo:rerun-if-changed={}", asm_file);
}
설명
이것이 하는 일은 빌드 과정을 완전히 자동화하는 것입니다. 개발자는 단순히 cargo build를 실행하면 모든 컴포넌트가 올바르게 빌드됩니다.
첫 번째로, 환경 변수 OUT_DIR에서 Cargo가 지정한 출력 디렉토리를 가져옵니다. 이 디렉토리는 target/debug/build/프로젝트명-해시/out/ 같은 형태이며, 빌드 아티팩트를 저장하는 임시 공간입니다.
obj_file 경로를 이 디렉토리 아래에 생성하여 오브젝트 파일을 저장할 위치를 결정합니다. 그 다음으로, std::process::Command로 GNU 어셈블러(as)를 실행합니다.
--32 플래그는 32비트 코드를 생성하도록 지시합니다(부팅 초기는 보호 모드이므로). -o 옵션으로 출력 파일을 지정합니다.
status() 메서드는 프로세스가 완료될 때까지 기다렸다가 종료 상태를 반환합니다. assert!(status.success())는 어셈블리 컴파일이 실패하면 빌드를 중단시킵니다.
이렇게 하면 부분적으로 빌드된 바이너리가 생성되는 것을 방지할 수 있습니다. println!("cargo:rustc-link-arg=...")는 특별한 형식으로, Cargo에게 링커에 추가 인자를 전달하도록 지시합니다.
이 경우 boot.o 파일을 링크하라고 알려줍니다. 마지막으로, println!("cargo:rerun-if-changed=...")는 Cargo의 증분 빌드 시스템에 boot.s 파일이 변경되었을 때만 이 빌드 스크립트를 다시 실행하라고 알려줍니다.
이렇게 하면 Rust 파일만 변경되었을 때는 어셈블리를 다시 컴파일하지 않아 빌드 시간이 단축됩니다. 여러분이 이 빌드 스크립트를 사용하면 개발 워크플로우가 크게 간소화됩니다.
어셈블리 파일을 수정하고 cargo build만 실행하면 자동으로 재컴파일되고 링크됩니다. 팀원들은 별도의 빌드 도구를 설치할 필요 없이(GNU binutils만 있으면 됨) 프로젝트를 빌드할 수 있습니다.
CI/CD 파이프라인에서도 동일한 명령으로 재현 가능한 빌드를 수행할 수 있습니다.
실전 팁
💡 build.rs의 의존성은 [build-dependencies] 섹션에 추가해야 합니다. 예를 들어 cc 크레이트를 사용하면 크로스 플랫폼 C/어셈블리 컴파일이 간편해집니다.
💡 NASM을 사용하려면 as 대신 nasm -f elf32로 변경하세요. NASM 문법은 AT&T 문법과 다르므로 어셈블리 파일도 수정해야 합니다.
💡 여러 어셈블리 파일이 있다면 glob 크레이트로 패턴 매칭하여 모두 컴파일할 수 있습니다: glob("src/**/*.s")
💡 빌드 스크립트가 실행되지 않는 것 같으면 cargo clean을 시도하세요. 때로는 캐시가 꼬여서 재실행되지 않을 수 있습니다.
💡 크로스 컴파일 시 호스트 시스템의 어셈블러가 아닌 타겟용 어셈블러를 사용해야 합니다. 환경 변수 TARGET을 확인하여 적절한 툴체인을 선택하세요.
8. QEMU 테스트 환경 - 빠른 개발 사이클
시작하며
여러분이 커널을 수정할 때마다 실제 하드웨어에 설치하고 재부팅해야 한다면? 개발 속도가 극도로 느려지고, 잘못된 코드로 시스템을 망가뜨릴 위험도 있습니다.
실제 하드웨어 테스트는 최종 단계에서 필요하지만, 개발 중에는 너무 느리고 위험합니다. USB 드라이브에 이미지를 쓰고, 부팅하고, 결과를 확인하는 과정은 몇 분씩 걸립니다.
버그가 있으면 시스템이 크래시하고 다시 시작해야 합니다. 바로 이럴 때 필요한 것이 QEMU 가상화입니다.
QEMU는 x86 하드웨어를 에뮬레이션하여 몇 초 만에 커널을 테스트할 수 있게 해주며, 강력한 디버깅 기능도 제공합니다.
개요
간단히 말해서, QEMU는 하드웨어 가상화 도구로, 실제 CPU를 에뮬레이션하여 OS를 안전하게 테스트할 수 있는 환경을 제공합니다. OS 개발에서 QEMU가 필수적인 이유는 여러 가지입니다.
첫째, 부팅 시간이 1초 미만으로 빠릅니다. 둘째, 잘못된 코드로 호스트 시스템을 망가뜨리지 않습니다.
셋째, GDB와 통합되어 소스 레벨 디버깅이 가능합니다. 예를 들어, 메모리 접근 오류를 일으키는 버그를 작성해도 QEMU만 종료되고 호스트는 안전합니다.
기존에는 VirtualBox 같은 무거운 가상화 도구를 사용했다면, 이제는 명령줄 기반의 빠르고 가벼운 QEMU를 사용할 수 있습니다. QEMU의 핵심 특징은 다음과 같습니다.
첫째, -kernel 옵션으로 멀티부트 커널을 직접 로드할 수 있고, 둘째, 시리얼 포트를 stdio로 리다이렉트하여 로그를 쉽게 볼 수 있으며, 셋째, -s -S 옵션으로 GDB 서버를 시작하여 단계별 디버깅이 가능합니다. 이러한 기능들이 개발 생산성을 극적으로 향상시킵니다.
코드 예제
# Makefile 또는 스크립트에 추가할 QEMU 실행 명령
# 기본 실행 - 커널 부팅
qemu-system-x86_64 \
-kernel target/x86_64-unknown-none/debug/my_os \
-serial stdio \
-display none
# 디버그 모드 - GDB 연결 대기
qemu-system-x86_64 \
-kernel target/x86_64-unknown-none/debug/my_os \
-serial stdio \
-display none \
-s -S
# GDB 연결 (별도 터미널에서)
gdb target/x86_64-unknown-none/debug/my_os \
-ex "target remote :1234" \
-ex "break rust_main" \
-ex "continue"
설명
이것이 하는 일은 개발 중인 OS를 실제 하드웨어에 설치하지 않고도 실행하고 테스트할 수 있게 하는 것입니다. 몇 초 만에 빌드-테스트 사이클을 완료할 수 있습니다.
첫 번째로, qemu-system-x86_64 명령이 x86_64 아키텍처를 에뮬레이션하는 QEMU 인스턴스를 시작합니다. -kernel 옵션은 바이너리를 멀티부트 커널로 직접 로드합니다.
이는 GRUB 이미지를 만들 필요 없이 커널을 즉시 부팅할 수 있게 해주며, 개발 초기 단계에서 매우 유용합니다. 그 다음으로, -serial stdio가 가상 머신의 첫 번째 시리얼 포트를 호스트의 표준 입출력으로 연결합니다.
커널에서 시리얼 포트로 데이터를 보내면(UART 0x3F8 포트) 터미널에 출력됩니다. 이는 VGA 텍스트 모드를 구현하기 전에 로그를 출력하는 가장 간단한 방법입니다.
-display none은 그래픽 창을 띄우지 않아 터미널에서만 작업할 수 있게 합니다. 디버그 모드에서는 -s -S 옵션이 추가됩니다.
-s는 TCP 포트 1234에 GDB 서버를 시작하고, -S는 CPU를 정지 상태로 시작하여 GDB가 연결될 때까지 기다립니다. 이렇게 하면 커널의 첫 명령어부터 단계별로 실행을 추적할 수 있습니다.
별도 터미널에서 GDB를 실행하면 QEMU에 연결됩니다. target remote :1234는 GDB 원격 프로토콜로 QEMU에 접속하고, break rust_main은 Rust 메인 함수에 중단점을 설정하며, continue는 실행을 재개합니다.
이제 step, next, print 같은 GDB 명령으로 코드를 탐색할 수 있습니다. 여러분이 QEMU를 사용하면 개발 속도가 10배 이상 빨라집니다.
코드를 수정하고 즉시 결과를 확인할 수 있으며, 버그가 발생해도 단순히 QEMU를 재시작하면 됩니다. 여러 QEMU 인스턴스를 동시에 실행하여 서로 다른 설정을 테스트할 수도 있습니다.
나중에는 자동화된 테스트 스위트를 만들어 커널의 각 기능이 올바르게 작동하는지 검증할 수 있습니다.
실전 팁
💡 -m 옵션으로 가상 머신의 메모리 크기를 조절할 수 있습니다. 기본값은 128MB이며, 메모리 관리 코드를 테스트할 때 유용합니다: -m 512M
💡 시리얼 출력을 파일로 저장하려면 -serial file:serial.log를 사용하세요. 나중에 로그를 분석하거나 회귀 테스트에 활용할 수 있습니다.
💡 QEMU 모니터 콘솔(Ctrl+Alt+2)을 사용하면 가상 머신 상태를 검사할 수 있습니다. info registers, info mem 같은 명령이 유용합니다.
💡 -d int,cpu_reset 옵션은 인터럽트와 CPU 리셋을 로그로 남깁니다. 트리플 폴트가 발생하는 이유를 추적할 때 필수적입니다.
💡 Cargo 별칭에 QEMU 실행을 추가하면 편리합니다: [alias]에 run = "build --release && !qemu-system-x86_64 -kernel target/.../my_os"
9. 크로스 컴파일 도구 체인 검증 - 빌드 환경 테스트
시작하며
여러분이 모든 설정을 완료하고 빌드를 실행했는데 이상한 에러가 발생한다면? 크로스 컴파일 도구 체인이 제대로 설치되지 않았거나, 버전이 호환되지 않기 때문일 수 있습니다.
베어메탈 개발은 많은 도구에 의존합니다. Rust 나이틀리, LLVM 도구들, GNU binutils, QEMU 등이 모두 올바른 버전으로 설치되어야 합니다.
하나라도 빠지거나 잘못 설치되면 빌드가 실패하거나 런타임 버그가 발생합니다. 바로 이럴 때 필요한 것이 도구 체인 검증 스크립트입니다.
개발을 시작하기 전에 필요한 모든 도구가 준비되었는지 자동으로 확인할 수 있습니다.
개요
간단히 말해서, 도구 체인 검증은 필요한 모든 개발 도구가 올바르게 설치되고 호환 가능한 버전인지 확인하는 프로세스입니다. 검증이 중요한 이유는 명확합니다.
복잡한 에러 메시지로 몇 시간을 낭비하는 대신, 시작부터 문제를 발견하고 수정할 수 있습니다. 또한 새로운 팀원이 프로젝트에 참여할 때 환경 설정이 올바른지 빠르게 확인할 수 있습니다.
예를 들어, Rust 스테이블 버전으로는 build-std 기능을 사용할 수 없으므로 나이틀리가 필수입니다. 기존에는 수동으로 각 도구를 확인했다면, 이제는 자동화된 스크립트로 모든 것을 한 번에 검증할 수 있습니다.
도구 체인 검증의 핵심 요소는 다음과 같습니다. 첫째, Rust 툴체인 버전 확인(나이틀리 필수), 둘째, 필요한 Rust 컴포넌트 설치 여부(rust-src 등), 셋째, 외부 도구 존재 확인(QEMU, 어셈블러 등).
이러한 검증이 원활한 개발 환경을 보장합니다.
코드 예제
#!/bin/bash
# check_toolchain.sh - 도구 체인 검증 스크립트
set -e # 에러 발생 시 중단
echo "=== Rust OS 개발 환경 검증 ==="
# Rust 나이틀리 확인
echo -n "Rust 나이틀리 버전: "
rustc --version | grep -q nightly || {
echo "ERROR: Rust 나이틀리가 필요합니다"
echo " rustup override set nightly 실행"
exit 1
}
rustc --version
# rust-src 컴포넌트 확인
echo -n "rust-src 컴포넌트: "
rustup component list | grep -q "rust-src.*installed" || {
echo "ERROR: rust-src 미설치"
echo " rustup component add rust-src 실행"
exit 1
}
echo "설치됨"
# LLVM 도구 확인
echo -n "rust-lld 링커: "
which rust-lld > /dev/null && echo "$(which rust-lld)" || {
echo "ERROR: rust-lld를 찾을 수 없음"
exit 1
}
# QEMU 확인
echo -n "QEMU 버전: "
qemu-system-x86_64 --version | head -n1 || {
echo "ERROR: QEMU 미설치"
exit 1
}
echo -e "\n✓ 모든 도구가 준비되었습니다!"
설명
이것이 하는 일은 개발에 필요한 모든 도구가 제자리에 있는지 자동으로 확인하는 것입니다. 문제가 발견되면 정확한 해결 방법을 알려줍니다.
첫 번째로, set -e가 스크립트를 안전 모드로 설정합니다. 어떤 명령이든 실패하면 스크립트가 즉시 중단되어 부분적으로 검증된 결과를 신뢰하는 것을 방지합니다.
각 섹션은 특정 도구나 컴포넌트를 검사합니다. Rust 나이틀리 버전 확인은 rustc --version 출력에 "nightly" 문자열이 포함되어 있는지 grep으로 검사합니다.
스테이블 버전이 설치되어 있으면 에러 메시지와 함께 rustup override set nightly 명령을 제안합니다. 이 명령은 현재 디렉토리에서만 나이틀리를 사용하도록 설정합니다.
그 다음으로, rust-src 컴포넌트가 설치되었는지 확인합니다. 이 컴포넌트는 build-std 기능에 필수이며, Rust 표준 라이브러리의 소스 코드를 포함합니다.
rustup component list의 출력에서 "rust-src"가 "installed"로 표시되는지 검사합니다. rust-lld 링커는 Rust 툴체인과 함께 제공되지만, PATH에 있는지 확인해야 합니다.
which 명령으로 실행 파일의 경로를 찾고, 찾지 못하면 Rust 재설치를 제안할 수 있습니다. QEMU도 비슷하게 검사하며, 버전 정보를 출력하여 사용자가 확인할 수 있게 합니다.
마지막으로, 모든 검사를 통과하면 성공 메시지를 출력합니다. 스크립트의 종료 코드가 0이면 모든 것이 준비된 것이고, 0이 아니면 문제가 있는 것입니다.
CI/CD 파이프라인에서도 이 스크립트를 실행하여 빌드 환경이 올바른지 확인할 수 있습니다. 여러분이 이 검증 스크립트를 사용하면 "내 컴퓨터에서는 되는데" 문제를 크게 줄일 수 있습니다.
새로운 개발자가 프로젝트에 참여할 때 이 스크립트를 실행하여 몇 초 만에 환경이 준비되었는지 확인할 수 있습니다. 문제가 발생하면 정확한 에러 메시지와 해결 방법이 제공되어 스스로 해결할 수 있습니다.
실전 팁
💡 스크립트를 scripts/ 디렉토리에 저장하고 실행 권한을 부여하세요: chmod +x scripts/check_toolchain.sh
💡 프로젝트 README에 이 스크립트 실행을 첫 단계로 포함시키면 신규 개발자 온보딩이 쉬워집니다.
💡 더 고급 버전은 최소 요구 버전을 확인할 수 있습니다. 예: QEMU 7.0 이상 필요 시 버전 번호를 파싱하여 비교
💡 Windows용 PowerShell 버전도 작성하면 크로스 플랫폼 개발이 가능합니다. 같은 로직을 PowerShell 문법으로 변환하세요.
💡 CI/CD에서 이 스크립트를 실패하면 빌드를 중단하도록 설정하세요. 잘못된 환경에서 빌드하여 시간을 낭비하는 것을 방지합니다.
10. 최소 바이너리 검증 - 부팅 가능한 첫 커널
시작하며
여러분이 모든 코드를 작성하고 빌드했는데 정말로 부팅 가능한지 확신이 서지 않는다면? 실제로 QEMU에서 실행하기 전에 바이너리가 올바른 형식인지 확인하는 것이 중요합니다.
복잡한 빌드 과정을 거쳐 생성된 바이너리는 여러 이유로 잘못될 수 있습니다. 링커 스크립트 오류, 멀티부트 헤더 누락, 잘못된 섹션 배치 등이 모두 부팅 실패로 이어집니다.
QEMU가 "not a valid kernel"이라고 말하면 무엇이 잘못되었는지 알기 어렵습니다. 바로 이럴 때 필요한 것이 바이너리 검증입니다.
objdump, readelf, file 같은 도구로 생성된 바이너리를 분석하여 예상대로 만들어졌는지 확인할 수 있습니다.
개요
간단히 말해서, 바이너리 검증은 생성된 실행 파일이 부트로더가 기대하는 형식과 내용을 가지고 있는지 분석하는 과정입니다. 바이너리 검증이 중요한 이유는 여러 가지입니다.
첫째, 부팅 실패의 원인을 빠르게 찾을 수 있습니다. 둘째, 링커 스크립트가 의도대로 작동하는지 확인할 수 있습니다.
셋째, 바이너리 크기와 구조를 모니터링하여 불필요한 코드나 데이터를 발견할 수 있습니다. 예를 들어, 멀티부트 헤더가 첫 8KB 내에 있는지 readelf로 확인할 수 있습니다.
기존에는 문제가 생기면 추측으로 디버깅했다면, 이제는 도구를 사용하여 정확한 정보를 얻을 수 있습니다. 바이너리 검증의 핵심 도구는 다음과 같습니다.
첫째, readelf로 ELF 헤더와 섹션 정보를 확인하고, 둘째, objdump로 디스어셈블하여 코드가 올바른 위치에 있는지 검사하며, 셋째, hexdump로 멀티부트 매직 넘버를 직접 확인합니다. 이러한 도구들이 바이너리의 내부를 투명하게 보여줍니다.
코드 예제
#!/bin/bash
# verify_binary.sh - 커널 바이너리 검증
KERNEL="target/x86_64-unknown-none/debug/my_os"
echo "=== 커널 바이너리 검증 ==="
# 파일 타입 확인
echo -e "\n[1] 파일 타입:"
file "$KERNEL"
# ELF 헤더 정보
echo -e "\n[2] ELF 헤더:"
readelf -h "$KERNEL" | grep -E "Machine|Entry"
# 섹션 배치 확인
echo -e "\n[3] 주요 섹션:"
readelf -S "$KERNEL" | grep -E "\.text|\.rodata|\.data|\.bss|multiboot"
# 멀티부트 매직 넘버 확인
echo -e "\n[4] 멀티부트 헤더 (처음 1KB):"
hexdump -C "$KERNEL" | head -20 | grep -E "d6 50 52 e8|02 b0 ad 1b"
if [ $? -eq 0 ]; then
echo "✓ 멀티부트 매직 넘버 발견"
else
echo "✗ 멀티부트 매직 넘버 없음"
fi
# 바이너리 크기
echo -e "\n[5] 바이너리 크기:"
ls -lh "$KERNEL" | awk '{print $5}'
설명
이것이 하는 일은 생성된 커널 바이너리를 여러 각도에서 검사하여 부팅에 필요한 모든 요소가 제자리에 있는지 확인하는 것입니다. 첫 번째로, file 명령이 바이너리의 기본 타입을 확인합니다.
출력은 "ELF 64-bit LSB executable, x86-64" 같은 형태여야 합니다. 이는 링커가 올바른 형식의 실행 파일을 생성했음을 나타냅니다.
만약 "data" 같은 결과가 나오면 링커 설정이 잘못된 것입니다. readelf -h는 ELF 헤더의 상세 정보를 출력합니다.
Machine 필드가 "Advanced Micro Devices X86-64"이고, Entry point address가 우리가 설정한 주소(보통 0x100000 또는 1MB)인지 확인합니다. 진입점이 잘못되면 부트로더가 엉뚱한 곳으로 점프하여 크래시가 발생합니다.
그 다음으로, readelf -S가 모든 섹션의 정보를 출력합니다. .text 섹션이 0x100000 근처에 있고, .multiboot_header 섹션이 .text보다 앞에 있는지 확인해야 합니다.
각 섹션의 주소가 4KB 경계(0x1000의 배수)에 정렬되어 있는지도 중요합니다. hexdump 명령으로 바이너리의 첫 부분을 16진수로 출력하여 멀티부트 매직 넘버를 직접 확인합니다.
멀티부트2의 경우 d6 50 52 e8 바이트 시퀀스(리틀 엔디안으로 0xe85250d6)를 찾습니다. 멀티부트1은 02 b0 ad 1b(0x1badb002)입니다.
이 넘버가 첫 8KB 내에 있어야 부트로더가 인식합니다. 마지막으로, 바이너리 크기를 확인합니다.
초기 커널은 보통 몇 KB에서 수십 KB 정도입니다. 만약 MB 단위로 커지면 불필요한 디버그 정보나 표준 라이브러리 코드가 포함되었을 가능성이 있습니다.
strip 명령이나 링커의 --gc-sections 옵션으로 크기를 줄일 수 있습니다. 여러분이 이 검증 스크립트를 사용하면 부팅 문제를 빠르게 진단할 수 있습니다.
빌드 후 자동으로 실행하여 CI/CD에 통합할 수도 있습니다. 각 빌드마다 바이너리 크기를 추적하면 코드 변경이 크기에 미치는 영향을 모니터링할 수 있어 최적화 목표를 설정하는 데 도움이 됩니다.
실전 팁
💡 nm 명령으로 심볼 테이블을 확인하세요. _start, rust_main 같은 중요한 심볼이 올바른 주소에 있는지 검증할 수 있습니다.
💡 objdump -d로 디스어셈블하면 실제 기계어 코드를 볼 수 있습니다. 진입점 주변 코드가 예상과 맞는지 확인하세요.
💡 바이너리를 ISO 이미지로 패키징하려면 grub-mkrescue를 사용하세요. 실제 하드웨어에 설치하거나 부트 가능한 USB를 만들 때 필요합니다.
💡 size 명령은 각 섹션의 크기를 요약하여 보여줍니다. .text, .data, .bss 크기를 추적하여 코드/데이터 비율을 모니터링하세요.
💡 멀티부트 검증 도구(mbchk)를 사용하면 헤더가 규격을 완전히 준수하는지 자동으로 확인할 수 있습니다. 패키지 매니저에서 grub-legacy 또는 multiboot를 설치하세요.