FreeBSD Assembly Language Programming

Preface

저자 : G. Adam Stanislav

Whiz Kid Technomagic

역자 : 최진희

jhchoi@os.korea.ac.kr

유닉스(unix) 환경에서의 어셈블리 언어 프로그래밍(assembly language programming)은 거의 문서화되지 않았다. 이것은 많은 사람들이 여러 유닉스 시스템이 서로 다른 마이크로프로세서(microprocessor)를 기반으로 동작하고 있기 때문에 이식성(portability)을 위해서라면 거의 모든 코드를 C로 써야 한다고 생각해 왔기 때문이다.

실제로는 C 조차 완벽한 이식성을 제공하지 못하기 때문에 하나의 유닉스에서 다른 종류의 유닉스로 포팅(porting)할 때 대부분의 C 프로그램은 수정되어야 한다. 일반적으로 이런 프로그램은 컴파일된 시스템에 의존적인 조건문(conditional statements)을 잔뜩 사용한 경우가 많다.

모든 유닉스 소프트웨어가 C나 그 밖의 고수준 언어(high level language)로 씌여져야 한다고 믿고 있다 할지라도 어셈블리 프로그래머는 여전히 필요하다. 어셈블리 프로그래머가 없다면 C 라이브러리(library)에서 커널에 접근하는 부분을 누가 쓸 것인가?

이 튜토리얼(tutorial)에서 필자는 어셈블리 언어를 이용하여 유닉스 프로그램- 특히 FreeBSD -을 쓰는 방법을 간단히 설명할 것이다. 필자는 이 문서가 언젠가는 FreeBSD 어셈블리 언어의 완벽한 가이드가 될 수 있기를 기원한다.

이 튜토리얼은 어셈블리 언어의 기본 내용을 설명하진 않는다. 이러한 기본 내용을 설명한 수많은 자료들이 있으니 참조하기 바란다.(어셈블리 언어를 완벽하게 설명한 온라인 가이드를 얻고 싶다면 Randall Hyde의 Art of Assembly Language를 추천하며, 인쇄된 책을 원한다면 Jeff Duntemann의 Assembly Language Step-by-Step을 추천한다.) 어쨌든 일단 이 튜토리얼을 끝까지 읽은 후에는 대부분의 어셈블리 프로그래머가 빠르고 효율적인 FreeBSD 프로그램을 작성할 수 있도록 구성했다.

Chapter 1 – The Tools

1.1. The Assembler

어셈블리 언어 프로그래밍을 할 때 가장 중요한 도구는 어셈블러, 즉 어셈블리 언어 코드를 기계어(machine language)로 변환해 주는 프로그램이다.

FreeBSD에서 사용할 수 있는 어셈블러로는 크게 두 가지 종류의 것이 있다. 그 중 하나는 as (1)인데, 전통적인 유닉스 어셈블리 언어의 문법을 따르고 있으며 일반적으로 시스템에 기본 탑재되어 있다.

다른 하나는 /usr/ports/devel/nasm이다. 이것은 인텔(Intel)의 문법을 따르는데, 여러 운영 체제를 위한 어셈블리 코드를 작성할 수 있다는 큰 장점이 있다. 이 어셈블러는 별도로 설치해야 하지만 공개 소프트웨어이기 걱정할 것은 없다.

이 튜토리얼은 nasm의 문법을 사용하는데, 이는 다른 운영체제 환경에서 어셈블리 언어를 사용하던 대부분의 프로그래머들이 이해하기 쉽도록 하기 위한 배려이다. 또, 솔직히 말하자면 필자가 사용하고 있는 어셈블러이기 때문이기도 하다.

1.2. The Linker

대부분의 컴파일러와 마찬가지로 어셈블러의 결과물(output)은 실행 가능한 파일로 링크(link)될 필요가 있다. 표준 ld (1) 링커(linker)는 FreeBSD에 탑재되어 있는데, 어떤 어셈블러에 의해서 만들어진 코드라도 실행 파일로 만들어 준다.

Chapter 2 – System Calls

2.1. Default Calling Convention

FreeBSD는 기본적으로 C의 호출 방식(calling convention)을 사용한다. 게다가 커널이 int 80h를 사용하여 접근되었다 할지라도, 커널은 프로그램 int 80h를 바로 사용한 것이 아니라 int 80h를 사용하는 함수를 호출했다고 가정한다.

이러한 관례는 배우 편리하며 MS DOS에서 사용된 마이크로소프트(Microsoft)의 관례에 비해 우월한 점이 많다. 이렇게 말할 수 있는 대표적인 근거는 유닉스에서 사용하는 관례에 따르면 어떤 언어로 작성된 프로그램이라도 커널에 접근할 수 있다는 것이다.

당연한 말이지만 어셈블리 언어로 작성된 프로그램도 커널에 접근할 수 있다. 가령, 다음과 같이 파일을 열 수 있다.

kernel:

int 80h ; Call kernel

ret

open:

push dword mode

push dword flags

push dword path

mov eax, 5

call kernel

add esp, byte 12

ret

이 코드는 매우 간결하며 이식하기도 쉽게 작성되었다. 만약 어떤 코드를 다른 인터럽트를 사용하거나 매개 변수(parameter)를 다른 방식으로 넘기는 유닉스 시스템으로 포팅한다면 kernel 프로시져(precedure)만 다시 작성하면 된다.

하지만 어셈블리 프로그래머는 CPU 주기(cycle)을 최대한 줄이고 싶어하는 경향이 있다. 위의 예는 call/ret 조합(combination)이 사용되었는데, dword를 푸시(push)하는 명령어(instruction) 하나면 이 코드를 제거할 수 있다.

open:

push dword mode

push dword flags

push dword path

mov eax, 5

push eax ; Or any other dword

int 80h

add esp, byte 16

EAX에 저장되는 5는 open이라는 커널 함수의 식별자(identifier)이다.

2.2. Alternate Calling Convention

FreeBSD는 아주 융통성 있는 시스템이다. 이 운영체제는 커널을 호출할 수 있는 다른 방법도 제공한다. 하지만 이러한 호출 방식이 제대로 동작하려면 리눅스(Linux) 애뮬레이션(emulation)이 시스템에 설치되어 있어야 한다.

리눅스는 유닉스 계열의 시스템 중 하나지만 커널은 레지스터에 매개 변수를 넘기는 마이크로소프트의 시스템 콜(call) 관례를 따르고 있다. 함수의 번호가 EAX 레지스터에 저장된다는 것은 유닉스의 호출 관례와 같다. 하지만 매개 변수는 스택에 넘겨지는 것이 아니라 EBX, ECX, EDX, ESI, EDI, EBP 레지스터에 넘겨진다.

open:

mov eax, 5

mov ebx, path

mov ecx, flags

mov edx, mode

int 80h

이 관례는 유닉스의 관례에 비해 커다란 단점이 있다. 즉, 프로그래머는 커널의 기능을 이요할 때마다 레지스터들을 스택에 푸시하고 요청 작업이 끝나면 다시 팝(pop)해야 한다. 이러한 단점은 코드를 크고 느리게 만든다. 그럼에도 불구하고 FreeBSD는 프로그래머에게 선택권을 주고 있다.

만약 프로그래머가 마이크로소프트/리눅스 호출 관례를 선택한다면 시스템에게 이 호출 관례를 사용한다는 사실을 통보해 주어야 한다. 즉, 프로그램이 어셈블되고 링크된 후에 실행 파일에 다음과 같이 표시를 해 두어야 한다.

% brandelf –f Linux filename

2.3. Which Convention Should You Use?

만약 FreeBSD에 국한된 코드를 작성하고 있다면 유닉스 호출 관례에 따라야 한다. 이러한 호출 방식이 보다 빠르고, 레지스터에 전역 변수(global variable)를 저장할 수 있게 해주며, 실행 파일에 표시를 할 필요도 없다. 게다가 프로그램이 설치될 시스템에 리눅스 애뮬레이션 패키지를 설치해야 한다는 제약 조건도 제거할 수 있다.

대부분의 경우에는 리눅스에서도 돌아가는 이식성 있는 프로그램을 작성하면서도 FreeBSD 사용자에게 가능한 한 효율적으로 실행되는 프로그램을 작성하고 싶을 것이다. 우선 기본적인 내용을 좀 더 설명한 후에 이식성과 효율성을 동시에 만족시킬 수 있는 방법을 설명할 것이다.

Chapter 3 – Call Numbers

어떤 서비스를 원하는지 커널에게 알리기 위해 EAX 레지스터에 식별 번호를 저장한다. 물론 그 번호가 어떤 서비스를 지정하는 것인지 알아둘 필요가 있다.

3.1. The syscalls file

식별 번호는 syscalls 파일에 기록되어 있다. locate syscalls 명령을 내리면 시스템에 있는 다양한 형태의 syscalls 파일을 찾아 주는데, 이 파일들은 모두 syscalls.master 파일에서 자동 생성된 것이다.

기본적인 유닉스 호출 관례를 위해 정의된 마스터 파일(master file)은 /usr/src/sys/ kern/syscalls.master 에서 찾을 수 있다. 만약 리눅스 애뮬레이션 모드에서 구현된 마이크로소프트의 호출 관례를 사용하고 싶다면 /usr/src/sys/i386/linux/syscalls.master를 참조하기 바란다.

N.B.: FreeBSD와 Linux가 호출 관례만 달리 사용하는 것은 아니다는 사실에 주목해야 한다. 같은 함수에 다른 식별 번호를 할당한 경우도 있다.

syscalls.master에는 시스템 콜들이 어떻게 구성되어 있는지에 대한 설명이 있다.

 
0 STD NOHIDE { int nosys(void); } syscall nosys_args int
1 STD NOHIDE { void sys_exit(int rval); } exit sys_exit_args void
2 STD POSIX { int fork(void); }
3 STD POSIX { ssize_t read(int fd, void *buf, size_t nbyte); }
4 STD POSIX { ssize_t write(int fd, const void *buf, size_t nbyte); }
5 STD POSIX { int open(char *path, int flags, int mode); }
6 STD POSIX { int close(int fd); }

etc...

.

가장 왼쪽의 숫자가 EAX에 저장될 값이다.

그리고 가장 오른쪽에 있는 값이 어떤 매개 변수가 푸시되어야 하는지를 나타내는 값이다. 이 값들은 오른쪽에서 왼쪽의 순서로 푸시된다.

EXAMPLE 3.1: 가령, 파일을 열기 위해 mode를 먼저 푸시해야 하고 flags와 path가 저장된 주소를 푸시한다는 의미가 된다.

Chapter 4 – Return Values

만약 시스템 콜이 어떤 결과값을 리턴(return)하지 않는다면 유용하게 사용할 수 없는 경우도 많이 있을 것이다. 가령, 열린 파일(open file)의 파일 기술자(file descriptor), 버퍼에서 읽은 바이트 수, 시스템 시간 등이 유용하게 사용될 수 있는 리턴값의 예이다.

게다가 에러가 발생했을 때, 시스템이 사용자에게 에러를 통보해 줄 수단도 필요하다. 이러한 에러의 경우에는 파일이 없다든지, 시스템 자원이 고갈되었다든지, 유효하지 않은 매개 변수가 넘어 온 경우 등이 해당된다.

4.1. Man Pages

유닉스 시스템에서 사용되는 다양한 시스템 콜들에 대한 정보를 얻을 수 있는 전통적인 방법은 맨 페이지(man page)를 이용하는 것이다. FreeBSD는 맨 페이지의 2절에서 시스템 콜을 설명하고 있지만 가끔 3절에서 소개되는 시스템 콜도 있다.

가령, open(2)를 보면 다음과 같은 정보를 얻을 수 있다.

만약 성공하면 open() 함수는 양의 정수를 리턴하는데, 이것은 연 파일의 기술자다. 이 함수가 –1을 리턴하면 함수의 호출이 실패한 것이고 errno 변수에 에러의 종류가 기록된다.

