Introduction
Absolute Loader
Machine-Dependent Loader Features(Linking Loader)
Machine-Independent Loader Features
Loader Design Options
Linkers and Loaders(1) 과 이어지는 내용이다.
다음 이미지는 어셈블러의 Two-pass process를 나타낸 것이다.
이제 링킹 로더의 자료구조와 알고리즘을 살펴보자. 링킹 로더의 알고리즘은 어셈블러의 2 pass 알고리즘과 상당히 유사하다.
pass 1에서 모든 외부 심볼들에 대해서 주소를 할당하고, pass 2에서는 실제적인 로딩, 재배치 그리고 링킹을 수행한다.
Data Structures
ESTAB(External Symbol Table)
링킹 로더에 대해 필요한 주요 자료구조는 외부 심볼 테이블인 ESTAB이다. 어셈블러 알고리즘 안에서의 SYMTAB과 유사한 이 테이블은, 로드되어진 제어 섹션들의 집합 안에서의 각 외부 기호의 이름과 주소를 저장하기 위해 사용되어진다. 또한 ESTAB은 어떤 제어 섹션 안에서 기호가 정의되어졌는지를 가리킨다. 해쉬 구조가 보통 이 테이블의 구현에 사용된다.
PROGADDR(Program Load Address): 프로그램 로드 주소
링크된 프로그램이 로드되어지는 메모리의 시작 주소이다. 이 값은 운영체제에 의해 로더에게 제공된다.
CSADDR(Control Section Address): 제어 섹션 주소
로더에 의해 현재 스캔되고 있는 제어 섹션에 할당된 시작 주소이다. 이 값은 모든 상대 주소들을 실제 주소들로 변환하기 위해 제어 섹션 내의 모든 상대 주소들에 더해진다.
Algorithm
pass 1 동안에 로더는 오직 제어 섹션들 안에서의 헤더(H)와 정의 레코드(D)에 대해서만 다룬다.
(only Header and Define records are concerned)
링크된 프로그램(PROGADDR)에 대한 시작 로드 주소는 운영 체제로부터 얻어진다.
(get PROGADDR from operating system)
이 주소는 첫 번째 제어 섹션에 대한 시작 주소(CSADDR)가 된다.
(set CSADDR to PROGADDR)
헤더 레코드로부터의 제어 섹션 이름은 CSADDR 값과 함께 ESTAB으로 들어간다.
(enter control section name into ESTAB with value CSADDR)
제어 섹션에 대한 정의 레코드 안에서 나타나는 모든 외부 심볼들은 ESTAB으로 들어간다.
(enter symbol into ESTAB)
정의 레코드 안에서 명시된 값에 CSADDR을 추가함으로써 외부 심볼들의 주소가 얻어진다.
(CSADDR + indicated address)
End 레코드를 만났을 때, 헤더 레코드로부터 저장된 제어 섹션 길이(CSLTH)가 CSADDR로 더해진다.
(add CSLTH to CSADDR {starting address for next control section})
이 계산은 다음 제어 섹션에 대한 시작 주소를 결정해주게 된다.
pass 1의 끝에서, ESTAB은 각각에 할당된 주소와 함께 제어 섹션들 내에서 정의된 모든 외부 기호들을 포함한다.
pass 2는 프로그램의 실제적인 로딩, 재배치와 링킹을 수행한다.
CSADDR는 항상 현재 로드되는 제어 섹션의 실제 시작 주소를 담고 있다.
(set CSADDR to PROGADDR) (set EXECADDR to PROGADDR)
각 텍스트 레코트를 만날 때, 목적 코드는 명시된 메모리의 주소로 이동된다.
(if record type = 'T' then ... move object code ... CSADDR + specified address)
수정 레코드를 만나면, ESTAB 안에서 수정될 심볼의 이름을 찾고 심볼의 값을 더하거나 뺀다.
(if record type = 'M' then ... search ESTAB for modifying symbol name, add or subtract symbol value ... CSADDR + s.a.)
로더에 의해 마지막으로 수행되는 단계는 실행을 시작하기 위해 로드된 프로그램으로 제어를 옮기는 것이다.
각 제어 섹션에 대한 end 레코드는 제어 섹션이 실행되는 첫 번째 명령의 주소를 포함한다.
(jump to location given by EXECADDR {to start execution of loaded program})
# Enhance the Algorithm
참조 번호를 제어 섹션에서 참조되는 각 외부 심볼에 할당하는 방법으로 링킹 로더의 알고리즘을 더 효율적으로 만들 수 있다. 이 참조 번호는 수정 레코드 안에서 심볼 이름 대신에 사용된다. 제어 섹션의 이름은 01로 할당되고, 나머지는 02, 03 ... 차례대로 할당된다.
장점: 제어 섹션의 로딩 동안 같은 심볼에 대해 ESTAB을 중복으로 찾는 것을 막아준다.
Machine-Independent Loader Features
Automatic library search loader options
- 외부 참조를 처리하기 위한 자동 라이브러리 검색: 프로그래머가 표준 서브루틴을 사용할 수 있도록 해준다. 이 루틴들은 링크 동안에 필요로할 때마다 라이브러리에서 자동적으로 추출된다.
- 로딩과 링킹 옵션: 입력의 선택 지정, 외부 참조의 변경 또는 삭제, 외부 참조의 자동적인 처리를 조절하는 기능
Automatic Library Secarch: 자동 라이브러리 탐색
많은 링크 로더들은 로드되는 프로그램에 부프로그램 라이브러리 루틴으로부터 루틴들을 자동적으로 포함시킬 수 있다. 이를 표준 시스템 라이브러리라고 하며 라이브러리들은 제어문 또는 파라미터에 의해 로더에게 지정된다.
프로그래머는 하나 이상의 라이브러리에서 부루틴을 프로그래밍 언어의 일부인 것처럼 사용할 수 있다.
로드되는 프로그램에서 부루틴은 자동적으로 라이브러리로부터 가져오며, 주 프로그램과 링크되고 로드된다.
프로그래머는 원시 프로그램에서 외부 참조로서 부루틴 이름을 지정하는 것 이외의 다른 작업을 할 필요가 없다. 이러한 기능을 자동 라이브러리 호출이라 한다.
Implementation of Automatic Library Search
자동 라이브러리 탐색을 제공하는 링크 로더는 입력 프로그램에서 정의되지 않은 외부 기호를 추적해야만 한다. 각 참조 레코드에서 어떤 기호가 현재 기호 테이블에 없다면, 기호 테이블(ESTAB)에 기입하고, 이 기호가 아직 정의되지 않았음을 표시한다. 나중에 이 기호가 정의되면 기호에 배정된 주소를 채워서 완성한다.
패스 1이 끝난 후에 정의되지 않고 ESTAB에 남아있는 기호는 미해결 외부 참조임을 표시한다. 로더는 이들 기호의 정의를 포함하는 루틴을 위해 지정된 라이브러리를 탐색하고, 이 탐색에서 발견된 부루틴들은 원래의 입력 프로그램의 일부였던 것처럼 처리한다.
라이브러리 탐색 과정은 모든 참조가 해결될 때까지 반복된다. 라이브러리 탐색이 완료된 후에도 해결되지 않은 외부 참조가 있다면 오류로 처리된다.
Discussions of Automatic Library Search
제시된 링킹 로더는 프로그래머가 자신이 만든 루틴을 제공함으로써 라이브러리에 있는 표준 부루틴을 덮어 쓸 수 있도록 한다.
예를 들어, 주프로그램이 SQRT라는 표준 부루틴을 참조한다고 가정하자. 이 이름의 부루틴은 자동적으로 라이브러리 탐색을 통해 포함된다. 다른 종류의 SQRT를 사용하기를 원하는 프로그래머는 이 SQRT를 로더의 입력에 포함시키면 된다.
로더의 패스 1이 끝난 후 SQRT는 이미 정의되어 있으므로, 라이브러리 탐색이 불필요하게 된다.
로더에 의해 탐색되는 라이브러리는 부루틴의 어셈블 또는 컴파일된 형태인 목적 프로그램을 포함하고 있다. 이러한 라이브러리 탐색은 라이브러리에서 목적 프로그램의 정의 레코드를 조사함으로써 가능하지만 비효율적이다. 이름과 각 루틴의 주소를 가리키는 진입점을 제공하는 디렉토리를 탐색하는 것이 더 효율적이다.
Loader Options
사용자는 로더의 표준 처리를 변경할 수 있도록 옵션을 지정할 수 있다. 이 때 특별한 명령어를 사용한다:
독립된 입력 파일일 수도 있고, 본래의 입력 흐름에서 목적 프로그램들 사이에 제어문들이 삽입될 수 있다, 로더 제어문을 원시 프로그램에 포함시킬 수도 있다.
전형적인 로더 선택 사항:
입력으로 원시 프로그램을 선택하는 명령어
- INCLUDE program-name(library-name): 로더가 라이브러리에서 지시한 목적 프로그램을 읽어들이고 기본 로더 입력의 일부인 것처럼 취급하도록 지시한다.
외부 기호나 제어 섹션 전체를 삭제하도록 하는 명령어
- DELETE csect-name: 로드되는 프로그램들 중에서 지정된 제어 섹션을 로더가 삭제하도록 지시한다.
프로그램 내에서 외부 참조를 변경하도록 하는 명령어
- CHANGE name1, name2: 외부 기호 name1을 name2로 변경한다. 목적 프로그램의 어느 위치에 있는지와 상관없다.
라이브러리 루틴을 자동으로 포함하는 명령어
- LIBRARY MYLIB: 탐색할 라이브러리를 지정한다. 사용자 지정 라이브러리는 표준 시스템 라이브러리를 탐색하기 전에 탐색된다.
- NOCALL name: 외부 참조 name이 미 해결된 상태로 남아있게 로더에게 지시한다.
라이브러리 UTLIB에서 READ와 WRITE 제어 섹션을 포함시키고, RDREC, WRREC 제어 섹션을 삭제하도록 로더에게 지시한다. 기호 RDREC에 대한 모든 외부 참조를 기호 READ로 참조하도록 변경하며, WRREC에 대한 모든 외부 참조를 WRITE로 변경하도록 지시한다. 그 결과 원시 프로그램은 READ와 WRITE를 사용하는 것과 같다.
Loader Design Options
Linkage Editors
Dynamic Linking
Bootstrap Loaders
Linkage Editors
링킹 로더(linking loader)는 로드 시간에 모든 링크와 재배치를 수행한다.
링크 편집기(linkage editor)는 로드 시간 이전에 링크를 수행한다.
동적 링킹(dynamic linking)은 실행 시간에 링크를 수행한다.
링킹 로더(Linking Loader)는 자동 라이브러리 검색을 포함하여 모든 링크와 재배치 작업을 수행하고, 이 링크된 프로그램 실행을 위해 직접 메모리로 로드한다.
반면에 링크 편집기(Linkage Editor)는 프로그램의 링크된 버전을 생성하고, 나중에 실행하기 위해 라이브러리나 파일로 출력한다. <즉시 메모리로 로드되지 않는다.> 사용자가 링크된 프로그램을 실행하고자 할 때, 간단한 재배치 로더(one pass)가 프로그램을 메모리로 로드한다. 목적 코드 수정은 단지 프로그램 내의 상대적인 값에 실제 로드 주소를 더해주는 것이다. 링크 편집기는 모든 제어 섹션을 링크된 프로그램의 시작으로부터 상대적으로 재배치한다. <따라서 로드 시에 수정이 필요한 모든 항목은 링크된 프로그램의 시작으로부터 상대적인 값을 갖고 있다.> 이것은 로드가 외부 기호 테이블(ESTAB) 없이 단일 패스에 완료될 수 있다는 것을 의미한다. 결과적으로 링킹 로더를 사용하는 것보다 적은 부담을 준다.
프로그램이 다시 어셈블되지 않고 여러 번 실행된다면, 링크 편집기(linkage editor)의 사용이 더 효율적이다. 외부 참조의 처리와 라이브러리 탐색은 프로그램이 링크 편집되는 때에 단 한번만 수행되기 때문이다.
반면에, 링킹 로더는 프로그램이 실행될 때마다 라이브러리를 탐색하고 외부참조를 결정한다.
때로는 실행될 때마다 거의 매번 다시 어셈블되어야 하는 프로그램이 있다. 프로그램의 개발과 테스트를 주로하는 환경이 그렇다. 또한 프로그램이 매우 드물게 사용되서 라이브러리에 어셈블된 것과 링크된 버전을 저장할 필요가 없는 경우도 있다. 이러한 경우 링크된 프로그램을 저장하고 접근하는 과정이 필요없는 링킹 로더(linking loader)를 사용하는 것이 더 효과적이다.
Dynamic Linking (dynamic loading, load and call)
실행 시간까지 링킹을 연기한다. 서브루틴은 첫 번째로 호출될 때에 프로그램의 나머지에 로드되고 링크된다.
실행중인 프로그램들이 서브루틴이나 라이브러리의 복사본을 공유하게끔 한다.
객체 지향 시스템에서 공유된 오브젝트의 구현과 그것의 메소드가 프로그램의 실행 시간에 결정되게 한다.
Dynamic linking은 프로그램 실행 도중 어떤 object code가 필요할 때 그때 해당 코드를 메모리에 로드하고 linking을 수행한다.
그럼 dynamic linking이 도대체 뭐가 좋을까? 바로 상당한 시간 및 메모리 공간 절약이 가능하다는 것이다. 어떤 라이브러리 전체를 로드하고 linking 하는 것이 아니고 프로그램에서 필요한 일부만을 로드하고 linking하기 때문이다.
Bootstrap loader
일부 컴퓨터에서, 절대 로더 프로그램은 읽기 전용 메모리인 ROM 안에 영원히 상주한다. 어떤 하드웨어 신호가 발생할 때, 기계는 이 ROM 프로그램을 실행하기 시작하기 시작한다.
부츠트랩 로더는 최초의 레코드를 읽고, 이 최초의 레코드는 다른 레코드들을 읽도록 만들며, 차례로 더 많은 레코드들을 읽도록 만든다.
자료 출처
- "System Software: An Introduction to Systems Programming" by Leland L. Beck
- 동국대학교 엄진영 교수님 시스템 소프트웨어와 실습 강의 교안
'computer science > System software || OS' 카테고리의 다른 글
| Operating system (2) (0) | 2022.12.07 |
|---|---|
| Operating system (1) (0) | 2022.11.22 |
| Macro Processors (0) | 2022.11.20 |
| Linkers and Loaders (1) (0) | 2022.11.01 |
Introduction
Absolute Loader
Machine-Dependent Loader Features(Linking Loader)
Machine-Independent Loader Features
Loader Design Options
Linkers and Loaders(1) 과 이어지는 내용이다.
다음 이미지는 어셈블러의 Two-pass process를 나타낸 것이다.
이제 링킹 로더의 자료구조와 알고리즘을 살펴보자. 링킹 로더의 알고리즘은 어셈블러의 2 pass 알고리즘과 상당히 유사하다.
pass 1에서 모든 외부 심볼들에 대해서 주소를 할당하고, pass 2에서는 실제적인 로딩, 재배치 그리고 링킹을 수행한다.
Data Structures
ESTAB(External Symbol Table)
링킹 로더에 대해 필요한 주요 자료구조는 외부 심볼 테이블인 ESTAB이다. 어셈블러 알고리즘 안에서의 SYMTAB과 유사한 이 테이블은, 로드되어진 제어 섹션들의 집합 안에서의 각 외부 기호의 이름과 주소를 저장하기 위해 사용되어진다. 또한 ESTAB은 어떤 제어 섹션 안에서 기호가 정의되어졌는지를 가리킨다. 해쉬 구조가 보통 이 테이블의 구현에 사용된다.
PROGADDR(Program Load Address): 프로그램 로드 주소
링크된 프로그램이 로드되어지는 메모리의 시작 주소이다. 이 값은 운영체제에 의해 로더에게 제공된다.
CSADDR(Control Section Address): 제어 섹션 주소
로더에 의해 현재 스캔되고 있는 제어 섹션에 할당된 시작 주소이다. 이 값은 모든 상대 주소들을 실제 주소들로 변환하기 위해 제어 섹션 내의 모든 상대 주소들에 더해진다.
Algorithm
pass 1 동안에 로더는 오직 제어 섹션들 안에서의 헤더(H)와 정의 레코드(D)에 대해서만 다룬다.
(only Header and Define records are concerned)
링크된 프로그램(PROGADDR)에 대한 시작 로드 주소는 운영 체제로부터 얻어진다.
(get PROGADDR from operating system)
이 주소는 첫 번째 제어 섹션에 대한 시작 주소(CSADDR)가 된다.
(set CSADDR to PROGADDR)
헤더 레코드로부터의 제어 섹션 이름은 CSADDR 값과 함께 ESTAB으로 들어간다.
(enter control section name into ESTAB with value CSADDR)
제어 섹션에 대한 정의 레코드 안에서 나타나는 모든 외부 심볼들은 ESTAB으로 들어간다.
(enter symbol into ESTAB)
정의 레코드 안에서 명시된 값에 CSADDR을 추가함으로써 외부 심볼들의 주소가 얻어진다.
(CSADDR + indicated address)
End 레코드를 만났을 때, 헤더 레코드로부터 저장된 제어 섹션 길이(CSLTH)가 CSADDR로 더해진다.
(add CSLTH to CSADDR {starting address for next control section})
이 계산은 다음 제어 섹션에 대한 시작 주소를 결정해주게 된다.
pass 1의 끝에서, ESTAB은 각각에 할당된 주소와 함께 제어 섹션들 내에서 정의된 모든 외부 기호들을 포함한다.
pass 2는 프로그램의 실제적인 로딩, 재배치와 링킹을 수행한다.
CSADDR는 항상 현재 로드되는 제어 섹션의 실제 시작 주소를 담고 있다.
(set CSADDR to PROGADDR) (set EXECADDR to PROGADDR)
각 텍스트 레코트를 만날 때, 목적 코드는 명시된 메모리의 주소로 이동된다.
(if record type = 'T' then ... move object code ... CSADDR + specified address)
수정 레코드를 만나면, ESTAB 안에서 수정될 심볼의 이름을 찾고 심볼의 값을 더하거나 뺀다.
(if record type = 'M' then ... search ESTAB for modifying symbol name, add or subtract symbol value ... CSADDR + s.a.)
로더에 의해 마지막으로 수행되는 단계는 실행을 시작하기 위해 로드된 프로그램으로 제어를 옮기는 것이다.
각 제어 섹션에 대한 end 레코드는 제어 섹션이 실행되는 첫 번째 명령의 주소를 포함한다.
(jump to location given by EXECADDR {to start execution of loaded program})
# Enhance the Algorithm
참조 번호를 제어 섹션에서 참조되는 각 외부 심볼에 할당하는 방법으로 링킹 로더의 알고리즘을 더 효율적으로 만들 수 있다. 이 참조 번호는 수정 레코드 안에서 심볼 이름 대신에 사용된다. 제어 섹션의 이름은 01로 할당되고, 나머지는 02, 03 ... 차례대로 할당된다.
장점: 제어 섹션의 로딩 동안 같은 심볼에 대해 ESTAB을 중복으로 찾는 것을 막아준다.
Machine-Independent Loader Features
Automatic library search loader options
- 외부 참조를 처리하기 위한 자동 라이브러리 검색: 프로그래머가 표준 서브루틴을 사용할 수 있도록 해준다. 이 루틴들은 링크 동안에 필요로할 때마다 라이브러리에서 자동적으로 추출된다.
- 로딩과 링킹 옵션: 입력의 선택 지정, 외부 참조의 변경 또는 삭제, 외부 참조의 자동적인 처리를 조절하는 기능
Automatic Library Secarch: 자동 라이브러리 탐색
많은 링크 로더들은 로드되는 프로그램에 부프로그램 라이브러리 루틴으로부터 루틴들을 자동적으로 포함시킬 수 있다. 이를 표준 시스템 라이브러리라고 하며 라이브러리들은 제어문 또는 파라미터에 의해 로더에게 지정된다.
프로그래머는 하나 이상의 라이브러리에서 부루틴을 프로그래밍 언어의 일부인 것처럼 사용할 수 있다.
로드되는 프로그램에서 부루틴은 자동적으로 라이브러리로부터 가져오며, 주 프로그램과 링크되고 로드된다.
프로그래머는 원시 프로그램에서 외부 참조로서 부루틴 이름을 지정하는 것 이외의 다른 작업을 할 필요가 없다. 이러한 기능을 자동 라이브러리 호출이라 한다.
Implementation of Automatic Library Search
자동 라이브러리 탐색을 제공하는 링크 로더는 입력 프로그램에서 정의되지 않은 외부 기호를 추적해야만 한다. 각 참조 레코드에서 어떤 기호가 현재 기호 테이블에 없다면, 기호 테이블(ESTAB)에 기입하고, 이 기호가 아직 정의되지 않았음을 표시한다. 나중에 이 기호가 정의되면 기호에 배정된 주소를 채워서 완성한다.
패스 1이 끝난 후에 정의되지 않고 ESTAB에 남아있는 기호는 미해결 외부 참조임을 표시한다. 로더는 이들 기호의 정의를 포함하는 루틴을 위해 지정된 라이브러리를 탐색하고, 이 탐색에서 발견된 부루틴들은 원래의 입력 프로그램의 일부였던 것처럼 처리한다.
라이브러리 탐색 과정은 모든 참조가 해결될 때까지 반복된다. 라이브러리 탐색이 완료된 후에도 해결되지 않은 외부 참조가 있다면 오류로 처리된다.
Discussions of Automatic Library Search
제시된 링킹 로더는 프로그래머가 자신이 만든 루틴을 제공함으로써 라이브러리에 있는 표준 부루틴을 덮어 쓸 수 있도록 한다.
예를 들어, 주프로그램이 SQRT라는 표준 부루틴을 참조한다고 가정하자. 이 이름의 부루틴은 자동적으로 라이브러리 탐색을 통해 포함된다. 다른 종류의 SQRT를 사용하기를 원하는 프로그래머는 이 SQRT를 로더의 입력에 포함시키면 된다.
로더의 패스 1이 끝난 후 SQRT는 이미 정의되어 있으므로, 라이브러리 탐색이 불필요하게 된다.
로더에 의해 탐색되는 라이브러리는 부루틴의 어셈블 또는 컴파일된 형태인 목적 프로그램을 포함하고 있다. 이러한 라이브러리 탐색은 라이브러리에서 목적 프로그램의 정의 레코드를 조사함으로써 가능하지만 비효율적이다. 이름과 각 루틴의 주소를 가리키는 진입점을 제공하는 디렉토리를 탐색하는 것이 더 효율적이다.
Loader Options
사용자는 로더의 표준 처리를 변경할 수 있도록 옵션을 지정할 수 있다. 이 때 특별한 명령어를 사용한다:
독립된 입력 파일일 수도 있고, 본래의 입력 흐름에서 목적 프로그램들 사이에 제어문들이 삽입될 수 있다, 로더 제어문을 원시 프로그램에 포함시킬 수도 있다.
전형적인 로더 선택 사항:
입력으로 원시 프로그램을 선택하는 명령어
- INCLUDE program-name(library-name): 로더가 라이브러리에서 지시한 목적 프로그램을 읽어들이고 기본 로더 입력의 일부인 것처럼 취급하도록 지시한다.
외부 기호나 제어 섹션 전체를 삭제하도록 하는 명령어
- DELETE csect-name: 로드되는 프로그램들 중에서 지정된 제어 섹션을 로더가 삭제하도록 지시한다.
프로그램 내에서 외부 참조를 변경하도록 하는 명령어
- CHANGE name1, name2: 외부 기호 name1을 name2로 변경한다. 목적 프로그램의 어느 위치에 있는지와 상관없다.
라이브러리 루틴을 자동으로 포함하는 명령어
- LIBRARY MYLIB: 탐색할 라이브러리를 지정한다. 사용자 지정 라이브러리는 표준 시스템 라이브러리를 탐색하기 전에 탐색된다.
- NOCALL name: 외부 참조 name이 미 해결된 상태로 남아있게 로더에게 지시한다.
라이브러리 UTLIB에서 READ와 WRITE 제어 섹션을 포함시키고, RDREC, WRREC 제어 섹션을 삭제하도록 로더에게 지시한다. 기호 RDREC에 대한 모든 외부 참조를 기호 READ로 참조하도록 변경하며, WRREC에 대한 모든 외부 참조를 WRITE로 변경하도록 지시한다. 그 결과 원시 프로그램은 READ와 WRITE를 사용하는 것과 같다.
Loader Design Options
Linkage Editors
Dynamic Linking
Bootstrap Loaders
Linkage Editors
링킹 로더(linking loader)는 로드 시간에 모든 링크와 재배치를 수행한다.
링크 편집기(linkage editor)는 로드 시간 이전에 링크를 수행한다.
동적 링킹(dynamic linking)은 실행 시간에 링크를 수행한다.
링킹 로더(Linking Loader)는 자동 라이브러리 검색을 포함하여 모든 링크와 재배치 작업을 수행하고, 이 링크된 프로그램 실행을 위해 직접 메모리로 로드한다.
반면에 링크 편집기(Linkage Editor)는 프로그램의 링크된 버전을 생성하고, 나중에 실행하기 위해 라이브러리나 파일로 출력한다. <즉시 메모리로 로드되지 않는다.> 사용자가 링크된 프로그램을 실행하고자 할 때, 간단한 재배치 로더(one pass)가 프로그램을 메모리로 로드한다. 목적 코드 수정은 단지 프로그램 내의 상대적인 값에 실제 로드 주소를 더해주는 것이다. 링크 편집기는 모든 제어 섹션을 링크된 프로그램의 시작으로부터 상대적으로 재배치한다. <따라서 로드 시에 수정이 필요한 모든 항목은 링크된 프로그램의 시작으로부터 상대적인 값을 갖고 있다.> 이것은 로드가 외부 기호 테이블(ESTAB) 없이 단일 패스에 완료될 수 있다는 것을 의미한다. 결과적으로 링킹 로더를 사용하는 것보다 적은 부담을 준다.
프로그램이 다시 어셈블되지 않고 여러 번 실행된다면, 링크 편집기(linkage editor)의 사용이 더 효율적이다. 외부 참조의 처리와 라이브러리 탐색은 프로그램이 링크 편집되는 때에 단 한번만 수행되기 때문이다.
반면에, 링킹 로더는 프로그램이 실행될 때마다 라이브러리를 탐색하고 외부참조를 결정한다.
때로는 실행될 때마다 거의 매번 다시 어셈블되어야 하는 프로그램이 있다. 프로그램의 개발과 테스트를 주로하는 환경이 그렇다. 또한 프로그램이 매우 드물게 사용되서 라이브러리에 어셈블된 것과 링크된 버전을 저장할 필요가 없는 경우도 있다. 이러한 경우 링크된 프로그램을 저장하고 접근하는 과정이 필요없는 링킹 로더(linking loader)를 사용하는 것이 더 효과적이다.
Dynamic Linking (dynamic loading, load and call)
실행 시간까지 링킹을 연기한다. 서브루틴은 첫 번째로 호출될 때에 프로그램의 나머지에 로드되고 링크된다.
실행중인 프로그램들이 서브루틴이나 라이브러리의 복사본을 공유하게끔 한다.
객체 지향 시스템에서 공유된 오브젝트의 구현과 그것의 메소드가 프로그램의 실행 시간에 결정되게 한다.
Dynamic linking은 프로그램 실행 도중 어떤 object code가 필요할 때 그때 해당 코드를 메모리에 로드하고 linking을 수행한다.
그럼 dynamic linking이 도대체 뭐가 좋을까? 바로 상당한 시간 및 메모리 공간 절약이 가능하다는 것이다. 어떤 라이브러리 전체를 로드하고 linking 하는 것이 아니고 프로그램에서 필요한 일부만을 로드하고 linking하기 때문이다.
Bootstrap loader
일부 컴퓨터에서, 절대 로더 프로그램은 읽기 전용 메모리인 ROM 안에 영원히 상주한다. 어떤 하드웨어 신호가 발생할 때, 기계는 이 ROM 프로그램을 실행하기 시작하기 시작한다.
부츠트랩 로더는 최초의 레코드를 읽고, 이 최초의 레코드는 다른 레코드들을 읽도록 만들며, 차례로 더 많은 레코드들을 읽도록 만든다.
자료 출처
- "System Software: An Introduction to Systems Programming" by Leland L. Beck
- 동국대학교 엄진영 교수님 시스템 소프트웨어와 실습 강의 교안
'computer science > System software || OS' 카테고리의 다른 글
| Operating system (2) (0) | 2022.12.07 |
|---|---|
| Operating system (1) (0) | 2022.11.22 |
| Macro Processors (0) | 2022.11.20 |
| Linkers and Loaders (1) (0) | 2022.11.01 |
