ELF 파일 형식 버전 1.2

+--------------------------------------------------------+
원문서   제목 : Executable and Linking Format (ELF) Specification 1.2
원문서   저자 : Tool Inerface Standards(TIS) 위원회
원문서 작성일 : 1995. 05. 00
문  서 번역일 : 2003. 08. 00
문  서 번역자 : 광주광역쉬에서 세벌쉭
코  멘     트 : 본 번역본은 순전히 개인적인 호기심에서 번역한 것이다.
                조금이라도 의심스러운 해석은 원문서를 참조하기 바란다.
+--------------------------------------------------------+
번역문서 버전 : 00
적절하지 않는 단어선택, if 문에 대한 오역등 많은 오류가 보인다.

번역문서 버전 : 01
수많은 오역 중에 눈에 띠는 몇개를 수정했다. 탈자를 수정했다. 오자를 수정했다. 몇가지 번역 용어를 수정했다.

번역문서 버전 : 02
출력모양을 잡기 위해서 빈 페이지를 삽입했다. 아직 분명하지 않는 번역과 오타들이 보인다.

 
 
  TIS 위원회는 당신에게 당신의 소프트웨어를 TIS에 호환하는 것의로 만들기 위해서 이 규정에서 제공하는 정보를 사용하기위한 비 배타적이고, 세계적이고, 로얄티가 없는 라이선스를 부여한다; 표현되거나 암시적인 다른 어떤 라이선스도 여기서 부여되거나 될것이다.

  TIS 위원회는 이 표준의 사용을 위한 어떤것도 보장하지 않는다.

  TIS 위원회는 모든 표현되고 묵시적인 보장들, 모든 책임, 사용 결과로서 나타나는 것을 포함하고 다른 부수적인 손해들, 이 규정을 사용하고 그것 안에 포함된 정보를 사용하기위한, 어떤 소유권을 위-반하는 책임들을 특별히 포기할것을 선언한다. TIS 위원회는 규정에 나타나는 어떤 에러들에 대해서 어떤 책임을 가정하지 않는다. 그것들안에 포함된 정보를 업데이트하는 책임도 가지지 않는다. TIS 위원회는 알림 없이 언제든지 이 규정을 변경할수 있는 권리를 남겨 놓는다.

  IBM 은 등록된 상표이다. OS/2 는 International Business Machines Corporation 의 상표이다. 인텔 로고는 등록된 상표이다. i386 과 Intel386 은 인텔 상품들을 구별하기위해서 사용되어지는 Intel Corporation 의 등록상표이다. Microsoft, Microsoft C, MS, MS-DOS, Windows, 그리고 XENIX는  Microsoft Corporation 의 등록 상표이다. Phoenix 는 Phoenix Technologies, Ltd 의 등록 상표이다. UNIX는 미국과 다른 나라들에서 X/Open Company Limited 에 의해서 배타적으로 라이선스된 등록 상표이다. 

* 다른 상표들과 이름들은 그들 관련자들의 소유권이다.

 
 
서문 

이 Executable and Linking Format 규정은, 버전 1.2, Tool Inerface Standards(TIS) 위원회의 작업 결과이다. 마이크로 컴퓨터 산업 회원들의 연합은 32비트 인텔 구조 오버레이팅 환경하에서 툴들을 개발하기위한 소트트웨어 인터페이스들의 표준화 작업을 하기위해서 구성되었다. 그러한 인터페이스들은 오브젝트 모듈 포멧들, 실행가능 파일 포멧들, 디버그 기록 정보와 포멧들을 포함한다. 

위원회의 목표는 32비트 오버레이팅 환경에 집중하여 마이크로 컴퓨터 산업을 통해서 소프트웨어 개발 프로세스를 도우는 것이다. 마침내, 위원회는 산업 오퍼레이팅 시스템들을 넘나들수 있는 파일 포멧을 위한 몇개, 32비트 윈도우즈를 위한 몇개의 포멧 규정들을 개발했다. 원래 TIS Portable Formats 규정 버전 1.1에서 집합적으로 제공되었다. 이 규정은 이제 이제 분리되었다. 개별적으로 배포되어진다. 

TIS 위원회 멤버들은 Absoft, Autodesk, Borland International Corporation, IBM Corporation, Intel Corporation, Lahey, Lotus Corporation, MetaWare Corporation, Microtec Research, Microsoft Corporation, Novell Corporation, The Santa Cruz Operation, 그리고 WATCOM International Corporation. PharLap Software Incorporated 의 대표들과 규정을 만드는데 노력을 아끼지 않는 Symantec Corporation 역시 포함한다.  

  TIS 규정들 집합안에있는 다른것과 같이 이 규정은 이미 존재하는것에 기초하고 있으며, TIS 위원회의 목표를 적용하기에 알맞고 증명된 포멧들, 그리고 필요할때, 새로운 것을 발명하기 보다는 존재하는 표준을 확장하는것을 기초로하고 있다.

ELF에 관하여 :  Executable and Linking Format 

Executable and Linking Format 은 유닉스 시스템 연구소(USL)에서 어플리케이션 바이너리 인터페이스(ABI)의 일부분으로 개발되고 출판 발표되었다. TIS 표준 위원회는(TIS)는 다양한 오퍼레이팅 시스템상에서 32비트 인텔 구조 환경상에서 작동하는 이식가능한 오브젝트 파일 포멧처럼 발전된 ELF 표준을 선택했다. 

  ELF 표준은 개발자들에게 멀티 오퍼레이팅 환경을 넘나들어 확장하는 바이너리 인터페이스 정의 셋을 제공함으로서 소프트웨어 개발을 합리적으로 할수 있다. 이것은 다른 인터페이스 이행들의 수를 감소시킨다. 그래서 코드를 재코딩하고 재컴파일하는 필요들을 감소 시킬 것이다.

이 문서에 관하여 

이문서는 32비트 환경 오퍼레이팅 시스템 상에서 오브젝트나 실행가능한 파일들을 만드는 개발자들을 위해서 제공되어진다. 현재 ELF 버전 1.2 문서는 오퍼레이팅 시스템 특성 정보를 인식한다. 이것은 다음 3개의 책으로 분리 되어져 있다.

• 책 1 :  Executable and Linking Format, ELF 라고 불리는 오브젝트 파일 포멧에대해서 설명한다. 이책은 또한 역사적 참조를 설명하는 부록을 포함하고 있다. 프로세서와 오퍼레이팅 시스템을 나열하고 이름들과 단어들을 예약한다.

• 책 2 : Processor Specific (Intel Achitecture), 하드웨어 특성 ELF 정보, 인텔 구조 정보와 같은

• 책 3 : Operating System Specific, 오퍼레이팅 시스템에 의존적인 ELF 정보을 설명한다, 시스템 브이 릴리즈 4 정보 같은. 또한 이 책은 오퍼레이팅 시스템과 프로세서 의존적인 ELF 정보를 설명하는 부록을 포함하고 있다.

Book I:
Executable and Linking Format (ELF)

 
1. Object Files (오브젝트 파일들)

1.1.Introduction (소개)

  이번 장은 ELF(Excutable and Linking Format)이라 불리는 오브젝트 파일 포멧을 설명한다. 오브젝트 파일들의 3가지 타입이 있다.

 재배치가능 파일은 실행가능 파일 이나 공유 오브젝트 파일을 만들기위해서다른 오브젝트 파일들과 함께 링킹을 가능하게하는 코드와 데이타를 가지고 있다.

 실행가능한 파일은 실행하기에 적당한 프로그램을 가지고 있다.

 공유 오브젝트 파일은 두가지 방법으로 링킹하기 적당한 코드와 데이타를 가지고 있다. 

  첫번째, 링크 에디터는 또다른 다른 오브젝트 파일을 만들기위해서 다른 재배치가능 하고 공유 오브젝트 파일들을 처리한다. 

  두번째, 동적 링커는 프로세스 이미지를 만들기 위해서 실행가능 파일 과 다른 공유 오브젝트들을 결합한다. 

어셈블러와 링크에디터에 의해서 만들어진 오브젝트 파일들은 프로세서 상에서 바로 실행할수 있는 프로그램의 이진 표현이다. 다륵 특정 머신들을 요구하는 프로그램들은 배제되어진다.

  소개글이 끝난후, 이 장은 파일 포멧에 논점을 맞출것이다. 또한 파일 포멧이 어떻게 프로그램을 생성하는데 관여하는지에 관한 것이다. 2장도 오브젝트 파일에 관한 부분을 설명할것이다. 프로그램을 실행하기 위해서 필요한 정보들에 집중할 것이다.