유닉스와 FreeBSD를 처음 접하는 어셈블리 프로그래머라면 바로 errno는 어디에 있고 어떻게 그 값을 얻을 수 있는가라는 질문을 던질 것이다.

N.B.: 맨 페이지에 있는 정보들은 C 프로그램을 위한 것들이다. 어셈블리 프로그래머들은 이 이상의 부가적인 정보가 필요하다.

4.2. Where Are The Return Values?

불행하게도 리턴 값이 저장되는 장소는 시스템 콜의 종류에 따라 다르다. 대부분의 시스템 콜은 EAX에 리턴 값을 저장하지만 전부 여기에 저장하는 것은 아니다. 처음 사용하는 시스템 콜은 리턴된 후에 EAX 레지스터를 검사해 보는 것이 좋은 프로그래밍 습관이다. 만약 EAX에 리턴값이 없다면 다른 곳을 찾아봐야 할 것이다.

N.B.: 필자가 사용했던 모든 시스템 콜은 EAX에 리턴값을 저장했다. 단 한가지 예외가 있었는데, SYS_fork가 바로 그것이다. 이 시스템 콜은 EDX 레지스터에 리턴값을 저장했다. 물론 필자가 모든 시스템 콜을 사용해 본 것은 아니기 때문에 EAX 레지스터를 검사해 보는 과정을 생략해선 안된다.

TIP: 만약 특정 시스템 콜의 리턴값이 저장되는 위치를 도저히 알 수가 없다면 libc 라이브러리의 소스 코드를 분석해 보는 것이 좋을 것이다. 이 라이브러리에서 커널과 어떻게 인터페이스를 형성하는 지에 주목해 보라.

4.3. Where Is errno?

사실은 어디에도 errno는 없다. errno는 유닉스 커널이 아닌 C 언어의 한 부분이다. 커널 서비스에 바로 접근할 때 error 코드는 일반적인 리턴값이 저장되는 EAX에 기록된다.

이것은 대단히 흥미 있는 구조를 형성한다. 에러가 없다면 에러 코드도 당연히 없을 것이고 에러가 있다면 리턴값도 의미가 없을 것이다. 따라서 하나의 레지스터에 에러 코드와 리턴값을 각각의 경우에 저장하는 것이다.

4.4 Determining an Error Occurred

표준 FreeBSD의 호출 관례를 사용할 때, 시스템 콜이 성공하면 carry flag가 클리어(clear)되고 실패하면 설정된다.

리눅스 애뮬레이션 모드를 사용할 때는 EAX에 저장된 값이 양의 정수면 호출이 성공한 것이고 그 값은 리턴값이 된다. 에러가 발생했을 경우에는 EAX에 저장된 값이 음수일 것이다.

Chapter 5 – Creating Portable Code

이식성은 일반적으로 어셈블리 언어가 유리한 점은 아니다. 하지만 어셈블리 프로그램을 서로 다른 플랫폼(platform)을 위해 작성하는 경우-특히 nasm으로-가 있을 수 있다. 필자는 Windows와 FreeBSD 같이 다른 운영체제를 위한 어셈블리 언어 라이브러리를 작성해 왔다.

어느 정도 차이는 있겠지만 유사한 구조를 가진 두 플랫폼에서 실행되는 코드를 작성하고자 한다면 이 일이 결코 불가능한 것이 아니라는 사실에 주목해야 한다.

가령, FreeBSD는 유닉스이며 Linux는 유닉스와 유사한 구조를 가진 운영체제이다. 필자는 이 둘 사이의 차이점을 단지 세 가지 밖에 언급하지 않았다. 즉, 호출 관례와 함수 번호, 그리고 리턴값의 저장 위치가 그것인데, 이 외의 구조는 거의 동일하기 때문에 굳이 언급하지 않은 것이었음을 기억하기 바란다.

5.1. Dealing With Function Numbers

많은 경우에 함수 번호는 같다. 하지만 같지 않은 함수가 있더라도 그리 큰 문제는 아니다. 코드를 작성할 때, 번호를 사용하는 대신 실행될 시스템에 따라 달리 선언되는 상수(constant)를 사용하면 이 문제는 해결된다.

%ifdef LINUX
%define SYS_execve 11
%else
%define SYS_execve 59
%endif

5.2. Dealing With Conventions

호출 관례와 리턴값(errno 문제)의 문제는 매크로를 이용하면 어렵지 않게 해결할 수 있다.

%ifdef LINUX
 
%macro system 0
 call kernel
%endmacro
 
align 4
kernel:
 push ebx
 push ecx
 push edx
 push esi
 push edi
 push ebp
 
 mov ebx, [esp+32]
 mov ecx, [esp+36]
 mov edx, [esp+40]
 mov esi, [esp+44]
 mov ebp, [esp+48]
 int 80h
 
 pop ebp
 pop edi
 pop esi
 pop edx
 pop ecx
 pop ebx
 
 or eax, eax
 js .errno
 clc
 ret
 
.errno:
 neg eax
 stc
 ret
 
%else
 
%macro system 0
 int 80h
%endmacro
 
%endif

5.3. Dealing With Other Portability Issues

위에서 제시한 해결 방법으로 대부분의 경우에 FreeBSD와 Linux 사이의 이식성 있는 코드를 작성할 수 있지만 일부의 커널 서비스는 정말 심각할 만큼 다른 경우가 있다.

이런 경우, 특정 시스템 콜을 위한 핸들러(handler)를 플랫폼마다 각각 작성하고 조건부 어셈블리(conditional assembly)를 사용할 필요가 있다. 다행히도 대부분의 코드에서 커널 서비스를 호출하는 부분은 많지 않으므로 조건문이 그리 많이 나오지는 않을 것이다.

5.4 Using a Library

이식성 문제를 피하는 또 한가지 방법은 시스템 콜의 라이브러리를 작성하여 주요 코드에서 사용하는 것이다. 즉, FreeBSD를 위한 라이브러리를 작성하고 이와는 별도로 Linux를 위한 라이브러리를 작성하여 사용하는 방법을 말한다.

라이브러리를 작성할 때, 각 시스템 콜을 분리된 별도의 함수(만약 여러분이 전통적인 어셈블리 언어의 용어를 선호한다면 프로시져라 표현할 수 있다.)로 작성하라. 또한 매개 변수를 넘기는 C의 호출 관례를 사용하라. 그러나 여전히 호출 번호(call number)를 넘기기 위해 EAX는 사용해야 할 것이다. 이러한 경우에 명백히 다른 함수들에는 레이블(label)을 붙여 두면 FreeBSD 라이브러리는 매우 단순해 질 것이다.

 
sys.open:
sys.close:
[etc...]
 int 80h
 ret

Linux 라이브러리에는 보다 많은 다른 함수들이 필요하겠지만 매개 변수의 수가 같은 시스템 콜들을 묶어 단순화시킬 수 있다.

sys.exit:
sys.close:
[etc... one-parameter functions]
 push ebx
 mov ebx, [esp+12]
 int 80h
 pop ebx
 jmp sys.return
 
...
 
sys.return:
 or eax, eax
 js sys.err
 clc
 ret
 
sys.err:
 neg eax
 stc

ret

라이브러리를 이용하여 이식성을 높이는 방법은 프로그래머가 플랫폼 마다 다른 파일에 코드를 분리하여 작성해야 하므로 처음에는 불편하겠지만 많은 장점이 있다. 먼저, 라이브러리는 한번 작성해 두면 여러 프로그램에서 사용할 수 있다는 장점이 있다. 게다가 라이브러리를 다른 프로그래머를 위해 공개할 수도 있으며, 다른 사람이 작성한 라이브러리를 사용하여 개발 효율을 높일 수도 있다. 하지만 뭐라 해도 가장 큰 장점을 꼽으라면 역시 이식성이다. 플랫폼 마다 라이브러리를 작성해 놓으면 프로그램을 다른 운영체제로 포팅할 때, 프로그램은 그대로 두고 라이브러리만 다시 작성하면 된다는 장점이 있다.

만약 라이브러리를 사용하는 방식이 마음에 들지 않으면 별도의 어셈블리 언어 파일에 모든 시스템 콜을 저장해 놓고 작성한 프로그램을 그 파일과 링크 시키는 것이 그나마 괜찮은 방법이 될 것이다. 프로그램을 포팅할 때 반드시 거쳐야 하는 과정은 작성한 프로그램과 링크하여 다시 새로운 개체 파일(object file)을 생성해 내는 것이다.

5.5. Using an Include File

소프트웨어를 소스 코드 형태로 발표한다면 매크로들을 별도의 파일로 모아 놓고 주 코드에서 인클루드(include)시키는 방식을 택할 수 있다.

이러한 형태로 작성된 소프트웨어를 포팅할 때는 인클루드된 파일만 재작성 하여 포팅을 마무리 지을 수도 있다. 즉, 라이브러리나 외부 개체 파일도 필요치 않으며 프로그램 코드도 수정할 필요 없이 포팅을 마무리할 수 있다는 뜻이다.

N.B.: 이 방법이 바로 이 튜토리얼에서 사용할 포팅 방식이다. 필자는 사용할 인클루트 파일을 system.inc라 정하고 새로운 시스템 콜을 다룰 때마다 추가할 것이다.

그럼 표준 파일 기술자를 정의하면서 system.inc 파일의 내용을 작성해 나가도록 하겠다.

 
%define stdin 0
%define stdout 1
%define stderr 2

다음으로 각 시스템 콜의 심볼릭 이름(symbolic name)을 생성한다.

 
%define SYS_nosys 0
%define SYS_exit  1
%define SYS_fork  2
%define SYS_read 3
%define SYS_write 4
; [etc...]

그리고 코드 전체에서 사용되지 않는 프로시져 중 코드 길이가 짧고 긴 이름을 가진 것들을 추가시킨다. 이런 프로시져들은 코드에서 자주 사용되진 않을 것이다.

section .code
align 4
access.the.bsd.kernel:
 int 80h
 ret

그리고 시스템 콜 번호를 매개 변수로 갖는 매크로를 생성한다.

 
%macro system 1
 mov eax, %1
 call access.the.bsd.kernel
%endmacro

마지막으로 각 시스템 콜에 해당하는 매크로를 생성한다. 이 매크로는 매개 변수가 없다.

 
%macro sys.exit 0
 system SYS_exit
%endmacro
 
%macro sys.fork 0
 system SYS_fork
%endmacro
 
%macro sys.read 0
 system SYS_read
%endmacro
 
%macro sys.write 0
 system SYS_write
%endmacro
 
; [etc...]

필자는 더 많은 시스템 콜을 다루면서 이 파일에 여러 내용을 추가 시켜 나갈 것이다.

Chapter 6 – Our First Program

이제 첫 프로그램을 작성할 준비가 되었다. 첫 프로그램은 모든 프로그래밍 언어를 배울 때 거의 의무적으로 접하게 되는 hello, world 프로그램이다.

 
 1: %include 'system.inc'
  2:
  3: section .data
  4: hello db 'Hello, World!', 0Ah
  5: hbytes equ $-hello
  6:
  7: section .code
  8: global _start
  9: _start:
 10: push dword hbytes
 11: push dword hello
 12: push dword stdout
 13: sys.write
 14:
 15: push dword 0
 16: sys.exit

첫번째 라인에서는 system.inc 파일에서 정의된 매크로와 코드를 인클루드 하고 있다.

라인 3-5는 데이터 영역이다. 라인 3은 데이터 섹션/세그먼트로 시작하고 라인 4는 “Hello, World!”라는 문자열을 저장하고 있다. 라인 5는 라인 4에서 정의된 문자열의 길이를 값으로 하는 상수를 만든다.

라인 7-16은 코드를 포함하고 있다. FreeBSD가 모든 프로그램이 _start라는 레이블이 붙은 지점에서 시작되어야 하는 elf 파일 포맷을 사용한다는 사실에 주목하라.(보다 정확히 말하자만 링커가 _start를 시작 지점으로 생각한다.) 이 레이블은 전역 변수(global variable)이어야 한다.

라인 10-13에서는 시스템에게 hello 문자열의 hbytes 만큼 stdout으로 써 달라는 요청을 하고 있다.

라인 15-16에서는 시스템에게 0을 리턴값으로 갖고 프로그램을 종료 시켜 달라는 요청으 하고 있다. SYS_exit 시스템 콜은 결코 리턴되지 않기 때문에 코드는 여기에서 끝난다.

N.B.: 만약 독자가 MS DOS 어셈블리 언어를 익히고 유닉스 환경으로 이전해 온 것이라면 출력을 위해서 비디오 하드웨어에 직접 쓰는 코드를 작성했을 것이다. FreeBSD나 기타 다른 유닉스 환경에서는 이 문제에 대해 걱정할 필요가 없다. 출력에 관련된 작업을 처리해야 한다면 stdout이라는 파일에 기록하기만 하면 된다. stdout은 비디오 스크린이 될 수도 있고 텔넷 터미널(telnet terminal) 혹은 실제 파일 심지어 다른 프로그램의 입력일 수도 있다. 이것은 전적으로 시스템이 이해하는 방식에 따라 다른 것이다.

6.1. Assembling the Code

일단 에디터에 어셈블리 언어 코드를 타이핑하고 hello.asm이라는 이름으로 저장하자. 이 파일을 어셈블하려면 nasm이 필요하다.

6.1.1. Installing NASM

nasm이 없다면 다음과 같이 타이핑하여 nasm을 설치하자.

% su
Password:your root password
# cd /usr/ports/devel/nasm
# make install
# exit
%

만약 nasm의 소스 코드를 유지하고 싶지 않다면 make install 대신 make install clean을 타이핑해야 한다.

위의 두 방법 중 어떤 것을 택하든지 FreeBSD는 인터넷에서 nasm을 다운 받아 컴파일하고 시스템에 설치해 줄 것이다.

N.B: 만약 시스템이 FreeBSD가 아니라면 nasm의 홈페이지에 가서 직접 소스를 구해야 한다. 물론 여기에서 얻은 소스로도 FreeBSD 코드를 어셈블할 수 있다.

이제 여러분은 다음과 같이 어셈블, 링크를 수행하고 코드를 실행시킬 수 있다.

% nasm -f elf hello.asm
% ld -s -o hello hello.o
% ./hello
Hello, World!

%

Chapter 7 – Writing Unix Filters

유닉스 애플리케이션(application)의 일반적인 타입은 필터(filter) -stdin에서 데이터를 읽고 처리한 후, stdout으로 출력하는 프로그램 –의 형태를 가진다.

이 장에서는 간단한 필터를 개발하면서 stdin에서 데이터를 읽는 방법과 stdout으로 데이터를 쓰는 방법에 대해 알아볼 것이다. 이 필터는 입력 받은 데이터를 바이트 단위로 16진수로 변환하고 변환된 데이터를 출력한다.

%include 'system.inc'
 
section .data
hex db '0123456789ABCDEF'
buffer db 0, 0, ' '
 
section .code
global _start
_start:
 ; read a byte from stdin
 push dword 1
 push dword buffer
 push dword stdin
 sys.read
 add esp, byte 12
 or eax, eax
 je .done
 
 ; convert it to hex
 movzx eax, byte [buffer]
 mov edx, eax
 shr dl, 4
 mov dl, [hex+edx]
 mov [buffer], dl
 and al, 0Fh
 mov al, [hex+eax]
 mov [buffer+1], al
 
 ; print it
 push dword 3
 push dword buffer
 push dword stdout
 sys.write
 add esp, byte 12
 jmp short _start
 
.done:
 push dword 0
 sys.exit

데이터 섹션(data section)에서 hex라는 배열을 만들었다. 이 배열은 16진수 자리수를 오름 차순으로 저장하고 있다. 이 배열에 이어 바로 입력과 출력 모두에 사용될 버퍼가 선언된다. 이 버퍼의 첫 두 바이트는 0으로 초기화되어 있다. 이 버퍼가 두 개의 16진수 자리수를 쓸 장소이다.(버퍼의 첫번째 바이트는 입력을 위한 장소로도 사용된다.) 그리고 세 번째 바이트는 공란(space)이다.

이 코드 섹션은 네 부분으로 구성된다. 한 바이트를 읽고 이것을 16진수로 변환시킨 후, 결과를 쓰고 프로그램을 종료 시킨다.

바이트 단위로 읽기 위해 시스템에게 stdin으로 부터 한 바이트를 읽어 달라는 요청을 하고 이것을 buffer의 첫번째 바이트에 저장한다. 시스템은 EAX에 읽은 바이트 수를 리턴한다. 들어온 데이터가 있으면 1이 될 것이고 없으면 0이 될 것이다. 따라서 EAX의 값을 검사해야 한다. 만약 EAX의 값이 0이면 .done으로 분기하고 0이 아니면 다음 명령어를 계속 실행한다.

N.B.: 이 예에서는 코드를 단순화시키기 위해 에러 상황을 무시하고 있다.

16진수 변환은 buffer에서 바이트를 읽어 들여 변환을 수행하고 EAX 레지스터에 변환 값을 저장한다. (실제로는 AL이다.) 이후 상위 4비트를 하위 4비트와 분리시켜 변환해야 할 필요가 있기 때문에 바이트를 EDX로 복사한다. 그리고 버퍼의 첫번째 두 바이트에 분리한 4비트의 변환 값을 각각 저장한다.

다음으로 시스템에 버퍼의 3 바이트- 두 16진수 자리수와 공란- 를 stdout에 써 달라는 요청을 한다. 그 후 프로그램의 시작 부로 분기하여 다음 바이트를 처리한다.

처리할 입력이 더 없으면 시스템에게 0을 리턴하면서 프로그램을 종료해 달라는 요청을 하는데, 이것은 프로그램이 성공적으로 종료되었음을 뜻하는 전통적인 값이다.

이제 이 소스 파일을 hex.asm이라는 이름으로 저장한 후 다음과 같이 타이핑한다.(^D의 의미는 Ctrl 키를 누른 상태에서 D를 누르라는 뜻이다.)

% nasm -f elf hex.asm
% ld -s -o hex hex.o
% ./hex
Hello, World!
48 65 6C 6C 6F 2C 20 57 6F 72 6C 64 21 0A Here I come!
48 65 72 65 20 49 20 63 6F 6D 65 21 0A ^D %

N.B.: 만약 MS DOS 환경에서 유닉스 환경으로 이전해 온 프로그래머라면 각 라인이 0D 0A가 아닌 0A로 끝난다는 사실에 의아해 할 것이다. 이것은 유닉스가 cr/lf의 관례를 따르지 않고 0A 값을 갖는 새 라인(new line) 문자 만으로 라인의 끝을 표시하기 때문이다.

예제 코드에서 어떤 점을 개선할 수 있을까? 많은 부분이 있겠지만 출력 형식이 특히 미비하다. 즉, 텍스트의 한 라인을 변환하여 화면에 출력하는데, 새로운 텍스트의 변환문이 이전의 출력과 공란 하나만으로 구분되어 출력되는 것은 썩 유쾌하지 못한 일이다. 이러한 점은 다음 코드와 같이 다음 라인을 출력하기 전에 다음 라인으로 출력 위치를 재조정하도록 코드를 수정할 수 있을 것이다.

%include 'system.inc'
 
section .data
hex db '0123456789ABCDEF'
buffer db 0, 0, ' '
 
section .code
global _start
_start:
 mov cl, ' '
 
.loop:
 ; read a byte from stdin
 push dword 1
 push dword buffer
 push dword stdin
 sys.read
 add esp, byte 12
 or eax, eax
 je .done
 
 ; convert it to hex
 movzx eax, byte [buffer]
 mov [buffer+2], cl
 cmp al, 0Ah
 jne .hex
 mov [buffer+2], al
 
.hex:
 mov edx, eax
 shr dl, 4
 mov dl, [hex+edx]
 mov [buffer], dl
 and al, 0Fh
 mov al, [hex+eax]
 mov [buffer+1], al
 
 ; print it
 push dword 3
 push dword buffer
 push dword stdout
 sys.write
 add esp, byte 12
 jmp short .loop
 
.done:
 push dword 0
 sys.exit

우리는 CL 레지스터에 공란을 저장해왔다. 마이크로소프트 윈도우와는 달리 유닉스의 시스템 콜은 결과 값을 리턴하기 위해 사용하는 레지스터를 제외하고는 어떤 레지스터의 값도 수정하지 않기 때문에 공란을 CL 레지스터에 저장하는 것이 문제될 건 없다.

이것은 프로그래머가 CL 레지스터의 값을 한번만 설정해 주면 된다는 것을 의미한다. 따라서 .loop라는 레이블을 추가하고 다음 바이트를 처리해야 할 때 _start로 분기하지 않고 .loop으로 분기한다. 또한 .hex 레이블을 추가하여 buffer의 세번째 바이트로 공란이나 새 라인 문자를 저장하는데 사용한다.

일단 hex.asm에 이러한 변화를 반영했으면 다음과 같이 타이핑하라.

% nasm -f elf hex.asm
% ld -s -o hex hex.o
% ./hex
Hello, World!
48 65 6C 6C 6F 2C 20 57 6F 72 6C 64 21 0A
Here I come!
48 65 72 65 20 49 20 63 6F 6D 65 21 0A
^D %

새 버젼은 좀 나아 보이지만 코드 자체가 비효율적인 면이 많다. 이런 이유로 필자는 한 바이트 당 두번 호출되는 시스템 콜을 만들고 있다.(한번은 읽고 한번은 출력한다.)

Chapter 8 – Buffered Input and Output

입력과 출력을 버퍼링하면 코드를 좀 더 효율적으로 구현할 수 있다. 이런 이유로 한번에 전체 바이트를 읽어올 입력 버퍼를 만든 후, 버퍼에서 한 바이트씩 가져와 처리하는 형식을 도입할 것이다. 또, 출력 버퍼를 만들어서 이 버퍼가 가득 찰 때에만 stdout에 출력 하도록 수정할 것이다.

프로그램은 더 이상의 입력이 없을 때 종료된다. 하지만 마지막에는 여전히 커널에게 출력 버퍼를 stdout에 써달라는 요청을 해야 한다. 물론 버퍼가 비어 있다면 이러한 요청을 할 필요가 없을 것이다. 프로그램의 종료 시 출력 버퍼의 내용을 정리해야 한다는 사실을 잊고 출력이 완전하지 않다고 투덜대지 않기 바란다.

%include 'system.inc'
 
%define BUFSIZE 2048
 
section .data
hex db '0123456789ABCDEF'
 
section .bss
ibuffer resb BUFSIZE
obuffer resb BUFSIZE
 
section .code
global _start
_start:
 sub eax, eax
 sub ebx, ebx
 sub ecx, ecx
 mov edi, obuffer
 
.loop:
 ; read a byte from stdin
 call getchar
 
 ; convert it to hex
 mov dl, al
 shr al, 4
 mov al, [hex+eax]
 call putchar
 
 mov al, dl
 and al, 0Fh
 mov al, [hex+eax]
 call putchar
 
 mov al, ' '
 cmp dl, 0Ah
 jne .put
 mov al, dl
 
.put:
 call putchar
 jmp short .loop
 
align 4
getchar:
 or ebx, ebx
 jne .fetch
 
 call read
 
.fetch:
 lodsb
 dec ebx
 ret
 