1.1.1. File Format (파일 포멧)

  오브젝트 파일들은 프로그램 링킹(프로그램 만들때) 와 프로그램 실행(프로그램 운영때)에 참여한다. 편리하고 효과적 수행을 위해서, 오브젝트 파일 포멧은 파일 내용에 관해서 동등한 관점을 제공한다. 이들 행위들의   다른 필요들을 반영한다. 그림 1-1은 오브젝트 파일의 조직을 보여준다.

그림 1-1.  Object File Format

Linking View  Execution View
ELF Header  ELF Header
Program Header Table
optional  Program Header Table
Section 1  Segment 1
…… 
Section n  Segment 2
…… 
……  ……
Section Header Table  Section Header Table
optional

  ELF 헤더는 시작부분에 존재하고 파일의 조직도를 설명하는 구조를 가지고 있다. 섹션은 링킹 관점을 위해서 오브젝트 파일 정보의 많은 부분을 가지고 있다: 명령들, 데이타, 심볼 테이블, 재배치 정보 등등. 특별 섹션들의 성명은 이 장의 후반부에 나타난다.  2장은 세그먼트들과 파일의 프로그램 실행 관점에 대해서 설명한다.
  만일 존재한다면, 프로그램 허데 테이블은 시스템에게 프로세스 이미지를 어떻게 만들지에 관한 것들을 제공한다. 프로세스 이미지(프로그램을 실행하는것)을 만들기위해서 사용되어지는 파일들은 프로그램 헤더 페이블을 가지고 있어야만한다; 재배치가능 파일들은 그럴필요가 없다. 섹션 헤더 테이블은 파일의 섹션들을 설명하는 정보를 포함하고 있다. 모든 섹션은 테이블안에 엔트리를 가지고 있다. 각 엔트리는 섹션 에름, 섹션 크기 등등의 정보를 부여한다. 링킹동안에 사용되어지는 파일들은 섹션 헤더 테이블을 가지고 있어야만 한다; 다른 오브젝트 파일들은 필수 사항이 아니다.
주의. 비록 그림이 ELF 헤더 다음에 바로 프로그램 헤더를 보여 주고, 섹션들이 뒤따라오는 섹션 헤더 테이블을 보여 준다고 할지라도, 실제 파일들은 다를수 있다. 더욱이, 섹션들과 세그먼트들은 특별한 순서를 가지고 있지 않다. 단지 ELF 헤더만이 파일 내에서 고정된 위치를 가지고 있다.
 
1.1.2. Data Representation (데이타 표현)

  여기에 묘사되어진 것 처럼, 오브젝트 파일 포멧은 8 비트, 32비트 구조들의 다양 프로세서들을 지원한다. 그럼에도 불구하고, 더큰(또는 더작은) 구조들도 확장할 것이다. 그래서, 오브젝트 파일들은 기계 의존적인 포멧의 몇몇 제어 데이터를 표현한다. 그래서 오브젝트 파일을 식별 할수 있도록 하고 일반적인 방법으로 오브젝트 파일을 해석할수 있도록 한다. 오브젝트 파일 내부에 있는 데이터는 파일이 만들어진 머신에 관계없이 해당 프로세서의 인코딩 방식을 사용한다. 

그림 1-2.  32-Bit Data Types

Name Size Alignment Purpose
Elf32_Addr 4 4 Unsigned program address
Elf32_Half 2 2 Unsigned medium integer
Elf32_Off 4 4 Unsigned file offset
Elf32_Sword 4 4 Signed large integer
Elf32_Word 4 4 Unsigned large integer
unsigned char 1 1 Unsigned small integer

  오브젝트 파일 포멧이 정의한 모든 데이타 구조체들은 일반적인 크기를 따르고 관련 클래스들을 위해서 경계를 맞춘다. 만일 필요하다면, 데이타 구조체들은 4바이트 오브젝트들을 위해서 4바이트 경계 맞추기(얼라인먼트)를 확인하기위해, 4의 배수 사이즈등으로 구조체를 강요하기위해 명확한 덧붙임값을 가진다. 데이타는 파일의 시작으로부터 알맞는 경계 맟추기(얼라인먼트)를 가진다. 그래서, 예를 들자면, Elf32_Addr 멤버를 가지는 구조체는 파일 내부에서 4바이트 경계상에 위치하게 될것이다.
  호환성과 관련된 이유들 때문에, ELF 는 비트 필드들을 사용하지 않는다.

 
1.1.3. Character Representations (문자 표현들)

이 단원은 기본 ELF 문자 표현과 시스템들 사이에서 호환이 가능하도록 하기위한 외부 파일들을 위해 사용되어진 표준 문자 집합들을 정의한다. 몇몇 외부 파일 포멧들은 문자들로 제어 정보들을 표현한다. 이들 단일 바이트 문자들은 7비트 ASCII  문자 집합을 사용한다. 즉, ELF 인터페이스 문서가 ‘/’ 나 ‘\n’ 와 같은 문자 상수들을 언급할 때, 그것들의 숫자 값들은 7비트 아스키 가이드라인을 따른다.
  앞의 문자 상수들은, 단일 바이트 값들로 47 과 10 이다. 0 부터 127 범위 바깥의 문자 값들은 문자 인코딩 방법에 따라서 하나나 그이상의 바이트를 차지 할 수 있다.  어프리케이션들은 그들 자신 문자 집합들을 제어 할 수 있다.알맞은 다른 언어들을 위해서 다른 문자 확장들을 사용한다. 비록 TIS 를 따르는 것(TIS )이 문자 집합들을 제한하지 않는다고 할지라도, 그들은 몇가지 간단한 가이드라인들을 따라야만 한다.
 0 에서 127 사이에 있는 문자 값들은 7비트 아스키 코드에 일치하여야 한다. 즉, 127이상의 인코딩 값을 갖는 문자 집합들은 서브셋으로서 7비트 아스키를 포함해야만한다.
 127 이상의 값을 가지고 인코딩되는 멀티 바이트 문자는0 에서 127 범위 바깥의 값들을 가지는 바이트들만을 포함해야 한다. 즉, 문자당 1바이트 이상을 사용하는 문자 셋은 멀티바이트 안에 7비트 아스키 문자를 닮은 1바이트를 아스키 문자가 아닌 문자에 내포하지 말아야 한다.
 멀티바이트 문자들은 스스로 식별 가능해야만한다. 예를들면, 그것은 어떤 멀티바이트 문자를 문자들의 해석들을 변경함이 없이 멀티바이트 문자들의 쌍들 사이에 삽입되어지도록 허락한다.
  이 경고들을 특별히 다중언어 어플리케이션들과 관련이 있다.

주의. 특정 프로세서 범우를 가지를 ELF 상수들을 위해서 이름붙이기 규정들이 있다. 프로세서 특성 확장들을 위해서 DT_, DT_ 같은 이름들은 프로세서의 이름을 가지고 있다: 예를 들면, DT_M32_SPECIAL. 그러나 이 규정을 관례를 사용하지 않는 이미 존재하는 프로세서 확장들은 지원 되어 질 것이다.

Pre-existing Extensions(이미 존재하는 확장들)
DT_JMP_REL

 
1.2. ELF Header (ELF 헤더)

  몇몇 오브젝트 파일 제어 구조체들은 성장 할 수 있다(크기를 달리 할 수 있다). 왜냐하면 ELF 헤더는 그들의 실제 크기들을 포함하고 있기 때문이다. 만일 오브젝트 파일 포멧에 변화가 있다면, 프로그램은 기대하고 있는것보다 크거나 작은 제어 구조체들과 충돌할 지도 모른다. 그래서, 프로그램들은 부수적인 정보를 무시한다. 잘못된 정보를 처리하는 것은 내용에 달려있다. 확장들이 정의되어 질 때 또는 확장들이 정의되어진다면 그것들에 대한 처리를 확정한다.

그림 1-3.  ELF Header

#define EI_NIDENT 16
typedef struct {
unsigned char  e_ident[EI_NIDENT];
Elf32_Half  e_type;
Elf32_Half  e_machine;
Elf32_Word  e_version;
Elf32_Addr  e_entry;
Elf32_Off   e_phoff;
Elf32_Off   e_shoff;
Elf32_Word  e_flags;
Elf32_Half  e_ehsize;
Elf32_Half  e_phentsize;
Elf32_Half  e_phnum;
Elf32_Half  e_shentsize;
Elf32_Half  e_shnum;
Elf32_Half  e_shstrndx;
} Elf32_Ehdr;