read:
 push dword BUFSIZE
 mov esi, ibuffer
 push esi
 push dword stdin
 sys.read
 add esp, byte 12
 mov ebx, eax
 or eax, eax
 je .done
 sub eax, eax
 ret
 
align 4
.done:
 call write  ; flush output buffer
 push dword 0
 sys.exit
 
align 4
putchar:
 stosb
 inc ecx
 cmp ecx, BUFSIZE
 je write
 ret
 
align 4
write:
 sub edi, ecx ; start of buffer
 push ecx
 push edi
 push dword stdout
 sys.write
 add esp, byte 12
 sub eax, eax
 sub ecx, ecx ; buffer is empty now
 ret

이제 .bss라고 명명되어 있는 소스 코드의 세번째 섹션을 살펴보자. 이 섹션은 실행 파일에 포함되어 있지 않기 때문에 초기화할 수가 없다. 필자는 db 대신에 resb를 사용하는데, 이것은 단지 요청된 크기만큼 초기화되지 않은 메모리를 예약하는 역할을 한다.

시스템이 레지스터를 수정하지 않는다는 사실은 큰 장점이 될 수 있다. 레지스터의 값이 변하지 않기 때문에 여러 용도로 레지스터를 사용하는데, 만약 레지스터 값이 변한다면 .data 섹션에 전역 변수를 선언하고 저장해 두어야 할 것이다. 이 점이 바로 레지스터로 매개 변수를 전달하는 마이크로소프트의 호출 관례에 비해 스택에 시스템 콜의 매개 변수를 전달하는 유닉스 호출 관례가 우수하다고 말하는 이유이다. 이러한 이유로 필자는 여러 용도로 레지스터를 활용하여 프로그램을 작성한다.

EDI와 ESI 레지스터는 다음에 읽을 바이트나 쓸 바이트를 가리키는 포인터로 사용된다. 또한 EBX와 ECX는 두 버퍼에 남아 있는 바이트의 수를 세는 데 사용되기 때문에 프로그램이 출력을 해야 할 상황인지 입력을 받아야 할 상황인지를 판단할 수 있다.

이제 이 프로그램이 어떻게 동작하는 지 살펴보도록 하자.

% nasm -f elf hex.asm
% ld -s -o hex hex.o
% ./hex
Hello, World!
Here I come!
48 65 6C 6C 6F 2C 20 57 6F 72 6C 64 21 0A
48 65 72 65 20 49 20 63 6F 6D 65 21 0A
^D %

예상치 못했던 문제가 하나 있다. 이 프로그램은 ^D를 누를 때까지 출력 버퍼의 내용을 모두 출력하지 않는다. 이러한 문제는 새 라인 문자를 0A로 변환할 때마다 출력 버퍼의 내용을 출력하도록 코드를 수정하면 간단히 해결될 수 있다. 필자는 수정한 세 라인에 > 표시를 해 두었다.(hex.asm의 코드에 > 까지 복사하진 말기 바란다.)

%include 'system.inc'
 
%define BUFSIZE 2048
 
section .data
hex db '0123456789ABCDEF'
 
section .bss
ibuffer resb BUFSIZE
obuffer resb BUFSIZE
 
section .code
global _start
_start:
 sub eax, eax
 sub ebx, ebx
 sub ecx, ecx
 mov edi, obuffer
 
.loop:
 ; read a byte from stdin
 call getchar
 
 ; convert it to hex
 mov dl, al
 shr al, 4
 mov al, [hex+eax]
 call putchar
 
 mov al, dl
 and al, 0Fh
 mov al, [hex+eax]
 call putchar
 
 mov al, ' '
 cmp dl, 0Ah
 jne .put
 mov al, dl
 
.put:
 call putchar
> cmp al, 0Ah
> jne .loop
> call write
 jmp short .loop
 
align 4
getchar:
 or ebx, ebx
 jne .fetch
 
 call read
 
.fetch:
 lodsb
 dec ebx
 ret
 
read:
 push dword BUFSIZE
 mov esi, ibuffer
 push esi
 push dword stdin
 sys.read
 add esp, byte 12
 mov ebx, eax
 or eax, eax
 je .done
 sub eax, eax
 ret
 
align 4
.done:
 call write  ; flush output buffer
 push dword 0
 sys.exit
 
align 4
putchar:
 stosb
 inc ecx
 cmp ecx, BUFSIZE
 je write
 ret
 
align 4
write:
 sub edi, ecx ; start of buffer
 push ecx
 push edi
 push dword stdout
 sys.write
 add esp, byte 12
 sub eax, eax
 sub ecx, ecx ; buffer is empty now
 ret

이제 결과를 확인해 보자.

% nasm -f elf hex.asm
% ld -s -o hex hex.o
% ./hex
Hello, World!
48 65 6C 6C 6F 2C 20 57 6F 72 6C 64 21 0A
Here I come!
48 65 72 65 20 49 20 63 6F 6D 65 21 0A
^D %

644 바이트의 실행 파일 치곤 나쁘지 않은 결과가 아닌가?

8.1. How To Unread a Character

WARNING: 이 절에서 다룰 내용은 다소 어려운 주제에 속한다. 하지만 컴파일러 이론에 익숙한 프로그래머에게는 재미있는 주제가 될 수 있을 것이다. 만약 이 절을 건너 뛰고 싶다면 다음 장으로 건너 뛴 후, 나중에 읽어도 상관없다.

우리의 예제 프로그램에는 필요 없는 특징이지만 보다 복잡한 필터들은 문자를 읽기 전에 미리 다음 문자를 읽어서 특정 조건을 만족하는지 확인하는 과정이 필요하다.(이를 look-ahead라 한다.) 만약 다음 문자가 특정한 문자라면(즉, 공란이나 특수 문자가 아니고) 이 값은 현재 처리하고 있는 토큰(token)의 일부이고 그 이외의 문자라면 현재 토근이 아닐 것이다.

텍스트 문자열로 구성된 입력 스트림(input stream)을 파싱(parsing)해야 하는 상황을 생각해 보자.(컴파일러를 구현한다면 필수적인 작업이다.) 만약 한 문자나 숫자가 다른 문자에 연이어 나온다면 이것은 처리하고 있는 토큰의 일부이다. 또, 다음 문자가 공란이나 특수 문자라면 현재 토큰의 일부가 아니라는 판단이 가능하다.

이것은 재미있는 문제를 발생시킨다. 입력 스트림의 뒤 부분에 있는 다음 문자를 미리 읽어 판단한 후, 어떻게 다시 입력 스트림으로 되돌릴 수 있으며, 추후 이 문자를 어떻게 다시 읽을 수 있겠는가?

한 가지 가능한 방법은 다음 문자를 하나의 문자 변수에 저장하고 플래그를 설정하는 것이다. 우리는 getchar가 플래그를 검사하여 설정되어 있을 경우에는 입력 버퍼 대신 문자 변수에서 바이트를 읽어 오고 플래그를 클리어 하도록 수정 할 수 있다. 물론 처리 속도는 저하될 것이다.

C 언어에는 ungetc() 함수가 있는데, 이 함수가 바로 위와 같은 목적으로 사용된다. 우리 코드에서 이러한 기능을 구현할 수 있는 가장 빠른 방법은 무엇일까? 필자는 독자들에게 앞으로 돌아가서 getchar 프로시져의 구현을 살펴보고 한번 고민해 보기를 권하고 싶다. 그리고 나서 생각이 정리되면 필자의 해결 방법을 보아 주기 바란다.

미리 읽은 문자를 다시 스트림으로 돌려 놓는 일은 처리할 버퍼의 시작으로 어떤 문자부터 할 것이냐의 문제로 귀결된다.

먼저 EBX의 값을 검사하여 버퍼가 비어 있는지 여부를 검사하는데, EBX의 값이 0이면 read 프로시져를 호출한다.

프로그램이 처리할 문자가 있다면 lodsb를 사용하고 EBX의 값을 감소시킨다. lodsb 명령어는 다음의 코드와 동일한 일을 수행한다.

 
 mov al, [esi]
 inc esi

읽어온 바이트는 read 프로시져가 호출되기 전에는 여전히 버퍼에 남아 있다. 프로그램은 read가 언제 호출될지 정확히 알 수 없지만 getchar가 다시 호출되기 전에는 read도 호출되지 않는다는 것 정도는 알고 있다. 따라서 마지막으로 읽었던 문자를 다시 입력 스트림으로 되돌리기 위해서 해야 하는 일은 ESI 레지스터의 값을 감소시키고 EBX 레지스터의 값을 증가시키는 것이다.

ungetc:
 dec esi
 inc ebx
 ret

하지만 주의해야 한다. 만약 미리 보아야 할 문자가 한번에 기껏 한 문자라면 별 문제 없겠지만 한 개 이상의 문자를 미리 보아야 한다면 ungetc 프로시져가 여러 번 반복하여 호출된다. 대부분의 경우 이러한 경우에도 문제가 없겠지만 모든 경우에 정상 동작하는 것은 아니다. 왜 그럴까?

getchar는 read를 굳이 호출하지 않아도 동작하기 때문에 미리 읽었던 바이트들은 여전히 버퍼에 남아 있으며 당연히 ungetc 프로시져도 정상적으로 동작할 것이다. 하지만 getchar가 read를 호출하면 버퍼의 내용이 변한다.

프로그램은 항상 getchar로 읽은 마지막 바이트에 대해 정상적으로 동작한 ungetc에 의존할 수 있지만 전에 읽었던 값들에 의존할 순 없다.

만약 프로그램이 한 바이트 이상을 미리 읽어 들인다면 프로그래머는 어쨌든 두 가지의 선택을 해야 한다.

가능하다면 프로그램을 한 바이트만을 미리 읽어 들이도록 수정한다. 이것이 가장 간단한 방법이다.

수정이 불가능하다면 무엇보다 먼저 프로그램이 한번에 입력 스트림으로 되돌려야 하는 문자의 최대 수를 결정해야 한다. 최대 수는 16의 배수로 만들어 놓는 것이 좋은데, 16의 배수가 메모리에의 워드 단위이기 때문에 정렬이 효율적이다. 그리고 코드의 .bss 섹션을 수정하고 spare라는 버퍼를 입력 버퍼 바로 앞에 선언한다.

section .bss
 resb 16 ; or whatever the value you came up with
ibuffer resb BUFSIZE

obuffer resb BUFSIZE

또 프로그램을 미리 읽은 바이트 값을 AL 레지스터에 저장하는 것으로 수정한다.

ungetc:
 dec esi
 inc ebx
 mov [esi], al
 ret

Chapter 9 – Command Line Arguments

커맨드 라인(command line)에서 입력과 출력 파일의 이름을 넘겨 받을 수 있다면 hex 프로그램은 더욱 유용하게 사용될 수 있을 것이다.

유닉스 시스템은 프로그램을 시작 시키기 전에 스택에 몇 개의 데이터를 푸시해 놓고 프로그램의 _start이 있는 부분으로 분기한다. 필자는 분명 분기(jump)한다고 했는데, 분기와 호출(call)은 다르다는 사실에 유의해야 한다. 이것은 [esp+offset]을 읽거나 데이트를 스택에 팝 연산을 적용하여 데이터에 접근할 수 있다는 사실을 의미한다.

스택의 상단(top)에는 커맨드 라인 인자의 수가 저장되어 있다. 이것은 보통 argc라고 불렸다.(argument count)

커맨드 라인 인자들은 바로 연이어 argc 만큼 저장되는데, 이 인자들은 보통 argv (argument values)라는 이름으로 참조된다. 즉, argv[0], argv[1], ..., argv[argc-1] 같은 형식으로 얻을 수 있다. 이 값들은 실제 인자가 아니라 인자를 가리키는 포인터이다. (실 인자의 메모리 주소이다.) 그리고 인자들은 NULL을 종료 문자로 하는 문자열이다.

argv 리스트의 끝은 NULL 포인터가 설정되어 있다. 즉 포인터 값으로 0이 설정되어 있다는 뜻이다. 커맨드 라인 인자에 대해서는 할 말이 많지만 우리의 목적에는 이 정도의 내용으로 충분하다.

N.B.: MS DOS 프로그래밍 환경에 익숙한 사람들에게 유닉스 환경과의 가장 큰 차이점은 각 인자들이 분리된 문자열로 구성되어 있다는 것이고, 두 번째 차이점은 받을 수 있는 인자의 수에는 어떤 한계가 없다는 것이다.

이 정도 알았다면 hex.asm의 다음 버젼을 제작할 준비는 끝난 것이다. 하지만 다음 버젼 제작에 들어가기에 앞서 system.inc 파일에 몇 개의 라인을 추가해야 한다.

먼저 시스템 콜 번호 리스트에 두 개의 새로운 엔트리를 추가한다.

%define SYS_open 5
%define SYS_close 6

그리고 파일의 끝에 두개의 매크로를 추가한다.

%macro sys.open 0
 system SYS_open
%endmacro
 
%macro sys.close 0
 system SYS_close
%endmacro

다음이 수정된 버젼의 hex.asm 코드이다.

%include 'system.inc'
 
%define BUFSIZE 2048
 
section .data
fd.in dd stdin
fd.out dd stdout
hex db '0123456789ABCDEF'
 
section .bss
ibuffer resb BUFSIZE
obuffer resb BUFSIZE
 
section .code
align 4
err:
 push dword 1  ; return failure
 sys.exit
 
align 4
global _start
_start:
 add esp, byte 8 ; discard argc and argv[0]
 
 pop ecx
 jecxz .init  ; no more arguments
 
 ; ECX contains the path to input file
 push dword 0  ; O_RDONLY
 push ecx
 sys.open
 jc err  ; open failed
 
 add esp, byte 8
 mov [fd.in], eax
 
 pop ecx
 jecxz .init  ; no more arguments
 
 ; ECX contains the path to output file
 push dword 420 ; file mode (644 octal)
 push dword 0200h | 0400h | 01h
 ; O_CREAT | O_TRUNC | O_WRONLY
 push ecx
 sys.open
 jc err
 
 add esp, byte 12
 mov [fd.out], eax
 
.init:
 sub eax, eax
 sub ebx, ebx
 sub ecx, ecx
 mov edi, obuffer
 
.loop:
 ; read a byte from input file or stdin
 call getchar
 
 ; convert it to hex
 mov dl, al
 shr al, 4
 mov al, [hex+eax]
 call putchar
 
 mov al, dl
 and al, 0Fh
 mov al, [hex+eax]
 call putchar
 
 mov al, ' '
 cmp dl, 0Ah
 jne .put
 mov al, dl
 
.put:
 call putchar
 cmp al, dl
 jne .loop
 call write
 jmp short .loop
 
align 4
getchar:
 or ebx, ebx
 jne .fetch
 
 call read
 
.fetch:
 lodsb
 dec ebx
 ret
 
read:
 push dword BUFSIZE
 mov esi, ibuffer
 push esi
 push dword [fd.in]
 sys.read
 add esp, byte 12
 mov ebx, eax
 or eax, eax
 je .done
 sub eax, eax
 ret
 
align 4
.done:
 call write  ; flush output buffer
 
 ; close files
 push dword [fd.in]
 sys.close
 
 push dword [fd.out]
 sys.close
 
 ; return success
 push dword 0
 sys.exit
 
align 4
putchar:
 stosb
 inc ecx
 cmp ecx, BUFSIZE
 je write
 ret
 
align 4
write:
 sub edi, ecx ; start of buffer
 push ecx
 push edi
 push dword [fd.out]
 sys.write
 add esp, byte 12
 sub eax, eax
 sub ecx, ecx ; buffer is empty now
 ret

이번 버젼에서는 fd.in과 fd.out이라는 두 개의 변수를 .data 섹션에 추가했는데, 이 변수들은 입력과 출력 파일 기술자를 저장하는데 사용된다.

.code 섹션에서는 stdin과 stdout을 [fd.in]과 [fd.out]과 같은 참조로 대체 시켰다.

이번 버젼의 .code 섹션은 간단한 에러 핸들러로 시작되는데, 이 핸들러는 1을 리턴하며 프로그램을 종료 시키는 단순한 일을 한다. 에러 핸들러는 _start 앞에 있기 때문에 에러가 발생한 곳에서 가깝게 위치한다.

당연한 말이지만 프로그램은 여전히 _start에서 시작한다. 프로그램이 시작되면 먼저 스택에서 argc와 argv[0]을 제거한다. 이 값들은 우리 프로그램에서는 사용되지 않는다.

그 후 argv[1]을 팝하여 ECX 레지스터에 저장하는데, 이것은 jecxz로 NULL 포인터를 다룰 수 있는 것처럼 ECX 레지스터가 포인터 연산에 특히 적합하기 때문이다. 만약 argv[1]이 NULL이 아니라면 프로그램은 첫번째 인자를 이름으로 갖는 파일을 연다. 그리고 argv[1]이 NULL이라면 이전 버젼의 프로그램도 동일하게 동작한다.(stdin에서 읽어서 stdout으로 출력하는 버젼) 입력 파일을 열지 못하게 되면 (가령 그런 이름의 파일이 없는 이유로) 에러 핸들러로 분기하고 프로그램을 종료하게 된다.

이와는 달리 첫번째 인자 검사에서 에러가 발생하지 않으면 두 번째 인자를 검사한다. 역시 두 번째 인자가 있다면 파일을 연다. 그리고 두 번째 인자가 없다면 stdout으로 결과를 출력한다. 마찬가지로 출력 파일을 열지 못하는 상황이 발생하면 에러 핸들러로 분기한다.(파일이 있다 해도 파일의 쓰기 허가권-permisiion-가 없다면 파일을 열 수 없을 것이다.)

프로그램이 종료될 때, 열었던 파일들을 닫는다는 사실을 제외하면 코드의 나머지는 이전 버젼과 동일하다. 이미 언급한 바와 같이 [fd.in]과 [fd.out]을 사용했다는 사실에 주목하라.

이 프로그램의 실행 파일은 이제 768 바이트의 크기를 갖는다.

여전히 개선할 점이 있는가? 물론이다. 모든 프로그램은 어떤 방향으로든 개선될 수 있다. 이런 의미에서 다음과 같이 개선할 수 있는 점들을 모아 보았다.

l 에러 핸들러가 stderr로 메시지를 출력할 수 있도록 수정한다.

l read와 write 기능에 대한 에러 핸들러를 추가한다.

l 입력 파일을 열 때 stdin을 닫고, 출력 파일을 열 때 stdout을 닫도록 수정한다.

l -i 와 –o같은 커맨드 라인 스위치(command line switch)를 추가하여 입력과 출력 파일을 어떤 순서로 나열하거나 stdin으로 읽고 파일에 쓰는 등의 부가적인 기능을 제공할 수 있도록 수정한다.

l 커맨드 라인 인자가 부적절하면 사용 방법을 출력해 주도록 수정한다.

필자는 이러한 추가 사항을 독자에게 과제로 남겨둘 생각이다. 독자들은 이미 위와 같은 기능을 구현하는데 필요한 모든 지식을 갖추고 있다.

Chapter 10 – Unix Enviroment

유닉스의 개념 중 중요한 것으로 환경(enviroment)를 들 수 있는데, 이는 여러 환경 변수(enviroment variable)로 정의된다. 환경 변수 중 일부는 시스템이 설정하며, 또 일부는 사용자, 쉘(shell), 다른 프로그램을 로드시키는 프로그램이 설정한다.

10.1. How to Find Enviroment Variables

필자는 프로그램이 실행될 때, 스택에는 argc, argv, 그리고 그 밖의 다른 값들이 저장된다는 사실을 설명한 바 있다. 그 밖의 다른 값이라는 것이 바로 환경(enviroment), 보다 정확히 말하자면 NULL로 끝나는 환경 변수의 배열을 가리키는 포인터이다. 이 값은 보통 env라는 변수로 참조된다.

env의 구조는 NULL로 끝나는 메모리 주소의 리스트인 argv와 동일하지만 envc가 없다는 사실이 다르다. 하지만 NULL 값을 검색하면 원소의 수를 알아낼 수 있다.

이 변수는 보통 name=value 형태로 저장되지만 어떤 환경 변수들은 =이 없이 저장되기도 한다. 따라서 이 가능성을 고려해야 할 필요가 있다.

10.2. webvar

이 절에서 필자는 유닉스의 env 명령어가 동작하는 것처럼 환경 변수들을 출력해 줄 수 있는 코드를 작성할 것이다. 하지만 이 프로그램을 간단한 어셈블리 CGI 유틸리티로 작성해 보는 것도 재미있는 작업이리라 생각한다.

10.2.1. CGI: A Quick Overview

필자는 홈페이지에 자세한 CGI 튜토리얼을 올려 놓았지만 여기에서 CGI를 간단히 소개하겠다.

l 웹 서버(web server)는 환경 변수를 설정함으로써 CGI 프로그램과 통신한다.

l CGI 프로그램은 출력 결과를 stdout으로 보낸다. 그리고 웹 서버는 stdout에서 출력 결과를 읽어 들인다.

l HTTP 헤더 두 개의공백 라인 다음에 시작되어야 한다.

l 그리고 HTML 코드를 출력한다.

N.B.: 특정 환경 변수들은 표준 이름을 사용하지만 일부 변수들은 웹 서버에 따라 다른 이름이 사용된다. 따라서 webvars 프로그램은 이러한 점을 진단하는 유용한 도구가 될 것이다.

코드는 다음과 같다. 필자는 코드에 바로 주석과 설명을 붙여 놓았다.

;;;;;;; webvars.asm ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;
; Copyright (c) 2000 G. Adam Stanislav
; All rights reserved.
;
; Redistribution and use in source and binary forms, with or without
; modification, are permitted provided that the following conditions
; are met:
; 1. Redistributions of source code must retain the above copyright
; notice, this list of conditions and the following disclaimer.
; 2. Redistributions in binary form must reproduce the above copyright
; notice, this list of conditions and the following disclaimer in the
; documentation and/or other materials provided with the distribution.
;
; THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
; ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
; IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
; ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
; FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
; DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
; OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
; HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
; LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
; OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
; SUCH DAMAGE.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;
; Version 1.0
;
; Started:  8-Dec-2000
; Updated:  8-Dec-2000
;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
%include 'system.inc'
 
section .data
http db 'Content-type: text/html', 0Ah, 0Ah
 db '<?xml version="1.0" encoding="UTF-8"?>', 0Ah
 db '<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML Strict//EN" '
 db '"DTD/xhtml1-strict.dtd">', 0Ah
 db '<html xmlns="http://www.w3.org/1999/xhtml" '
 db 'xml.lang="en" lang="en">', 0Ah
 db '<head>', 0Ah
 db '<title>Web Environment</title>', 0Ah
 db '<meta name="author" content="G. Adam Stanislav" />', 0Ah
 db '</head>', 0Ah, 0Ah
 db '<body bgcolor="#ffffff" text="#000000" link="#0000ff" '
 db 'vlink="#840084" alink="#0000ff">', 0Ah
 db '<div class="webvars">', 0Ah
 db '<h1>Web Environment</h1>', 0Ah
 db '<p>The following <b>environment variables</b> are defined '
 db 'on this web server:</p>', 0Ah, 0Ah
 db '<table align="center" width="80" border="0" cellpadding="10" '
 db 'cellspacing="0" class="webvars">', 0Ah
httplen equ $-http
left db '<tr>', 0Ah
 db '<td class="name"><tt>'
leftlen equ $-left
middle db '</tt></td>', 0Ah
 db '<td class="value"><tt><b>'