e_ident    초기 바이트들은 오브젝트 파일에 대한 파일을 표시한다. 파일의 내용을 디코드하고 번역하기위한 머신 독립적인 데이타를 제공한다. 완벽한 설명은 아래에 있다. "ELF 식별" 부분을 참조하라.

e_type    이 멤버는 오브젝트 파일의 타입을 식별한다.

Name Value Meaning
ET_NONE
ET_REL
ET_EXEC
ET_DYN
ET_CORE
ET_LOPROC
ET_HIPROC 0
1
2
3
4
0xff00
0xffff No file type
Relocatable file
Executable file
Shared object file
Core file
Processor-specific
Processor-specific

  비록 코어 파일 내용들이 지정되어 있지 않도고 할지라도, ET_CORE 타입은 파일의 타입을 표시하기 위해서 예약되어져 있다. ET_LOPROC 부터 ET_HIPROC 까지의 값(각 값을 포함해서)들은 프로세서 특성 의미들을 위해서 예약되어져 있다. 다른 값들도 예약되어져 있고 필요하다면 새로운 오브젝트 파일 타입들을 위해서 할당되어 질 것이다.
e_machine  이 멤버의 값은 개별적인 파일들을 위해서 요구되어지는 구조(architecture)를 지정한다.

Name Value Meaning
ET_NONE
EM_M32
EM_SPARC
EM_386
EM_68K
EM_88K
EM_860
EM_MIPS
EM_MIPS_RS4_BE
RESERVED 0
1
2
3
4
5
7
8
10
11-16 No machine
AT&T WE 32100
SPARC
Intel Architecture
Motorola 68000
Motorola 88000
Intel 80860
MIPS RS3000 Big-Endian
MIPS RS4000 Big-Endian
Reserved for future use

  다른 값들은 예약되어져 있고 필요하다면 새로운 머신들을 위해서 할당되어질 것이다.  프로세서 특성 ELF 이름들은 그것들 구별하기 위해서 머신 이름을 사용한다, 예를 들자면, 아래에 언급되어진 플래그들은 접두사 EF_를 사용한다; EM_XYZ 머신를 위해 이름 붙여진 WIDGET 플래그는  EF_XYX_WIDGET 로 명명될 것이다.
e_version      이 멤버는 오브젝트 파일 버전을 식별한다.

Name Value Meaning
EV_NONE
EV_CURRENT 0
1 Invalid versionn
Current version
값 1은 원본 파일 포멧을 나타낸다. 확장들은 더 큰 수자들로 새로운 버전들을 만들 것이다. EV_CURRENT의 값은, 위에 1처럼 주어진 것을 통해서, 현재 버전 번호를 반영하기 위해서 필요할때 변경한다.
e_entry   이 멤버는 시스템이 첫번째로 제어를 변경하는 가상 주소를 부여한다. 그래서 프로세스를 시작한다. 만일 파일이 관련된 진입점을 가지고 있지 않다면, 이 멤버는 0 을 가지고 있다.
e_phoff   이 멤버는 프로그램 헤더 테이블의 바이트 단위 파일 옵셋을 가지고 있다. 만일 파일이 프로그램 헤더 테이블을 가지고 있지 않다면, 이 멤버는 0을 가지고 있다.
e_shoff   이 멤버는 섹션 헤더 테이블의 바이트 단위 파일 옵셋을 가지고 있다. 만일 파일이 섹션 헤더 테이블을 가지고 있지 않다면 이 멤버는 0을 가지고 있다.
e_flags   이 멤버는 파일과 관련이 있는 프로세서 특성 플래그들을 가지고 있다. 플래그 이름들은 EF_machine_flag 형태로 취해진다.
e_ehsize   이 멤버는 바이트 단위 ELF 헤더의 크기를 가지고 있다.
e_phentsize 이 멤버는 파일의 프로그램 헤더 테이블 내부에 있는 한 엔트리의 바이트 단위 크기를 가지고 있다. 모든 엔트리들은 동일한 사이즈를 가진다.
e_phnum   이 멤버는 프로그램 헤더 테이블내부에 가지고 있는 엔트리들의 수자를 가진다. 그래서 e_phentsize 와 e_phnum 곱은 바이트 단위 테이블의 크기로 주어진다. 만일 파일이 프로그램 헤더 테이블을 가지고 있지 않다면, e_phnum 은 0을 가진다.
e_shentsize 이 멤버는 섹션 헤더의 바이트 단위 크기를 가진다. 섹션 헤더는 섹션 헤더 테이블 내부에 있는 하나의 엔트리이다; 모든 엔트리들은 동일한 크기를 가진다.
e_shnum   이 멤버는 섹션 헤더 테이블 안에 있는 엔트리들의 수자를 가진다. 그래서 e_shentsize 와 e_shnum의 곱은 섹션 헤더 테이블의 바이트 단위 크기이다. 만일 파일이 섹션 헤더 테이블 가지지 않는다면, e_shnum은 0을 가지고 있다.
e_shstrndx  이 멤버는 섹션 이름 문자열 테이블과 관련 있는 엔트리의 섹션 헤더 테이블 인텍스를 가진다. 만일 파일이 섹션 이름 스트링 테이블 가지지 않는다면, 이 멤버는 SHN_UNDEF 값을 가진다. "섹션", "문자열 테이블" 을 참조하라.

 
1.2.1. ELF Identification (ELF 식별)

  위에 언급되어진 것과 같이, ELF 는 여러가지의 프로세서들, 여러가지의 데이타 인코딩방법들, 여러가지의 머신들의 종류들을 지원하기 위해서 오브젝트 파일 구조를 제공한다. 이 오브젝트 파일 패밀리를 지원하기 위해서, 파일의 초기 바이트들은 파일을 어떻게 해석 할 것인지, 조사를 통해서 프로세서에 독립적인지, 파일의 내용들에 대해서 독립적인 지를 지정한다.
  ELF 헤더(그리고 오브젝트 파일)의 초기 바이트들은 e_ident 멤버와 일치한다.

그림 1-4.  e_ident[] Identification Indexes

Name Value Purpose
EI_MAG0
EI_MAG1
EI_MAG2
EI_MAG3
EI_CLASS
EI_DATA
EI_VERSION
EI_PAD
EI_NIDENT 0
1
2
3
4
5
6
7
16 File identification
File identification
File identification
File identification
File class
Data encoding
File version
Start of padding bytes
Size of e_ident[]

  이들 인덱스들은 뒤따라오는 값들을 가지고 바이트들에 접근한다.
  EI_MAG0 부터  EI_MAG3  파일의 첫번째 4바이트는 "매직 넘버"을 가지고 있다. ELF 오브젝트 파일에 대한 파일을 식별하기 위해서

Name Value Meaning
ELFMAG0  0x7f  e_ident[EI_MAG0]
ELFMAG1  ’E’ e_ident[EI_MAG1]
ELFMAG2  ’L’ e_ident[EI_MAG2]
ELFMAG3  ’F’ e_ident[EI_MAG3] 

  EI_CLASS 다음 바이트는, e_ident[EI_CLASS], 파일의 종류와 능력을 식별한다.

Name Value Meaning
ELFCLASSNONE  0  Invalid class
ELFCLASS32  1  32-bit objects
ELFCLASS64  2  64-bit ob cts
  파일 포멧은 가장 작은 메신 상에서 가장 큰 머신의 사이즈를 부과함이 없이 다양한 사이즈의 머신들 사이에서 이식가능하도록 설계되어져 있다. ELFCLASS32 종류(부류)는 파일들과 4 기가바이트 까지의 가상 주소 공간을가지는 머신들을 지원한다; 이것은 위에서 정의되어진 기본적인 타입이다.
  ELFCLASS64 종류는 완벽하지는 않지만 64비트 구조들을 언급한다. 이것들의 외양은 여기에서 오브젝트 파일이 어떻게 변하는지에 대해 보여준다. 다른 종류들은 필요하다면 다른 기본 타입들과 오브젝트 파일 데이타를 위한 사이즐과 함께 정의되어질것이다.
EI_DATA   e_ident[EI_DATA] 바이트는 오브젝트 파일안에있는 프로세서 특성을 갖는 데이타 인코딩을 지정한다. 따라오는 인코딩 방법들이 현재 정의되어진다.