midlen equ $-middle
undef db '<i>(undefined)</i>'
undeflen equ $-undef
right db '</b></tt></td>', 0Ah
 db '</tr>', 0Ah
rightlen equ $-right
wrap db '</table>', 0Ah
 db '</div>', 0Ah
 db '</body>', 0Ah
 db '</html>', 0Ah, 0Ah
wraplen equ $-wrap
 
section .code
global _start
_start:
 ; First, send out all the http and xhtml stuff that is
 ; needed before we start showing the environment
 push dword httplen
 push dword http
 push dword stdout
 sys.write
 
 ; Now find how far on the stack the environment pointers
 ; are. We have 12 bytes we have pushed before "argc"
 mov eax, [esp+12]
 
 ; We need to remove the following from the stack:
 ;
 ; The 12 bytes we pushed for sys.write
 ; The 4 bytes of argc
 ; The EAX*4 bytes of argv
 ; The 4 bytes of the NULL after argv
 ;
 ; Total:
 ; 20 + eax * 4
 ;
 ; Because stack grows down, we need to ADD that many bytes
 ; to ESP.
 lea esp, [esp+20+eax*4]
 cld  ; This should already be the case, but let's be sure.
 
 ; Loop through the environment, printing it out
.loop:
 pop edi
 or edi, edi ; Done yet?
 je near .wrap
 
 ; Print the left part of HTML
 push dword leftlen
 push dword left
 push dword stdout
 sys.write
 
 ; It may be tempting to search for the '=' in the env string next.
 ; But it is possible there is no '=', so we search for the
 ; terminating NUL first.
 mov esi, edi ; Save start of string
 sub ecx, ecx
 not ecx  ; ECX = FFFFFFFF
 sub eax, eax
repne scasb
 not ecx  ; ECX = string length + 1
 mov ebx, ecx ; Save it in EBX
 
 ; Now is the time to find '='
 mov edi, esi ; Start of string
 mov al, '='
repne scasb
 not ecx
 add ecx, ebx ; Length of name
 
 push ecx
 push esi
 push dword stdout
 sys.write
 
 ; Print the middle part of HTML table code
 push dword midlen
 push dword middle
 push dword stdout
 sys.write
 
 ; Find the length of the value
 not ecx
 lea ebx, [ebx+ecx-1]
 
 ; Print "undefined" if 0
 or ebx, ebx
 jne .value
 
 mov ebx, undeflen
 mov edi, undef
 
.value:
 push ebx
 push edi
 push dword stdout
 sys.write
 
 ; Print the right part of the table row
 push dword rightlen
 push dword right
 push dword stdout
 sys.write
 
 ; Get rid of the 60 bytes we have pushed
 add esp, byte 60
 
 ; Get the next variable
 jmp .loop
 
.wrap:
 ; Print the rest of HTML
 push dword wraplen
 push dword wrap
 push dword stdout
 sys.write
 
 ; Return success
 push dword 0
 sys.exit

이 코드는 1396 바이트의 실행 코드를 만들어 낸다. 프로그램이 만들어 내는 대부분의 데이터는 출력 해야 하는 HTML이다.

어셈블과 링크는 다른 프로그램과 다르지 않다.

% nasm -f elf webvars.asm
% ld -s -o webvars webvars.o

이 프로그램을 사용하려면 webvars를 웹 서버에 올려야 한다. 따라서 웹 서버가 어떻게 설정 되었느야에 따라 webvars 실행 파일을 cgi-bin이나 .cgi 디렉토리에 저장해 두어야 할 것이다.

그리고 브라우져(browser)로 출력 결과를 확인하라. 필자의 웹 서버에서의 출력 결과를 보고 싶다면 웹 브라우져로 http://www.int80h.org/webvars/에 접속해 보기 바란다. 모든 검색 엔진에 출력 결과를 나오도록 하고 싶진 않기 때문에 의도적으로 정규 링크(regular link)를 여기에 싣진 않았다.

Chapter 11 – Working with Files

우리는 이미 파일을 다루는 대한 기본적인 지식은 얻었다. 즉, 파일을 열고, 닫고, 버퍼를 이용해 읽고, 쓰는 방법을 알고 있다. 하지만 유닉스는 파일에 대해 더 많은 기능을 제공한다. 우리는 이 섹션에서 그 기능 중 일부를 살펴 보고 이를 이용하여 파일 변환 유틸리티(file convention utility)를 작성해 볼 것이다.

작성해야 할 마지막 소프트웨어가 어떤 기능을 충족시켜야 하는 지를 시작할 때부터 알고 있다면 프로그래밍은 훨씬 쉬워 진다.

필자가 유닉스 환경에서 작성했던 첫번째 프로그램 중 하나가 tuc (text-to-Unix file converter)이었다. 이 프로그램은 다른 운영 체제에서 작성된 텍스트 파일을 유닉스 텍스트 파일로 변환해 준다. 즉, 라인의 끝을 구분하는 특수 문자를 서로 다르게 사용하는 운영 체제들 사이에 텍스트 파일을 공유할 수 있도록 해 주는 프로그램이다.(유닉스에서 작성된 텍스트 파일을 MS DOS 용으로 변환할 수도 있다.) 이 프로그램은 원본과 다른 파일에 결과를 저장한다.

필자는 tuc을 여러 모로 사용해 왔지만 항상 다른 운영체제에서 유닉스로의 변환만을 수행해 왔다. 이 때 결과를 다른 파일로 쓰기 보다는 변환한 파일에 덮어 쓰는 것이 낫겠다는 생각을 항상 해왔다. 대부분의 경우에 필자는 다음과 같이 이 프로그램을 이용해 왔다.

% tuc myfile tempfile

% mv tempfile myfile

이 프로그램을 다음과 같이 사용할 수 있도록 개량하고 이름을 ftuc로 정하면 더욱 쓰기 편할 것이다.

% ftuc myfile

이런 이유로 이 장에서는 어셈블리로 ftuc를 작성하고(원래 tuc는 C로 작성되었다.) 커널이 프로세스에게 제공하는 다양한 파일 서비스를 살펴볼 것이다.

언뜻 생각해 보면 파일 변환은 매우 간단한 작업이다. 해야 할 일은 cr/lf(carrage return/line feed)를 다른 개행 문자로 바꿔 주는 일 뿐이다. 안 그런가??

만약 개행 문자 변환 뿐이라고 생각했다면 다시 한번 재고해 보아라. 이 접근 방법은 대부분의 경우에 동작하겠지만(적어도 MS DOS 텍스트 파일에서는) 어떤 경우에는 잘못된 동작을 수행할 것이다.

문제는 모든 유닉스 이외의 운영체제에서 만들어지는 텍스트 파일이 cr/lf로 끝나진 않는다는 것이다. 일부 운영체제에서는 lf 없이 cr만을 사용하며, 일부는 여러 공백 라인을 여러 개의 lf와 cr 한 개로 대체하기도 한다.

이렇게 본다면 텍스트 파일 변환기는 라인의 끝을 표시하는 모든 가능한 조합을 처리할 수 있어야 한다.

l cr/lf

l cr

l lf/cr

l lf

또한 위의 조건들의 조합(몇 개의 lf 다음에 cr이 나온다든지.)을 사용하는 파일을 처리해야 할 것이다.

11.1. Finite State Machine

문제는 FSM(Finite State Machine)이라는 기술을 사용하면 쉽게 해결된다. FSM은 출력 값이 현재 상태에서의 입력 값 뿐 아니라 그 전 입력 값에도 관련되어 있는 디지털 회로이다. 마이크로프로세서는 FSM의 한 예가 된다. 우리의 어셈블리 코드는 기계어로 어셈블 되는데, 이 기계어 중 일부는 여러 개의 어셈블리 코드가 한 바이트의 기계어를 만들어 낸 것일 수도 있고 일부는 여러 개의 어셈블리 코드가 여러 바이트의 기계어를 만들어 낸 것이다. 마이크로프로세서는 메모리에서 단계적으로 바이트를 패치(fetch)하는데, 패치된 바이트의 일부는 어떤 결과를 내지 않고 단지 상태만 변화시키는 것들이다. 모든 op code가 패치되면 마이크로프로세서는 어떤 결과를 만들어 내거나 레지스터의 값을 변화시킬 것이다.

이런 이유로 모든 소프트웨어는 본질적으로 마이크로프로세서를 위한 상태 명령어(state instruction)의 연속이다. 그럼에도 불구하고 FSM의 개념은 소프트웨어의 설계에 중요한 역할을 한다.

우리의 텍스트 파일 변환기는 세 가지의 가능 상태가 있는 FSM으로 설계될 수 있다. 우리는 이러한 가능 상태를 상태 0-2라 부를 수 있지만 각각의 상태에 상징적인 이름을 부여하면 좀 더 편해질 수 있다.

l ordinary

l cr

l lf

우리 프로그램은 ordinary 상태에서 시작한다. 이 상태에 있는 동안 프로그램은 다음과 같이 입력에 따라 다른 동작을 한다.

l 입력이 cr이나 lf이외의 다른 값이라면 그대로 출력할 뿐이며, 상태도 변하지 않는다.

l 입력이 cr이면 상태는 cr 상태로 변하고, 입력 값은 버려진다. 따라서 아무런 출력도 만들어 지지 않는다.

l 입력이 lf라면 상태는 lf로 변하고, 입력 값은 버려진다.

cr 상태에 있는 동안에는 아무런 작업도 수행되지 않는데, 이것은 cr이 마지막 입력이기 때문이다. 이 상태에 있는 우리 프로그램은 현재의 입력에 따라 다른 동작을 한다.

l 입력이 cr이나 lf이외의 것이라면 lf과 입력 값을 출력하고 상태를 ordinary로 변경한다.

l 입력이 cr이라면 한 줄에서 두 개 이상의 cr을 받은 것이다. 따라서 입력을 버리고 lf를 출력한다. 이 때 상태는 변경시키지 않는다.

l 입력이 lf라면 lf를 출력하고 상태를 ordinary로 변경시킨다. 이 상태가 위의 첫번째 상황과 같지 않음에 유의하라. 만약 두 상황을 결합시킨다면 한 개가 아닌 두 개의 lf를 출력할 것이다.

이제 프로그램은 cr을 받고서도 처리되지 않은 lf를 받은 후의 lf 상태에 있다. 이 상황은 (1)대상 파일이 이미 유닉스 형식이거나 (2)한 줄(row)에 있는 여러 라인을 여러 개의 lf와 한 개의 cr로 처리한 경우, 혹은 (3) 라인이 lf/cr로 끝난 경우에 일어난다. 이제 이 상황에서 들어온 입력을 다음과 같이 처리할 수 있다.

l 입력이 cr아니 lf 이외의 것이라면 lf와 입력 값을 출력하고 상태를 ordinary로 변경한다. 이것은 정확히 cr 상태에서 똑같은 입력 값을 받았을 때와 같은 동작이다.

l 입력이 cr이면 입력 값을 버리고 lf를 출력한다. 그리고 상태를 orfinary로 변경시킨다.

l 입력이 lf라면 lf를 출력하고 상태를 그대로 놔둔다.

11.1.1. The Final State

위의 FSM은 전체 파일에 대해 동작하지만 마지막 라인이 무시될 가능성이 있다. 이러한 상황은 파일이 하나의 cr이나 lf로 끝날 때 발생한다. 필자는 tuc를 설계할 때 이러한 상황을 고려하지 않고 마지막 라인을 제거했었다.

이 문제는 전체 파일이 처리된 후의 상태를 검사하면 쉽게 수정할 수 있다. 만약 상태가 ordinary가 아니라면 단순히 마지막 lf를 출력하면 된다.

N.B.: 프로그램에서 사용될 알고리즘을 FSM으로 표현했기 때문에 파일 변환 문제를 처리하는 디지털 전자 회로(digital electronic circuit)을 쉽게 설계할 수 있다. 물론, 칩을 설계하고 구현하는 것은 어셈블리 언어로 프로그램을 작성하는 것보다 훨씬 많은 노력이 드는 일이다.

11.1.2. The Output Counter

파일 변환 프로그램이 두 문자를 결합하여 한 문자로 만들기 때문에 출력 카운터(output counter)가 필요하다. 프로그램에서는 0으로 초기화 시키고 한 문자를 출력할 때마다 카운터를 증가시킨다. 따라서 프로그램이 끝날 때의 카운터에는 파일 크기가 기록되어 있을 것이다.

11.2. Implementing FSM in Software

FSM을 이용하여 어떤 문제를 해결할 때 가장 어려운 점은 문제를 분석하고 분석한 문제를 FSM으로 표현하는 것이다. 이것이 해결되면 소프트웨어는 거의 다 쓴 것이나 마찬가지이다.

C같은 고 수준 언어를 사용할 때는 FSM을 구현하는 몇 가지 접근 방법이 있다. 하나는 switch 문장을 사용하여 각각의 경우에 실행되어야 할 함수로 분기하는 것이다. 가령 다음과 같은 형식이다.

  switch (state) {
 default:
 case REGULAR:
  regular(inputchar);
  break;
 case CR:
  cr(inputchar);
  break;
 case LF:
  lf(inputchar);
  break;
 }

또 다른 방법은 다음과 같이 함수 포인터(function pointer)의 배열을 사용하는 것이다.

(output[state])(inputchar);

이 경우 state를 함수 포인터로 구현하고 적절한 함수를 가리키도록 설정해야 한다.

(*state)(inputchar);

이 방법이 바로 우리 프로그램에서 사용될 방법인데, 이유는 이 방법을 어셈블리 언어로 구현하기 쉽고 매우 빠른 수행 속도를 보이기 때문이다. 프로그램에서는 수행되어야 할 프로시져의 주소를 EBX에 넣고 다음과 같이 호출하기만 하면 된다.

 call ebx

마이크로프로세서가 메모리에서 주소를 패치할 필요가 없기 때문에-주소가 이미 레지스터 중 하나에 저장되어 있다.- 코드에 주소를 직접 기록하는 것보다 빠를 수 있다. 필자는 빠를 수 있다고 표현했는데, 이것은 최근에 개발된 마이크로프로세서들이 캐싱(caching)을 하기 때문에 레지스터에 미리 저장되어 있는 것과 다를 바 없는 경우가 많기 때문이다.

11.3. Memory Mapped Files

프로그램이 하나의 파일에 대해서만 동작하기 때문에 입력 파일에서 읽고 출력 파일에 썼던 기존의 방법을 그대로 사용할 수 없다.

유닉스는 파일의 전부 혹은 일부를 메모리에 맵핑(mapping)시킬 수 있는 매커니즘을 지원한다. 이 기능을 사용하기 위해서는 우선 파일을 적절한 읽기/쓰기 플래그와 함께 연다. 그리고 mmap 시스템 콜을 사용하여 파일을 메모리에 맵핑시킨다. mmap이 좋은 점은 자동으로 가상 메모리에 맵핑된다는 것이다. 따라서 실제 메모리 크기 보다 큰 용량의 파일들을 메모리에 맵핑시킬 수 있다. 또, 여전히 mob.lods, stos 같은 일반 메모리 op code를 이용하여 접근할 수도 있으며 파일의 메모리 이미지에 어떤 변화가 생길 때마다 파일 시스템의 파일에 반영된다. 게다가 맵핑되어 있는 동안은 파일을 연 상태로 유지하지 않고도 파일에서 데이터를 읽고 파일로 데이터를 쓸 수 있다.

32비트 인텔 마이크로프로세서들은 4GB의 메모리-물리 메모리든 가상 메모리든-까지 접근할 수 있다. FreeBSD 시스템은 이 메모리 영역 중 2GB를 파일 맵핑에 사용할 수 있다.

문제를 단순화시키기 위해 이 튜토리얼에서는 전체 영역을 맵핑할 수 있는 파일에 한해서만 변환 기능을 지원하기로 한다. 2GB가 넘는 텍스트 파일은 아마 거의 없을 것이다. 만약 우리 프로그램이 이러한 상황에 직면한다면 단순히 tuc를 사용하라는 메시지를 출력하고 종료할 것이다.(tuc는 맵핑 파일을 사용하지 않았다.)

syscalls.master를 보면 mmap이라는 이름의 두 시스템 콜을 발견할 수 있을 것이다. 이것은 유닉스에 수많은 변종이 있기 때문인데, 실제 전통적인 BSD mmap은 71번으로 설정되어 있으며 POSIX mmap은 197번으로 설정되어 있다. FreeBSD 시스템은 초기의 BSD 환경에서 작성된 프로그램을 지원하기 위해서 두 시스템 콜을 모두 지원한다. 하지만 새로 작성될 소프트웨어는 POSIX 버젼을 사용해야 한다.

syscall.master 파일에는 다음과 같이 POSIX 버젼에 대한 내용이 기록되어 있다.

197 STD BSD { caddr_t mmap(caddr_t addr, size_t len, int prot, \
    int flags, int fd, long pad, off_t pos); }

이 시스템 콜은 mmap(2)와는 조금 다른데, 이는 mmap(2)가 C를 위해 작성된 함수이기 때문이다.

C 버젼과 시스템 콜의 차이점은 long pad 인자인데, 이 인자가 C 버젼에는 없기 때문이다. 하지만 FreeBSD 시스템 콜은 64비트 인자를 푸시한 후 32비트 패드(pad)를 추가했다. 이 경우 off_t는 64 비트 값이 된다.

프로그램이 메모리 맵을 더 이상 사용하지 않는다면 munmap 시스템 콜을 사용하여 맵핑을 해제 시켜야 한다.

TIP: W. Richard Stevens의 Unix Network Programming, Volume 2 Chapter 12 를 보면 mmap에 대해 자세히 나와 있다.

11.4. Determining File Size

파일의 어느 정도 크기를 메모리에 맵핑시키고 싶은지를 mmap에게 알려줘야 하는데, 우리 프로그램의 경우 전체 파일을 맵핑시키기 때문에 파일의 크기를 알아야 한다.

이 경우 fstat 시스템 콜을 사용하여 파일의 크기를 알아낼 수 있다. syscalls.master에는 mmap과 마찬가지로 두 가지 버젼의 fstat이 발견된다. (전통적인 시스템 콜 62, POSIX 시스템 콜 189) 당연한 말이지만 우리 프로그램에서는 POSIX 버젼을 사용할 것이다.

189 STD POSIX { int fstat(int fd, struct stat *sb); }

이것은 매우 직접적인 호출이다. 프로그램에서 이 시스템 콜에 stat 구조체의 주소와 열린 파일의 기술자를 넘기면 시스템 콜은 구조체에 정보를 채워 리턴한다.

하지만 필자가 .bss 섹션에 stat 구조체를 선언하고 fstat 시스템 콜을 호출하자 에러가 발생했음을 알리는 캐리 플래그(carray flag)가 설정됐다. 필자는 스택에 구조체를 할당하도록 코드를 수정한 후에야, 모든 동작이 정상적으로 수행됨을 확인할 수 있었다.

11.5. Changing the File Size

우리 프로그램이 cr/lf를 lf로 변경하기 때문에 출력 파일은 입력 파일 보다 작을 수 있다. 그런데 입력 파일을 출력 파일로 대체하기 때문에 파일의 크기를 변경할 수 있어야 한다.

ftruncate 시스템 콜은 이렇게 파일 크기를 변경하는 기능을 제공한다. 이름은 잘못 지은 감이 있지만 ftruncate 시스템 콜은 파일을 자를 수도 있고(파일을 작게 만들 수도 있고) 키울 수도 있다.

그리고 이전의 시스템 콜들과 마찬가지로 syscalls.master 파일에서 두 버젼의 ftruncate 시스템 콜을 발견할 수 있다.(예전 시스템 콜 130, POSIX 시스템 콜 201) 우리는 이전과 마찬가지로 POSIX 시스템 콜을 사용한다.

201 STD BSD { int ftruncate(int fd, int pad, off_t length); }

이 시스템 콜이 int pad를 다시 포함하고 있다는 사실에 유의하라.

11.6. ftuc

우리는 이제 ftuc 프로그램을 작성하는데 필요한 모든 지식을 알게 되었다. 이제 system.inc 파일에 새로운 라인을 추가하면서 프로그램의 작성을 시작해 보자. 먼저 파일의 시작 부분 근처에 몇 개의 상수와 구조체를 선언하자.

;;;;;;; open flags
%define O_RDONLY 0
%define O_WRONLY 1
%define O_RDWR 2
 
;;;;;;; mmap flags
%define PROT_NONE 0
%define PROT_READ 1
%define PROT_WRITE 2
%define PROT_EXEC 4
;;
%define MAP_SHARED 0001h
%define MAP_PRIVATE 0002h
 
;;;;;;; stat structure
struc stat
st_dev  resd 1 ; = 0
st_ino  resd 1 ; = 4
st_mode  resw 1 ; = 8, size is 16 bits
st_nlink resw 1 ; = 10, ditto
st_uid  resd 1 ; = 12
st_gid  resd 1 ; = 16
st_rdev  resd 1 ; = 20
st_atime resd 1 ; = 24
st_atimensec resd 1 ; = 28
st_mtime resd 1 ; = 32
st_mtimensec resd 1 ; = 36
st_ctime resd 1 ; = 40
st_ctimensec resd 1 ; = 44
st_size  resd 2 ; = 48, size is 64 bits
st_blocks resd 2 ; = 56, ditto
st_blksize resd 1 ; = 64
st_flags resd 1 ; = 68
st_gen  resd 1 ; = 72
st_lspare resd 1 ; = 76
st_qspare resd 4 ; = 80
endstruc

그리고 새로운 시스템 콜을 정의한다.

%define SYS_mmap 197
%define SYS_munmap 73
%define SYS_fstat 189
%define SYS_ftruncate 201

이제 새로 정의된 시스템 콜을 사용하기 위한 매크로를 추가한다.

%macro sys.mmap 0
 system SYS_mmap
%endmacro
 
%macro sys.munmap 0
 system SYS_munmap
%endmacro
 
%macro sys.ftruncate 0
 system SYS_ftruncate
%endmacro
 
%macro sys.fstat 0
 system SYS_fstat
%endmacro

다음이 전체 코드의 내용이다.

;;;;;;; Fast Text-to-Unix Conversion (ftuc.asm) ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;; Started: 21-Dec-2000
;; Updated: 22-Dec-2000
;;
;; Copyright 2000 G. Adam Stanislav.
;; All rights reserved.
;;
;;;;;;; v.1 ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
%include 'system.inc'
 
section .data
 db 'Copyright 2000 G. Adam Stanislav.', 0Ah
 db 'All rights reserved.', 0Ah
usg db 'Usage: ftuc filename', 0Ah
usglen equ $-usg
co db "ftuc: Can't open file.", 0Ah
colen equ $-co
fae db 'ftuc: File access error.', 0Ah
faelen equ $-fae
ftl db 'ftuc: File too long, use regular tuc instead.', 0Ah
ftllen equ $-ftl
mae db 'ftuc: Memory allocation error.', 0Ah
maelen equ $-mae
 
section .code
 
align 4
memerr:
 push dword maelen
 push dword mae
 jmp short error
 
align 4
toolong:
 push dword ftllen
 push dword ftl
 jmp short error
 
align 4
facerr:
 push dword faelen
 push dword fae
 jmp short error
 
align 4
cantopen:
 push dword colen
 push dword co
 jmp short error
 
align 4
usage:
 push dword usglen
 push dword usg
 