Name Value Meaning
ELFDATANONE  0  Invalid data encoding
ELFDATA2LSB  1  See below
ELFDATA2MSB  2  See below 

  인코딩에 관한 많은 정보들이 아래에 있다. 다른 값들은 예약되어져 있다. 필요하다면 새로운 인코딩 방법들이 할당되어 질 것이다.
EI_VERSION   e_ident[EI_VERSION] 바이트는 ELF 헤더 버전 번호를 지정한다. 현재, 이 값은 e_version 을 위해 위에 설명되어진것 처럼 EV_CURRENT 이어야만한다.
EI_PAD   이 값은 e_ident 내부에서 사용되어지지 않는 바이트들의 시작을 표시한다. 이들 바이트들은 예약되어져 있고 0 값을 가진다; 오브젝트 파일들을 읽는 프로그램은 그것들을 무시해야한다. 만일 현재 사용되어지지 않는 바이트들에 앞으로 의미가 부여된다면 EI_PAD 의 값은 변할 것이다.
  파일의 데이타 인코딩은 파일안에 있는 기본 오브젝트들을 어떻게 해석할것인가를 지정한다. 위에 설명되어진것과 같이, ELFCLASS32 파일들은 1, 2, 4바이트를 차지하는 오브젝트들을 사용한다. 정의되어진 인코딩방법들 하에서, 오브젝트들은 아래에 보여주는 것과같이 표현되어진다. 바이트 번호들은 위쪽에 왼쪽 코너에 표시한다. ELFDATA2LSD 인코딩 방법은 최하위 바이트가 최하위 메모리 주소를 차지하는 2의 보수 값들을 표시한다.
그림 1-5.  Data Encoding ELFDATA2LSB

0x01 0
01

0x0102 0
02 1
01

 
0x01020304 0
04 1
03 2
02 3
01

  ELFDATA1MSB 인코딩 방법은 최상위 바이트가 최하위 주소를 차지하는 2의 보수 값들을 표시한다.
그림 1-6.  Data Encoding ELFDATA2MSB

0x01 0
01

0x0102 0
01 1
02

 
0x01020304 0
01 1
02 2
03 3
04

 
1.3. Sections (섹션들)
오브젝트 파일의 섹션 헤더 테이블은 파일의 섹션들 모두를 한 위치에 놓는다. 섹션 헤더 테이블은 아래에 설명되어진것과 같이 Elf32_Shdr 구조체의 배열이다. 섹션 헤더 테이블 인덱스는 이들 배열 내부에대한 번호이다.
ELF 헤더의 e_shoff 멤버는 섹션 헤더 테이블에 대한 파일의 시작부로 부터의 바이트 옵셋값을 부여한다; e_shnum 은 섹션 헤더 테이블이 얼마나 많은 에트리를 포함하고 있는지를 말하고 있다; e_shentsize 는 각 엔트리의 바이트 단위 값을 가지고 있다.
  어떤 섹션 헤더 테이블 인덱스들은 예약되어져 있다; 오브젝트 파일은 이러한 특별한 인덱스들을 위해서 섹션들을 가지고 있지 않다.
그림 1-7.  Special Section Indexes

Name Value
SHN_UNDEF  0
SHN_LORESERVE  0xff00
SHN_LOPROC  0xff00
SHN_HIPROC  0xff1f
SHN_ABS  0xfff1
SHN_COMMON  0xfff2
SHN_HIRESERVE  0xffff 

SHN_UNDEF   이 값은 정의되어지지 않고, 잘못되고, 부적절하고, 또는 다른 의미없는 섹션 참조를 표시한다. 예를들면, 섹션 넘버 SHN_UNDEF 에 관련이 있는 심볼 "defined"는 정의되어있지 않는 심볼이다.
주의. 비록 인덱스 0이 정의되어지지 않는 값처럼 예약되어져 있다고 할지라도, 섹션 헤더 테이블은 인덱스 0을 위해서 엔트리를 포함한다. 즉, 만일 ELF 헤더의 e_shnum 수자가 파일이 섹션 헤더 테이블 안에 6개의 엔트리를 가지고 있다고 말한다면, 그것들은 인덱스 0 부터 5까지를 가지고 있다. 초기 엔트리의 내용은 이 단원의 후반부에 지정되어진다.
SHN_LORESERVE   이 값은 예약된 인덱스들 범위의 아래쪽 경계를 지정한다.
SHN_LOPROC ~
SHN_HIPROC   이 범위에 포함되어진 값들은 프로세서 특성 의미들을 위해서 예야되어져 있다.
SHN_ABS    이 값은 일치하는 참조를 위한 절대 값들을 지정한다. 예를들면, 섹션 수자 SHN_ABS 와 관련되어 정의되어진 심볼들은 절대 값들을 가지다. 재배치에 영향을 받지 않는다.
SHN_COMMON    이 섹션과 관련하여 정의되어진 심볼들은 FORTRAN COMMAN 이나 할당되어지지 않은 C 외부 변수들 처럼 일반적인 심볼들이다.
SHN_HIRESERVE   이 값은 예약되어진 인덱스들에대한 범위의 위쪽 경계를 지정한다. 시스템은 SHN_LOReserve 부터 SHN_HIRESERVE 사이의 익덱스들을(경계값 포함하여) 예약한다; 값들은 섹션 헤더 테이블을 참조하지 않는다. 즉, 섹션 헤더 테이블은 예약되어진 인덱스들을위해서 엔트리들을 포함하지 않는다.
  섹션들은 오브젝트 파일안에 ELF 헤더, 프로그램 헤더 테이블, 섹션 헤더 테이블을 제외한 모든 정보를 포함한다. 게다가, 오브젝트 파일의 섹션들은 몇가지 조건들을 만족한다.
 오브젝트 파일 안에 있는 모든 섹션은 그것을 묘사하는 정확하게 한개의 섹션 헤더를 가진다. 섹션 헤더들은 섹션을 가지지 않는 섹션 헤더들이 존재 할 수 있다.
 각 섹션은 파일안에 바이트들의 연속적인 배치를 차지하고 있다.
 파일 안에 있는 섹션들은 겹쳐지지 않는다. 파일 안에 어떤 바이트들도 한 섹션 이사에 위치해 있을 수 없다.
 오브젝트 파일은 활동하지 않는 공간을 가질 수 일다. 여러가지 헤더들과 섹션들은 오브젝트 파일 안에 있는 모든 바이트들을 표시 할 수는 없다. 활동하지 않는 데이타의 내용은 지정되어지지 않는다.
  섹션 헤더는 다음의 구조체를 가지고 있다.
그림 1-8.  Section Header

typedef struct {
Elf32_Word  sh_name;
Elf32_Word  sh_type;
Elf32_Word  sh_flags;
Elf32_Addr  sh_addr;
Elf32_Off  sh_offset;
Elf32_Word  sh_size;
Elf32_Word  sh_link;
Elf32_Word  sh_info;
Elf32_Word  sh_addralign;
Elf32_Word  sh_entsize;
} Elf32_Shdr;

sh_name   이 멤버는 섹션의 이름을 지정한다. 그것의 값은 섹션 스트링 테이블 섹션 내부에대한 인덱스이다.[아래"스트링 테이블" 항목참조] 널로 종료 되어지는 문자열의 위치를 부여한다.
sh_type   이 멤버는 섹션의 내용과 의미를 표시하는 값을 가진다. 섹션 타입과 그것에 대한 설명은 아래에 설명되어 있다.
sh_flags   섹션들은 다양한 특성들을 설명하는 1비트 플래그들을 지원한다. 프래그는 아래에 설명되어져 있다.
sh_addr   만일 섹션이 프로세스의 메모리 이미지 안에 나타날 것이라면, 이 멤버는 섹션의 첫번째 바이트가 위치해야할 주소를 부여한다. 그렇지 않으면 이 멤버는 0 이다.
sh_offset   이 멤버의 값은 파일의 시작으로부터 섹션에 대한 첫번째 바이트 까지의 바이트 옵셋이다. 어떤 섹션 타입, 아래에 설명된 SHT_NOBITS,은 파일 안에서 공간을 차지 하지 않는다. 그것의 sh_offset 멤버는 파일 안에 개념적으로 위치해 있다.
sh_size   이 멤버는 섹션의 바이트 단위 크기를 부여한다. 만일 섹션 타입이 SHT_NOBITS 이라면, 섹션은 파일안에 sh_size 바이트들을 차지한다. SHT_NOBITS 타입의 섹션은 0이 아닌 크기를 가지고 있을 수 있다. 하지만 그것은 파일 안에서 공간을 차지 하지 않는다.
sh_link   이 멤버는 섹션 타입에 따라서 해석이 달라지는 섹션 헤더 테이블 인덱스 링크를 가진다. 아래의 테이블은 값들을 설명한다.
sh_info   이 멤버는 섹션 타입에 따라서 해석이 달라지는 부수적인 정보를 가진다. 아래 테이블은 값들을 설명한다.
sh_addralign  몇몇 섹션들은 주소 경계 맟추기(얼라인먼트)를 강제한다. 예를 들면, 만일 섹션이 더블워드 값을 가지고 있다면, 시스템은 전체 섹션을 위한 더블워드 경계 맟추기를 확인해야한다. 즉, sh_addr의 값은 sh_addralign의 값으로 나누어서 나머지가 0에 일치 해야만 한다.(That is, the value of sh_addr must be congruent to 0, modulo the value of sh_addralign.). 현재, 단지 0 과 2의 누승배의 값만이 허락되어진다. 값 0 과 1은 섹션이 얼라인먼트를 강제 하지 않는다는 것을 의미한다.
sh_entsize   몇몇 섹션들은 심볼 테이블 처럼 고정된 크기 엔트리의 테이블을 가지고 있다. 그러한 섹션들을 위해서, 이 멤버는 각 엔트리의 바이트 단위 크기를 부여한다. 만일 섹션이 고정된 사이즈 엔트리들의 테이블 가지고 있지 않다면, 멤버는 0을 가지고 있다.

 
  섹션 헤더의 sh_type 멤버는 섹션의 의미를 지정한다.
그림 1-9.  Section Types, sh_type

Name Value
SHT_PROGBITS  1
SHT_SYMTAB  2
SHT_STRTAB  3
SHT_RELA  4
SHT_HASH  5
SHT_DYNAMIC  6
SHT_NOTE  7
SHT_NOBITS  8
SHT_REL  9
SHT_SHLIB  10
SHT_DYNSYM  11
SHT_LOPROC  0x70000000
SHT_HIPROC  0x7fffffff
SHT_LOUSER  0x80000000
SHT_HIUSER  0xffffffff 

SHT_NULL    이 값은 활동하지 않는 것으로 섹션 헤더를 표시한다; 그것은 관련된 섹션을 가지지 않는다. 이 섹션의 다른 멤버는 정의되어지지 않는 값들을 가진다.
SHT_PROGBITS   섹션은 프로그램에 의해서 정의되어진 정보를 가진다.  포멧과 의미는 단지 그 프로그램에 의해서만 결정되어진다.
SHT_SYMTAB 과
SHT_DYNSYM   이들 섹션들은 심볼 테이블을 가진다.
SHT_STRTAB     섹션은 스트링 테이블을 가진다.
SHT_RELA    섹션은 오브젝트 파일들의 32비트 종류를 위한 Elf32_Rela 타입과 같은 명확한 가수(addend)와 함께 재배치 엔트리들을 가진다. 오브젝트 파일은 여러개의 재배치 섹션을 가질 수 있다. 자세한 설명은 아래 "재배치" 단원에 있다.
SHT_HASH    섹션은 심볼 해쉬 테이블 가진다.
SHT_DYNAMIC   섹션은 동적 링킹에관한 정보를 가진다.
SHT_NOTE    이 섹션은 여러가지 방법으로 파일을 표시하는 정보를 가지고 있다.
SHT_NOBITS    이 타입의 섹션은 파일 안에서 공간을 차지 하지는 않지만 SHT_PROGBITS 와 비슷하다. 비록 이 섹션은 바이트들을 포함하지 않지만, sh_offset 멤버는 개념적 파일 옵셋을 포함하고 있다.
SHT_REL    섹셕은 오브젝트 파일들의 32비트 종류를 위한 Elf_Rel 과 같은 명확한 가수(addend) 없이 재배치 엔트리들을 가진다. 오브젝트 파일은 여러개의 재배치 섹션을 가질 수 있다. 아래의 "재배치" 단원을 참조하라.
SHT_SHLIB    이 세션 타입은 예약되어져 있지만 정의되어있지 않는 의미를 가진다.
SHT_LOPROC ~
SHT_HIPROC   이 범위를 포함하는 값들은 프로세서 특성 의미로 예약되어져 있다.
SHT_LOUSER    이 값은 어플리케이션 프로그램들을 위해 예약되어진 인덱스들의 범위의 하위 경계값을 지정한다.
SHT_HIUSER    이 값은 어플리케이션 프로그램들을 위해 예약되어진 인덱스 범위의 상위 경계 값을 지정한다. SHT_LOUSER 과 SHT_HIUSER 사이의 섹션 타입들은 현재 나 미래에 시스템 에서 정의되어진 섹션 타입들과 충돌 함이 없이 어플리키에션에 의해서 사용되어질수 있다.
  다른 섹션 타입 값들은 예약되어져 일다. 앞에 언급 되어진 것 처럼, 인덱스 0(SHN_UNDEF)을 위한 섹션 헤더는 존재하지만, 인덱스는 정의되어지지 않는 섹션 참조들을 표시한다. 이 엔트리는 다음의 값을 가지고 있다.
그림 1-10.  Section Header Table Entry: Index 0

Name Value Note
sh_name  0  No name
sh_type  SHT_NULL  Inactive
sh_flags  0  No flags
sh_addr  0  No address
sh_offset  0  No file offset
sh_size  0  No size
sh_link  SHN_UNDEF  No link information
sh_info  0  No auxiliary information
sh_addralign  0  No alignment
sh_entsize  0  No entries 

  섹션 헤더의 sh_flags 멤버는 섹션의 특성을 설명하는 1비트 플래그들을 가지고 있다. 정의되어진 값들은 아래에 나타나있다. 다른 값들은 예약되어져 있다.
그림 1-11.  Section Attribute Flags, sh_flags

Name Value
SHF_WRITE 0x1
SHF_ALLOC  0x2
SHF_EXECINSTR  0x4
SHF_MASKPROC  0xf0000000 

  만일 플래그 비트가 sh_flags 안에 셋 되어져 있다면, 특성은 섹션을 위해서 "on" 상태이다. 그렇지 않으면 특성은 "off" 상태이거나 적용되어지지 않는다. 정의되어지지 않은 특성들은 0으로 셋되어진다.
SHF_WRITE    섹션은 프로세스 실행동안에 기록되어질수 있는 데이타를 포함하고 있다.
SHF_ALLOC    섹션은 프로세스 실행 동안에 메모리를 차지한다. 몇몇 제어 섹션은 오브젝트 파일의 메모리 이미지 안에 위치해 있지 않는다; 이 특성은 그러한 섹션들을 위해서 off 이다.
SHF_EXECINSTR   섹션은 실행가능한 머신 명령들을 포함하고 있다.
SHF_MASKPROC   이 마스크에 포함되어진 모든 비트들은 프로세서 특성 의미를 위해 예약되어져 있다.
  섹션 헤더내에 있는 두 멤버들은, sh_link 와 sh_info, 섹션 타입에 의존적인 특별한 정보를 가지고 있다.
그림 1-12.  sh_link and sh_info Interpretation

sh_type sh_link sh_info
SHT_DYNAMIC  그 섹션안의 엔트리들에 의해서   
 사용되어진 스트링 테이블에 대한 0
 섹션 헤더 인덱스이다.
SHT_HASH  해쉬 테이블이 적용하기위한  
 심볼 테이블에 대한
섹션 헤더 인덱스이다.  0
SHT_REL  관련된 심볼 테이블에 대한 재배치가 적용될 섹션에대한
SHT_RELA  섹션 헤더 인덱스이다. 섹션 헤더 인덱스이다.
SHT_SYMTAB  이 정보는 오퍼레이팅 시스템 이 정보는 오퍼레이팅
SHT_DYNSYM  특성이다. 시스템 특성이다.
other  SHN_UNDEF  0
 