error:
 push dword stderr
 sys.write
 
 push dword 1
 sys.exit
 
align 4
global _start
_start:
 pop eax  ; argc
 pop eax  ; program name
 pop ecx  ; file to convert
 jecxz usage
 
 pop eax
 or eax, eax ; Too many arguments?
 jne usage
 
 ; Open the file
 push dword O_RDWR
 push ecx
 sys.open
 jc cantopen
 
 mov ebp, eax ; Save fd
 
 sub esp, byte stat_size
 mov ebx, esp
 
 ; Find file size
 push ebx
 push ebp  ; fd
 sys.fstat
 jc facerr
 
 mov edx, [ebx + st_size + 4]
 
 ; File is too long if EDX != 0 ...
 or edx, edx
 jne near toolong
 mov ecx, [ebx + st_size]
 ; ... or if it is above 2 GB
 or ecx, ecx
 js near toolong
 
 ; Do nothing if the file is 0 bytes in size
 jecxz .quit
 
 ; Map the entire file in memory
 push edx
 push edx  ; starting at offset 0
 push edx  ; pad
 push ebp  ; fd
 push dword MAP_SHARED
 push dword PROT_READ | PROT_WRITE
 push ecx  ; entire file size
 push edx  ; let system decide on the address
 sys.mmap
 jc near memerr
 
 mov edi, eax
 mov esi, eax
 push ecx  ; for SYS_munmap
 push edi
 
 ; Use EBX for state machine
 mov ebx, ordinary
 mov ah, 0Ah
 cld
 
.loop:
 lodsb
 call ebx
 loop .loop
 
 cmp ebx, ordinary
 je .filesize
 
 ; Output final lf
 mov al, ah
 stosb
 inc edx
 
.filesize:
 ; truncate file to new size
 push dword 0  ; high dword
 push edx  ; low dword
 push eax  ; pad
 push ebp
 sys.ftruncate
 
 ; close it (ebp still pushed)
 sys.close
 
 add esp, byte 16
 sys.munmap
 
.quit:
 push dword 0
 sys.exit
 
align 4
ordinary:
 cmp al, 0Dh
 je .cr
 
 cmp al, ah
 je .lf
 
 stosb
 inc edx
 ret
 
align 4
.cr:
 mov ebx, cr
 ret
 
align 4
.lf:
 mov ebx, lf
 ret
 
align 4
cr:
 cmp al, 0Dh
 je .cr
 
 cmp al, ah
 je .lf
 
 xchg al, ah
 stosb
 inc edx
 
 xchg al, ah
 ; fall through
 
.lf:
 stosb
 inc edx
 mov ebx, ordinary
 ret
 
align 4
.cr:
 mov al, ah
 stosb
 inc edx
 ret
 
align 4
lf:
 cmp al, ah
 je .lf
 
 cmp al, 0Dh
 je .cr
 
 xchg al, ah
 stosb
 inc edx
 
 xchg al, ah
 stosb
 inc edx
 mov ebx, ordinary
 ret
 
align 4
.cr:
 mov ebx, ordinary
 mov al, ah
 ; fall through
 
.lf:
 stosb
 inc edx
 ret

WARNING: MS DOS나 윈도우로 포맷된 디스크에 저장된 파일에는 이 프로그램을 사용하지 말아라. FreeBSD에서 마운트된 드라이브에서 mmap을 사용할 때, FreeBSD 코드에 미묘한 버그가 발생한다. 이 버그는 파일이 특정 크기 이상 일때 mmap을 실행시키면 메모리를 0으로 채우고 그 영역을 파일로 그대로 복사하여 결과적으로 파일의 내용을 모두 0으로 만든다.

Chapter 12 – Caveats

MS DOS와 윈도우 환경에서 어셈블리 언어를 공부한 사람은 최단 코스를 취하려는 경향이 있다. 키보드의 스캔 코드(scan code)를 읽고 비디오 메모리로 직접 스캔 코드를 쓰는 프로그램이 MS DOS 환경에서 사용되는 두 개의 고전적인 예제 중 하나이다. 이 프로그램은 동작을 하지 않는 것은 아니지만 적절한 구현 방법이라 생각되진 않는다.

이유가 뭘까? 이러한 연산을 수행할 때, PC BIOS와 MS DOS가 모두 느려진다는 것은 유명한 사실이다.

유닉스 환경에서도 이 비슷한 습관을 계속 보이는 사람도 있을 것이다. 가령, 필자는 일반적인 유닉스 환경에서 키보드 스캔 코드에 접근하는 방법을 설명한 웹 사이트를 본 적이 있다.

이것은 적어도 유닉스 환경에서는 매우 나쁜 습관인데, 이제부터 그 이유를 설명하도록 하겠다.

12.1. Unix Is Protected

먼저 하드웨어에 직접 접근하는 것 자체가 불가능할 수도 있다. 유닉스는 보호 모드에서 동작한다. 따라서 단지 커널과 디바이스 드라이버만이 하드웨어에 직접 접근할 수 있다. 아마도 몇몇 유닉스 호환 운영체제는 키보드 스캔 코드를 읽을 수 있도록 해 줄 수도 있지만 문제는 유닉스 운영체제는 이러한 직접 접근을 허용하지 않는다는 것이다. 또한 현재 버젼의 운영체제가 직접 접근을 허용 한다 해도 다음 버젼도 허용한다는 보장이 없다. 따라서 힘들여 작성한 소프트웨어가 3일 천하가 될 수도 있다.

12.2. Unix Is an Abstraction

하지만 하드웨어 직접 접근을 허용하는 유닉스 호환 운영체제에서 조차 직접 접근하는 시도를 하지 않아야 할 진정 중요한 이유는 따로 있다.(물론 디바이스 드라이버를 작성한다면 예외다.)

Unix is an abstraction!

MS DOS와 유닉스의 설계 철학에는 큰 차이점이 있다. MS DOS는 한 명의 사용자를 위해 설계된 운영체제이다. 따라서 이 운영체제는 하나의 키보드와 하나의 비디오 스크린이 직접 부착되어 있는 컴퓨터에서 수행된다. 사용자 입력은 거의 키보드로 들어오며 프로그램의 출력은 대부분 스크린으로 나간다.

이러한 사항들이 유닉스에서는 지켜지지 않는다. 유닉스 사용자는 한 프로그램의 출력을 재지정(redirect)하여 다른 프로그램의 입력으로 향하게 하는 다음과 같은 형식으로 많은 작업을 처리한다.

% program1 | program2 | program3 > file1

만약 program2를 작성했다면 프로그램의 입력은 키보드에서 오는 것이 아니며, 출력도 스크린이 아닌 program3로 나간다. 그리고 출력은 program3을 거쳐 file1으로 향한다.

하지만 더 많은 이유가 있다! 심지어 프로그램의 입력과 출력 방향이 터미널로 일정하다 하더라도 터미널이 PC라는 보장이 없다. 그 터미널은 프로그래머가 예상하는 곳에 비디오 메모리가 없을 수도 있으며 키보드도 PC 스타일의 스캔 코드를 사용하지 않을 수도 있다. 터미널이 매킨토시(Macintosh)라면 어떻겠는가?

지금쯤 고개를 흔들고 있는 사람이 있을 지 모르겠다. 지금까지 살펴본 프로그램들은 모두 어셈블리 언어로 작성되었다. 이 프로그램들을 어떻게 매킨토시에서 수행될 수 있도록 할 수 있겠는가? 하지만 필자는 작성한 소프트웨어를 매킨토시에서 수행시키라는 요구는 하지 않았다. 단지 터미널이 매킨토시일 경우에도 프로그램이 정상 수행되어야 하지 않겠는가?

유닉스 환경에서 터미널은 소프트웨어가 돌아가는 컴퓨터에 직접 접속해 있을 필요가 없다. 오스트레일리아에 사는 매킨토시 사용자가 북 아메리카에(혹은 어느 곳이든) 있는 유닉스 시스템에 telnet을 이용하여 접속하는 것이 가능하다. 그리고 터미널이 소프트웨어가 실행되는 컴퓨터에 있지 않다 할지라도 소프트웨어는 정상적으로 실행된다. 만약 스캔 코드를 읽으려 한다면 잘못된 값을 얻을 수도 있다.

어떤 하드웨어에 대해서도 동일한 가정이 성립한다면 위와 같은 모든 상황이 가능해 진다. 여러분이 읽고 있는 파일은 직접 접근할 수 없는 디스크에 있는 것일 수도 있으며, 보고 있는 이미지가 인공위성을 거쳐 연결된 우주선의 카메라의 것일 수도 있다.

이것이 유닉스 환경에서 데이터가 어디로 들어오고 어디로 나가는 지를 가정하면 안 되는 이유다. 시스템은 어느 상황에서도 하드웨어에 물리적인 접근을 할 수 있도록 처리할 수 있어야 한다.

N.B.: 어느 정도의 제재(caveats)가 있지만 절대적인 규칙은 아니다. 예외도 가능하다. 가령, 로컬 머신(local machine)에서만 돌아가는 텍스트 에디터를 작성한다면 보다 향상된 제어를 위해 직접 스캔 코드를 읽어 들이고 싶을 수도 있다. 필자는 무엇을 하고 무엇을 하지 말라는 제재 사항을 말하고 싶은 것이 아니라 MS DOS에서 유닉스 환경으로 이제 막 이전한 사람들이 생각지 않고 있는 함정을 알려 주려는 것 뿐이다. 물론 창조적인 사람들은 종종 규칙을 깬다. 당부하고 싶은 것은 최소한 자기가 기존의 규칙을 깨고 있다는 사실을 인지하고 규칙을 깨는 이유도 알면서 새로운 규칙을 만들라는 것이다.

Appendix A – Assembly Language Pearls

다음은 필자가 이 튜토리얼을 쓰기 시작한 이래 기고했던 다른 어셈블리 언어 관련 기사다. 기사들은 이 튜토리얼의 내용 중 일부를 읽을 만한 분량으로 줄인 것들이다.

l String Length – 어셈블리 언어에서 텍스트 문자열의 길이를 계산하는 방법으로 소개하고 있다.

l Smallest Unix Program – 가장 작은 유닉스 프로그램이 얼마나 우리를 위축시키는 지 확인해 보라.

Appendix B – BSD Style Copyright

BSD 스타일의 저작권으로 소프트웨어를 출시하고자 한다면 FreeBSD 시스템 도처에 위치해 있는 bsd-style-copyright를 찾아 참조할 수 있다. 그리고 이 저작권은 C 스타일의 주석을 사용한다는 사실도 기억해 두라.

필자는 BSD 스타일의 저작권을 어셈블리 언어 프로그램까지 포함하도록 편집하였다. 이 저작권을 보고 싶다면 nasm-compatible BSD-style copyright를 다운 받고 자신의 이름과 소스 코드를 기록하기 바란다.

Appendix C – Acknowledgements

이 튜토리얼은 FreeBSD hackers 메일링 리스트의 많은 뛰어난 프로그래머들의 도움이 없었다면 작성되기 어려웠을 것이다. 그들은 인내를 가지고 필자의 질문에 답해 주었으며, FreeBSD와 유닉스 시스템 프로그래밍의 내부를 파헤쳐 보고자 했던 필자에게 올바른 길을 제시해 주었다.

Thomas M. Sommers는 필자에게 FreeBSD 시스템 프로그래밍의 문을 열어준 사람이다. 그의 How do I write “Hello, world” in FreeBSD assembler? 웹 페이지는 필자가 FreeBSD 환경에서 접한 첫번째 어셈블리 예제였다.

Jake Burkholder는 필자의 모든 질문에 성의 있게 답해 주었으며 필자에게 다양한 어셈블리 언어 소스 코드를 제공해 준 사람이다.

Copytight © 2000 G. Adam Stanislav.

All rights reserved.