1.3.1. Special Sections (특수 섹션들)
  ELF 안에는 여러가지 종류의 섹션이 미리 정의되어져 있다. 그것들은 프로그램 정보와 제어 정보를 가지고 있다. 이러한 섹션들은 오퍼레이팅 시스템에의해서 사용되어진다. 다른 오퍼레이팅 시스템들을 위해서 다른 타입들과 특성들을 가지고 있다.
  실행가능한 파일들은 링킹 처리를 통해서 개별적인 오브젝트 파일들과 라이브러리들로부터 만들어진다. 링커는 다른 오브젝트 파일들 사이에서 참조들(서브루틴들과 데이터 참조들을 포함해서)을 해결하고, 오브젝트 파일들 안에서 절대 참조들을 조정하고, 명령들을 재배치한다. 2장에 설명되어진 프로세스 링킹 과 로딩은 오브젝트 파일들내에서 정의되어진 정보를 요구한다. 이 정보를 .dynamic 같은 특정 섹션에 저장한다.
  각 오퍼레이팅 시스템은 두가지 형태의 링킹 모델들의 셋을 지원한다:
정적인 형태    오브젝트 파일들, 시스템 라이브러들,  라이브러리 문서들의 셋은 정적으로 결합되어지고, 참조를 해결하고, 그 자체이 완벽하게 포함된 실행 파일을 만든다.
동적인 형태    오브젝트 파일들, 라이브러리들, 시스템 공유 리소스, 다른 공유 라이브러들의 셋은 실행가능 파일을 만들기 위해서 함께 연결(link)되어진다. 이 실행가능 파일이 로드되어질 때, 다른 공유 리소스들 과 동적 라이브러리들은 프로그램을 성공적으로 실행시키기위해서 유용한(available)형태로 있어야 한다.
  실행시에 동적 링키드 실행가능 파일을 위해 참조들을 해결하는데 사용되어진 일반적인 방법은 오퍼레이팅 시스템에의해 사용되어진 링키지 모델안에서 설명되어진다. 이 링키지 모델의 실제적인 수행은 프로세서 특성 요소들을 포함할 것이다.
  .debug 와 .line 같은 디버깅을 지원하는 섹션들이 있다. 프로그램 제어를 지원하는 .bss, .data, .data1, .rodata, .rodata1 같은 섹션들이 있다.
그림 1-13.  Special Sections

Name Type Attributes
.comment  SHT_PROGBITS  none
.data  SHT_PROGBITS  SHF_ALLOC + SHF_WRITE
.data1  SHT_PROGBITS  SHF_ALLOC + SHF_WRITE
.debug  SHT_PROGBITS  none
.dynamic  SHT_DYNAMIC  see below
.hash  SHT_HASH  SHF_ALLOC
.line  SHT_PROGBITS  none
.note  SHT_NOTE  none
.rodata  SHT_PROGBITS  SHF_ALLOC
.rodata1  SHT_PROGBITS  SHF_ALLOC
.strtab  SHT_STRTAB  see below
.symtab  SHT_SYMTAB  see below
.text  SHT_PROGBITS  SHF_ALLOC + SHF_EXECINSTR
.bss     이 섹션은 프로그램의 메모리 이미지에 공헌하는(영향을미치는) 비초기화된 데이타를 가지고 있다. 정의에 의해서, 프로그램이 실행을 시작할때 시스템은 데이타를 0 으로 초기화 한다. 섹션은 섹션타입 SHT_NOBITS 에 지시되어진것과 같이 파일 공간을 차지하지 않는다.
.comment   이 섹션은 버전 제어 정보를 가지고 있다.
.data 와
.data1   이 섹션들은 프로그램 메모리 이미지에 영향을 미치는 초기화된 데이타를 가지고 있다.
.debug   이 섹션은 심볼릭 디버깅을위한 정보를 가지고 있다. 코멘트들은 정의되어지지 않는다. 접두사 .debug를 가지는 모든 섹션 이름들은 미래의 사용을 위해서 예약되어져 있다.
.dynamic   이 섹션은 동적 링킹 정보를 가지고 있다. SHF_ALLOC 와 SHF_WRITE 와 같은 특성을 가지고 있다. SHF_WRITE 비트가 셋되어지는지 아닌지는 오퍼레이팅 시스템과 프로세서에 의해서 결정되어진다.
.hash    이 섹션은 심볼 해쉬 테이블을 가지고 있다.
.line    이 섹션은 소스프로그램과 머신 코드 사이의 일치성을 설명하는 심볼릭 디버깅을 위한 라인 번호 정보를 가지고 있다. 내용들은 정의되어지지 않는다.
.note    이 섹션은 2장의 "주의 섹션"에 설명되어진 포멧으로 정보를 가지고 있다.
.rodata 와
.rodata1   이 섹션들은 전통적으로 프로세스 이미지 내부에서 기록불가능한 세그먼트에 영향을 미치는 읽기만 가능한 데이타를 가지고 있다. 2장 "프로그램 헤더"를 참조하라.
.shstrtab   이 섹션은 섹션 섹션 이름들을 가지고 있다.
.strtab   이 섹션은 심볼 테이블 엔트리들과 관련있는 이름들을 표시하는 가장 일반적인 문자열들인 문자열들을 가지고 있다. 만일 파일이 심볼 스트링 테이블 포함하는 로더블 세그먼트를 가지고 있다면, 섹션의 특성은 SHF_ALLOC 비트를 포함할 것이다. 그렇지 않다면, 그 티트는 off 일 것이다.
.symtab   이 섹션은 이 장 "심볼 테이블"에서 설명하는 것과 같은 심볼 테이블을 가지고 있다. 만일 파일이 심볼 테이블을 포함하는 로더블 세그먼트를 가지고 있다면, 섹션의 특성은 SHF_ALLOC 비트를 포함할 것이다. 그렇지 않다면, 그 비트는 off 일 것이다.
.text    이 섹션은 프로그램의 "text" 나 실행가능한 명령들을 가지고 있다.
  도트(.) 접두사로 시작하는 섹션 이름들은 시스템을 위해서 예약되어져 있다. 만일 그들의 존재하는 의미들에 만족한다면, 어플리케이션들은 이들 섹션들을 사용할 수 있다. 어플리케이션들은 시스템 섹션들과 충돌을 피하기 위해서 접두사 없이 이름들을 사용 할 수 있다. 오브젝트 파일 포멧은 위의 나열에 나타있지 않는 섹션들을 정의 할수 있도록 한다. 오브젝트 파일 은 동일한 이름을 가지는 한개 이상의 섹션을 가질 수 있다.
 
1.4. String Table (문자열 테이블)

  이 섹션은 디폴트 문자열 테이블을 설명한다.  "문자열 테이블 섹션들"은 일반적으로 문자열이라고 불리는 널로 종료되는 연속된 문자들을 가지고 있다.  오브젝트 파일은 심볼과 섹션 이름들을 표시하기 위해서 이러한 문자열들을 사용한다.  문자열 테이블 섹션에 대한 인덱스로서 문자열을 참조한다.  인덱스 0 인 첫번째 바이트는 널 문자를 가지고 있는것으로 정의되어져 있다.  비슷하게 문자열 테이블의 마지막 바이트는 모든 문자열들에서 널 종료를 화인하는 널문자를 가지고 있도록 정의되어져 있다. 인덱스 0 인 어떤 문자열은 내용에 의존하여 이름이 없거나 널 이름을 지정한다. 빈 문자열 테이블 섹션은 인정되어 진다.  그것의 섹션 헤더의 sh_size 멤버는 0을 포함하고 있다.  0이 아닌 인덱스들은 빈 문자열 테이블에서 유효 하지 않다.
  섹션 헤더의 sh_name 멤버는 ELF 헤더의 e_shstrndx 멤버에 의해 명시되어진 섹션 헤더 스트링 테이블 섹션 내부에 대한 인덱스를 가지고 있다. 다음 그림은 25바이트를 가지고 있는 스트링 테이블을 보여준다. 문자열들은 다양한 인덱스들과 연관되어 있다.
Index +0 +1 +2 +2 +4 +5 +6 +7 +8 +9
0 \0 n a m e . \0 V a R
10 i a b l e \0 a b l e
20 \0 \0 x x \0     

그림 1-14.  String Table Indexes

Index String
0 none
1 name.
7 Variable
11 able
16 able
24 null string 

  예가 보여주는 바와 같이 문자열 테이블 인데스는 섹션안에 있는 어떤 바이트를 참조한다. 문자열은 한번 이상 나타 날수 있다. 서브스트링에 대한 참조도 가능 하다. 단일 문자열은 여러번 참조 되어 질수 있다.  참조되어지지 않는 문자열 역시 허락 되어진다.

 
1.5. Symbol Table (심볼 테이블)

  오브젝트 파일의 심볼 테이블은 프로그램의 심볼 정의들과 참조들을 배치하고 재배치하기 위해서 필요한 정보을 가지고 있다.  심볼테이블 인덱스는 이 배열 내부에대한 첨자이다.  테이블 안에있는 첫번째 엔트르를 표시하고 정의되지 않는 심볼 인덱스 처럼 사용되어지는 것은 인덱스 0 이다.  최초 엔트리의 내용은 이 섹션안에서 후반부에 설명되어 진다

Name Value
UNDEF  0

  심볼 테이블 엔트리는 다음 포멧을 가지고 있다.

그림 1-15.  Symbol Table Entry

typedef struct {
Elf32_Word  st_name;
Elf32_Addr  st_value;
Elf32_Word  st_size;
unsigned  char st_info;
unsigned  char st_other;
Elf32_Half  st_shndx;
} Elf32_Sym;

st_name 이 멤버는 심볼 네임들에 대한 문자 표현을 가지고 있는 오브젝트 파일의 심볼 문자열 테이블 내부에 대한 인덱스를 가지고 있다.
st_value 이 멤버는 관련된 심볼에 값을 부여 한다.  내용에 의존 적이다. 이것은 절대값, 주소 등등을 가질수 있다. 자세한 사항은 아래에 설명한다.
st_size 많은 심볼들은 관련된 사이즈를 가지고 있다. 예를 들면 데이타 오브젝트의 사이즈는 오브젝트 내부에 포한되어진 바이트의 수이다.  만일 심볼이 크기가 없거나 알려져 있지 않는 크기라면 이 멤버는 0을 가지고 있다.
st_info 이 멤버는 심볼의 타입과 특성을 결합하는 것을 지정한다.  값의 리스트와 의미는 아래에 설명한다.  다음 코드는 값들을 어떻게 처리할지를 보여 준다.
#define ELF32_ST_BIND(i)   ((i)>>4)
#define ELF32_ST_TYPE(i)   ((i)&0xf)
#define ELF32_ST_INFO(b,t)  (((b)<<4)+((t)&0xf))

st_other 이 멤버는 현재 0을 가지고 있다. 정의된 의미를 가지고 있지 않다.
st_shndx 모든 심볼 테이블 엔트리는 어떤 섹쎤과 연관되어 정의되어진 것이다. 이 멤버는 관련 섹션 헤더 테이블 인덱스를 가지고 있다. 그림 1-7 그리고 관련된 문장이 설명하는것과 같이, 어떤 섹션 인덱스들은 특별한 의미들을 가지고 있다.
  심볼의 바인딩은 링키지 가시성과 행동양식을 결정한다..
그림 1-16.  Symbol Binding, ELF32_ST_BIND

Name Value
STB_LOCAL 0
STB_GLOBAL  1
STB_WEAK  2
STB_LOPROC  13
STB_HIPROC  15

STB_LOCAL    로컬 심볼들은 그들의 정의를 포함하고 있는 오브젝트 파일 외부에는 보이지 않는다.  같은 이름의 로컬 심볼들은 서로 간섭함이 없이 여러개의 파일들 안에 존재 할 수 있다.

STB_GLOBAL   전역 변수들은 결합되어지는 모든 오브젝트 파일들에 보여 진다. 전역 심볼에 대한 어떤 파일의 정의는 같은 전역 심볼에 대한 다른 파일에서 미정의되어진 심볼을 참조하는 것을 만족시키게 될 것이다..

STB_WEAK      위크 심볼들은 전역 심볼들과 비슷하다. 하지만 그들의 정의들은 보다 낮은 우선권을 가지고 있다.

STB_LOPROC ~ 이 범위의 값들은 프로세서 특성 의미들로 예약되어져 있다..
STB_HIPROC

  각 심볼 테이블 내부에서, STB_LOCAL 바인등을 가지는 모든 심볼들은 위크 와 전역 심볼들보다 우선권을 갖는다.  심볼의 타입은 관련 엔트리를 위한 일반적인 분류를 제공한다. 

그림 1-17.  Symbol Types, ELF32_ST_TYPE 

Name Value
STT_NOTYPE 0
STT_OBJECT  1
STT_FUNC  2
STT_SECTION  3
STT_FILE  4
STT_LOPROC  13
STT_HIPROC  15 

STT_NOTYPE        심볼의 타입은 지정되어지지 않았다.

STT_OBJECT        변수, 배열 등과 같이 심볼은 데이타 오브젝트와 관련이 있다.
STT_FUNC        심볼을 함수나 다른 실행가능한 코드와 관련이 있다..
STT_SECTION  심볼은 섹션과 관련 있다. 이 타입의 심볼 테이블 엔트리는 재배치를 위해 중요하게 존재한다. 일반적으로 STB_LOCCAL 바인딩을 가가진다.
STT_LOPROC ~
STT_HIPROC  이 범위에 있는 값들은 프로세서 특성 의미들로 예약되어져 있다.  만일 심볼의 값이 섹션안에 있는 특정 위치를 참조한다면, 그것의 섹션 인덱스 멤버 st_shndx는 섹션 헤더 테이블 내부에 대한 인덱스를 가지고 있다. 섹션이 재배치 동안에 이동한는 것과 같이 심볼의 값도 물론 변경되어 진다. 심볼에 대한 참조는 프로그램 내부에서 동일한 위치를 지적하기 위해서 계속한다. 몇몇 특혈한 섹션 인데스 값들은 다른 의미를 부여한다..
STT_FILE  파일 심볼은 STB_LOCAL 바인딩을 가지고 있다. 그 섹션의 인덱스는 SHN_ANS 이다. 만일 존재 한다면, 그것은 파일을 위한 다른 STB_LOCAL 심볼들 보다 우선권을 가진다.
  ELF 오브젝트 파일들 안에서 심볼들은 링커와 로더를 위해서 특별한 정보들을 전달 한다. 시스템 내부에서 사용되어지는 실제 링킹 모델의 설명은 오퍼레이팅 시스템 섹션들을 보아라.
SHN_ABS 심볼은 재배치 때는에 변경되어지지 않는 절대 값을 가지고 있다.
SHN_COMMON 심볼은 아직 할당 되어지지 않는 일반적인 블록을 표시 하고 있다. 심볼의 값은 제한적 얼라인먼트가 주어진다. 섹션의 sh_addralign 멤버와 비슷하다. 즉, 링커 에디터는 st_value 개수의 주소에 심볼을 위한 영역을 할당하게 될 것이다. 심볼의 사이즈는 얼마나 많은 바이트들이 요구되어지는 말하게 된다.
SHN_UNDEF 이 섹션 테이블 인덱스는 심볼이 정의되이지 않았다는 것을 의미한다.  링크 에디터가 지시되어진 심볼을 정의하는 다른 파일과 이 오브젝트 파일을 결합할때, 심볼에대한 파일의 참조는 실제 정의에 대해 링크되어질 것이다.
  위에 언급 되어 진 것과 같이, 인덱스 0(STN_UNDEF)인 심볼테이블 엔트리는 예약 되어져 있다. 그것은 다음과 같은 값을 가지고 있다.
그림 1-18.  Symbol Table Entry: Index 0

Name Value Note
st_name 0 No name
st_value 0 Zero value
st_size 0 No size
st_info 0 No type, local binding
st_other 0
st_shndx SHN_UNDEF No section
 
1.5.1. Symbol Values (심볼 값들) 

  오브젝트 파일이 어떤 형태인지에 따라서 st_value 멤버는 약간은 다른 의미를 가지고 있다.
 
 재배치 파일들에서, st_value 는 심볼의 섹션 인덱스가 SHN_COMMON 이도록 억제하는 얼라인먼트(값)를 가지고 있다.

 재배치 파일들에서, st_value는 정의되어진 심볼들을 위해서 섹션 옵셋 값을 가지고 있다. 즉, st_value 는 st_shndx 가 지정하는 섹션의 시작에서 부터 옵셋이다. 

 실행 파일과 공유 오브젝트 파일들에서 st_value 는 가상 주소 값을 가지고 있다. 이런한 파일들의 심볼들이 동적 링커를 위해 보다 유용하도록하기 위해서, 섹션 옵셋(파일 번역)은 섹션 번호가 부적절한 가상 주소(메모리 번역)를 부여 한다.(?)

  심볼 테이블 값은 다른 오브젝트 파일들에서도 비슷한 의미를 갖는다고 할 지라도, 데이타는 적당한 프로그램들에의해서 효과적인 접근을 허락한다.

 
1.6. Relocation (재배치) 

  재배치는 심볼의 정의를 심볼의 참조로 연결하는 처리이다. 예를 들면, 프로그램이 함수를 호출 할때, 관련된 콜 명령은 실행시 적절한 목적 주소로 제어를 변경 하여야만 한다. 즉, 재배치 가능 파일들은 그들의 섹션 내용들을 어떻게 수정할지에 대해 설명하는 정보들을 가지고 있어야만한다. 그래서 실행가능 파일들과 공유 오브젝트 파일들로 하여금 프로세스의 프로그램 이미지를 위한 올바른 정보를 가지고 있도록 허락한다.  "재배치 가능 엔트리"는 이러한 데이타 이다
.
그림 1-19.  Relocation Entries

typedef struct {
Elf32_Addr  r_offset;
Elf32_Word   r_info;
} Elf32_Rel;

typedef struct {
Elf32_Addr  r_offset;
Elf32_Word  r_info;
Elf32_Sword  r_addend;
} Elf32_Rela;

r_offset  이 멤버는 재배치 행위를 적용하기 위한 위치를 부여 한다. 재배치가능 파일에서 값은 섹션의 시작으로 부터 재배치에의해 영향을 받는 저장 단위까지 바이트 옵셋이다. 실행가능 파일이나 공유 오브젝트 에서, 값은 재배치에의해서 영향을 받는 저장 단위의 가상 주소이다.

r_info  이 멤버는 재배치가 이루어져야만하는 관련된 심볼 테이블 인덱스 그리고 적용하기위한 재배치 타입을 부여한다. 예를 들면, 콜 명령의 재배치 엔트리는 호출되어지는 함수의 심볼 테이블 인덱스를 가지고 있을 수 있다.  만일 인덱스가 미정의된 심볼 인덱스인 STN_UNDEF 이라면,  재배치는 "심볼 값"에서 처럼 0을 사용한다.  재배치 타입들은 프로세서 특성 이다. 그것들의 행동 양상에대한 설명을 프로세서 부록에 나타나 있다. 프로세서 부록안에 있는 설명이 재배치 엔트리의 재배치 타입이나 심볼 테이블 인덱스에 관해 언급할때, 엔트리의 r_info 멤버에 대한 각각 ELF32_R_TYPE 나 ELF32_R_SYM 을 적용한 결과를 의미한다.

#define ELF32_R_SYM(i)  ((i)>>8)
#define ELF32_R_TYPE(i)    ((unsigned char)(i))
#define ELF32_R_INFO(s,t)  (((s)<<8)+(unsigned char)(t))
r_addend 이 멤버는 재배치가능 필드 내부에 저장되어질 값을 계산한기 위해서 사용되어지는 상수 값을 지정한다..
  위에서 보여준것과 같이, 오직 Elf32_Rela 엔트리 만이 정확한 추가 값을 가지고 있다. Elf32_Rel 타입의 엔트리들은 수정되어지는 위치 안에 암시적인 추가값을 저장한다. 프로세서의 구조에 따라서, 어떤 형태나 다른 형태가 필요 할수 있거나 보다 편리 할수 있다. 따라서, 특별한 머신을 위한 수행은 배타적으로 어떤 형태나 내용 의존적인 다른 형태를 사용 할 수 있다.

  재배치 섹션은 두개의 다른 섹션을 참조한다 : 심볼 테이블과 수정하기위한 섹션.  위의 "섹션들" 단원에서 설명되어진 섹션 헤더의 sh_info 와 sh_link 멤버들은 이러한 연관 관계를 표시한다. 오브젝트 파일들의 형태가 다를경우, 재배치 엔트리들에 있는 r_offset 멤버는 약간 다르게 해석되어진다.

 재배치 파일들에서, r_offset은 섹션 옵셋 값을 가지고 있다. 즉, 재배치 섹션 자치는 파일 안에있는 다른 섹션을 어떻게 수정할것인지에 대한 설명이다. 재배치 옵셋들은 두번째 섹션안에 있는 저장 단위를 명시한다.

 실행가능 파일들과 공유 오브젝트 파일들에서, r_offset 은 가상 주소 값을 가지고 있다. 동적 링커를 위해서 보다더 유용한 이러한파일들의 재배치 엔트리들을 만들기 위해서,  섹션 옵셋(파일 번역) 가상 주소(메모리 번역)을 부여한다.

  형태가 다른 오브젝트 파일에서 r_offset의 해석이 관련 프로그램에의해서 효과적인 엑세스를 허락한다고 할지라도,  재배치 티입의 의미는 동일하게 남아있다.

 
2. Program Loading and Dynamic Linking
   (프로그램 로딩 및 동적 링킹)

2.1. Introduction (소개) 

  이번 장에서는 프로그램을 실행되도록 만드는 오브젝트 파일 정보 와 시스템 액션들에 관해서 설명한다.  실행가능 파일들과 공유 오브젝트 파일들은 프로그램들을 정적으로 표현한다. 그러한 프로그램들을 실행하기 위해서, 시스템은 동적 프로그램 표현이나 프로세스 이미지들을 만들기 위해서 파일들을 사용한다.  프로세스 이미지는 자신의 text, data, stack 등등의 조각을 가지고 있다.  이 섹션은 프로그램 헤더를 설명하고 프로그램 실행과 직접적으로 관련이 있는 오브젝트 파일 구조들을 설명함으로서 1번 장을 보충한다. 중요 data 구조, 프로그램 헤더 테이블은 파일 안에 조각 이미지들로서 위치해 있다. 프로그램을 위한 메모리 이미지를 만들기 위해서 필요한 다른 정보들을 포함하고 있다.

  오브젝트 파일이 주어지면,  시스템은 프로그램을 실행하기 위해서 그것을 메모리로 로드해야만 한다. 시스템이 프로그램을 로드한 후에, 프로세스를 구성하는 오브젝트 파일들안에 있는 심볼릭 참조를 해결함으로서 프로세스 이미지를 완성해야한다.

 
2.2. Program Header (프로그램 헤더)

  실행가능 파일들과 공유 오브젝트 파일의 프로그램 헤더 테이블은 구조체의 배열이다. 각각은 프로그램의 실행을 준비 하기 위해서 시스템이 필요로 하는 세그먼트나 다른 정보를 설명하고 있다.  오브젝트 파일 세그먼트는 하나 나 그 이상의 섹션들을 포함하고 있다. 프로그램 헤더들은 실행가능 파일들과 공유 오브젝트 파일들에서만 의미가 있다. 파일은 자신의 프로그램 헤더 사이즈를 ELF 헤더의 e_phentsize 와 e_phnum 멤버로 지정한다. [ 1장에 있는 “ELF 헤더” 를 보라 ] 

그림 2-1.  Program Header

typedef struct {
Elf32_Word  p_type;
Elf32_Off  p_offset;
Elf32_Addr  p_vaddr;
Elf32_Addr   p_paddr;
Elf32_Word  p_filesz;
Elf32_Word  p_memsz;
Elf32_Word  p_flags;
Elf32_Word  p_align;
} Elf32_Phdr;

p_type  이 멤버는 이 배열 요소가 설명하는 세그먼트의 종류 나 배열 요소의 정보를 어떻게 해석할지를 말해 준다. 이 값 과 그것들의 의미는 아래에서 설명한다.

p_offset  이 멤버는 세그먼터의 첫번째 바이트가 존재하는 파일의시작 부터의 옵셋을 부여한다.

p_vaddr  이 멤버는 세그먼트의 첫번째 바이트가 메모리상에 존재하는 가상 주소를 부여한다.

p_paddr  어떤 물리적 주소가관련있는 시스템 상에서, 이 멤버는 세그먼트의 물리적 주소를 위해서 예약되어져 있다. 이 멤버는 BOOK III 의 끝부분에있는 부록에서 설명하고 있는 오퍼레이팅 시스템 지정 정보를 요구한다. 

p_filesz  이 멤버는 세그먼트의 파일 이미지 내부에서 바이트들의 수를 부여한다. 그것은 0이 될수 있다.

p_memsz  이 멤버는 세그먼트의 메모리 이미지 안에서 바이트들의 수를 부여한다. 그것은 0이 될 수 있다.

p_flags  이 멤버는 세그먼트에 관련된 플래그들을 부여한다. 정의되어진 플래그 값들은 아래에서 설명한다.

p_align  로더블 프로세스 세그먼트들은 p_vaddr 과 p_offset값을 페이지 사이즈로 나눈 나머지 값이 일치하여야만 한다.  이 멤버는 메모리와 파일 안