===================================================== 제목 : Executable and Linking Format (Spec 1.2) 작성자 : Application Binary Interface(ABI) & TIS 작성일자 : 알리만무 라이센스 : GPL 홈페이지 : http://osx86.codesum.org 분석*번역: edward frswz 분석 버젼: ver 0.0.1 ===================================================== Executable and Linking Format ======================================================= * 준비물 % Linux 환경에서 ASSEMBLE하는 경우 - i386이상 - 리눅스 - NASM - binutils package(gcc, gdb, ld, objcopy, objdump 필수) - binutils source - xxd or od or hexedit or hexeditor (암거나 주로 설명은 hexeditor를 이용함) 저는 file format 이나 linux에 대해서 거의 문외한 이니 틀린 내용이나 이상한 내용은 바로 메일로 씹어주세요. 제가 검증 후 바로 고쳐서 업데이트 하겠습니다. 이문서는 결코 제 개인의 창작물이나 그런것이 아닌 다른이(TIS팀)의 문서를 번역 분석작업을 했을 뿐입니다. 만약 이 문서의 원본을 작성하신분이 이의를 제기할 경우 제 홈페이지에서 지울것임을 알려드리는 바입니다. email : osx86@codesum.org ======================================================= 0. 서문 ELF 포맷은 UNIX SYSTEM Laboratories 의 Application Binary Interface 파트에서 개발하였고, Tool Interface Standards 에 의해 32-bit IA 환경의 다양한 OS 의 portable object file format 으로 발전되었다고 합니다. (그냥 들은거라 잘 모름.. 누가 만들었는지 관심도 없음) 1. 이 문서에 대해 이문서는 다양한 32bit-IA 환경에서의 object or executable file format 생성 에 대해 알아보고자 한다. PART 1. "OBJECT FILES" - ELF OBJECT 파일 포맷에 대한 설명 PART 2. "Program Loading & Dynamic Linking" - 파일생성 및 프로그램 실행시, 오브젝트 파일 정보와 시스템 액션에 대한 설명 PART 3. "C Library" - libsys 에 포함된 심벌 리스트 - ANSI C 와 libc 루틴 그리고 global data symbol 에 libc 푸틴의 필요에 대한 설명 PART 1. OBJECT FILES 1-1. Introduction part1에서는 ELF라 불리는 iABI object file format에 대해 설명하고자 한다. ELF 는 3가지 main type 이 있고 다음과 같다. * relocatable file(재배치 가능 파일) : code와 data를 다른 object file과 linking 시켜 executable or shared object 파일 생성이 용이하다. * executable file(실행 가능 파일) : exec(BA_OS)가 프로그램 프로세싱 이미지를 어떻게 하는지 알수있다. 걍 실행파일이라고 ... * shared object file(어설픈 번역 안할래요. 그냥 그대로 이해하세요) : code와 data를 다른 object file과 linking(두가지 예) First, 다른 relocatable file 과 shared object file 를 이용해 다른 Object file 생성 Second, dynamic linker 를 이용해 executable file 과 other shared object를 결합해 process image 생성 1-2. File Format Object file 은 program linking 과 execution 에 이용되며, file의 내용에 대한 어떤 동작에 대해 필요한 부분부분을 알려주게된다. Figure 1-1 에서 object file 의 구성을 나타내고 있다. Figure 1-1: Object File Format linking view Execution view ------------------------------ ------------------------------ | elf header | | elf header | ------------------------------ ------------------------------ | program header table | | program header table | | optional | | | ------------------------------ ------------------------------ | section 1 | | segment 1 | | ... | | | ------------------------------ ------------------------------ | section n | | segment 2 | | ... | | | ------------------------------ ------------------------------ | ... | | ... | ------------------------------ ------------------------------ | section header table | | section header table | | | | optional | ------------------------------ ------------------------------ * ELF header 는 파일 구성의 시작점에 존재하며, * section 은 linking view 에 대한 object file의 대부분의 정보(instructions, data, symbol table, relocation 정보 등) 를 갖고 있으며, special section에 대한 내용은 part1 뒷부분에 나오며, part2 에서는 segment 와 program execution view 에 대해서 논하게 된다. * program header table 이 존재한다면 system 이 process image 를 어떻게 생성하는지에 대해 알수있고, process image(execute a program)에는 항상 program header table가 존재 한다. 물론 relocatable file은 예외다. * section header table 은 file 의 section 정보를 포함하게 되며, 모든 section 은 entry(in the table)를 갖게 되고, 각각의 entry 는 section name, section size와 같은 정보들을 포함한다. (section header table은 linking 작업을 하는데 사용된다.) # 머라고 중얼 거리는지 저도 모르겠군요. 하지만 감은 대충오는데, 나중에 elf-format 파일을 열어서 한번 보도록하죠. =========================================================== 여기서 부터는 제 생각대로 쓰는 공간입니다. 너무 이론만 나오는거 같아 저도 무슨말인지 이해가 잘 안되고, 실제 코드와 map 을 열어서 한번 봤으면 좋을거 같아서 간단한 프로그램을 작성하여, 한번 돌려보겠습니다. 엉터리로 설명하는게 너무 위험하다는걸 알지만, 이글을 읽으시는 분들이 저를 가르쳐 줄수도 있다는 생각에 작성합니다. 이상한 부분은 꼭 메일로 통보해주세요. #source : test1.c ------------------ int myVar = 5; int main() { } ------------------ # compile & linking & objcopy gcc -c test1.c ld -o test1 -Ttext 0x0 -Tdata 0x1234 -N -e main test.o -M > test1.map objcopy -R .comment -R .note -O binary test1 test1.bin ndisasm -b 32 test1.bin > test1.dmp 일단 여기까지 해놓고 ... spec 에 대한 설명에 마춰 나올때 마다 한번 열어서 확인해봅시다. =========================================================== 1.3 Data Representation object file format 은 7bit와 32bit 아키텍쳐의 다양한 프로세서를 지원하지만, 더 작게 혹은 더 큰 아키텍쳐에 대한 확장도 가능하다. 이는 머신 독립적인 format의 data터 흐름을 표현한다고 볼수있다. Figure 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 ------------------------------------------------------------------ ============ inside the linux =========== #source : /linux/include/linux/elf.h typedef unsigned long Elf32_Addr; typedef unsigned short Elf32_Half; typedef unsigned long Elf32_Off; typedef long Elf32_Sword; typedef unsigned long Elf32_Word; (이런식으로 정의가 되어있네요 ... 아마 part1에서 쓰이는 대부분의 flag나 변수는 elf.h 에 있을겁니다.) ======================================== object file format의 모든 data 구조는 ''natural'' size와 alignment의 정의를 따른다. 만약 필요하다면, data 구조는 4-byte alignment 지키기위한 명시적 padding 을 포함하고, data는 파일의 시작점으로 부터 alignment를 맞춘다. 등등 여러가지 편리함을 이유로, ELF는 bit-field 를 사용하지 않는다. 1.4 Character Representation 여기서는 ELF 의 기본 character 표현과 시스템간 portable 한 external file을 위한 표준 character set 의 사용에 대한 정의를 내린다. 대부분의 external file format 은 character를 사용하여 information 을 제어한다. 이러한 single-byte character들은 7-bit ASCII character set 을 사용하게된다. ASCII 문자들을 예로들어 '\', '\n' 등을 47과 10의 numerical value 를 사용하게 된다. 0~127 을 수치를 넘어선 character value 에 대해서는 그이상의 바이트를 더 사용하게 되고, 이에따라 character enconding 을 하게 된다. application은 자신들의 character set을 다른 language에 적절하게 character set 확장을 사용하여 제어할수도 있다. 비록 TIS-conformance 가 character set 에 대한 제한은 하지 않더라도, 일반적으로 몇가지 simple guideline 을 따르게된다. 7bit ASCII code는 위에서 말했다시피, 그리고 대부분 알고 있는것처럼 0~127 사이의 값과 일치하게 된다. multibyte character 의 경우 self-identifying 을 해야한다. 예를 들어, 어떤 multibyte character가 어떤 multibyte character들 사이에 삽입되기 위해서는 character interpretaion 에 어떠한 변화도 있어서는 안된다는 의미이다. 이러한 주의가 필요한 이유는 multilingual application 에서 문제가 되기 때문이다. 1.5 ELF Header 어떤 object file control structure는 성장가능하다. 왜냐면 ELF header는 object file 의 실제 크기를 포함하기 때문이다. 만약 object file format 이 바뀌면, 프로그램은 control structure 가 커지가나 보다 작아질것이다. 따라서 프로그램은 이런 "extra" information 을 무시해도 된다. Figure 1-3. ELF Header ====================================================== #source : /linux/include/linux/elf.h #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; 앞으로 나오는 define된 값은 이 elf header 구조체에 각 변수들에 대한 값들 입니다. 눈에 확 집어 넣어버립시다. 나중에 계속 이걸 봐야하는 일이 많을겁니다. 왔다갔다 하시기 귀찮을테니... ;) ====================================================== - e_ident : e_ident 는 file에 initial byte로 마킹되고, 파일의 contents를 decode와interpret를 통해 machine-independant data를 제공하는 역할을 한다. 완전한 description 은 아래 ELF Identification 을 참조바람 - e_type : e_type 은 object file type을 식별하는 역할을 한다. =============================================== Name Value Meaning =============================================== ET_NONE 0 No file type ET_REL 1 Relocatable file ET_EXEC 2 Executable file ET_DYN 3 Shared object file ET_CORE 4 Core file ET_LOPROC 0xff00 Processor-specific ET_HIPROC 0xffff Processor-specific #source : /linux/include/linux/elf.h =============================================== 비록 core file contents 는 unspecified 이긴 하지만 type ET_CORE 는 file 타입을 mark 하기위해 예약되어 있다. ET_LOPROC로부터 ET_HIPROC 까지의 값은 processor-specific semantics로 예약되어 있다. 다른 값들은 new object file type의 할당을 위해 reserved 상태이다. HEX파일 열어서 봅시다. //////////////////////////////////by edward///////////////////////////////// #source : test1.c (위에서 나왔음) #compile gcc -c test1.c #hex dump hexeditor test1.o #dumped screen File test1.o ASCII Offset : 0x00000000 / 0x000002E9 # unsigned char e_ident[16] 00000000 7F 45 4C 46 ............. .......... ........... .ELF........... # Elf32_Half e_type (2byte) 00000010 01 00 ..... ............. .......... ........... ............... #으로 표기된 내용은 제가 추가한 내용입니다. 지금 보여지고 있는 화면은 ASCII 값 위주의 HEX 표현입니다. 따라서 LSB 타입으로 읽어나가야 겠죠. Elf32_Half e_type인 0x00000010 으로 시작하는 데이터가 01 00 으로 표현되어 있지만 실제는 0001 의 의미입니다. hexeditor 의 표현으로 보시기 싫으시면, od -x test1.o 라고 타이핑 하시면 LSB 타입으로 출력이 됩니다. 여튼 e_type의 0001(ET_REL) 이므로 이 파일은 relocatable file 이란 의미입니다. 그렇다면 gcc -c test1.c 라고 컴파일 하지말고, 바로 -o 옵션을 줘서 실행파일을 만들어 볼까요. # compile gcc -o test1 test1.c #hex dump hexeditor test1 #dumped screen File test1 ASCII Offset : 0x00000000 / 0x000002E9 # unsigned char e_ident[16] 00000000 7F 45 4C 46 ............. .......... ........... .ELF........... # Elf32_Half e_type (2byte) 00000010 02 00 ..... ............. .......... ........... ............... 00000010 02 00 이라고 나오죠 이걸 LSB 표현으로 바꾸면, 0002 가 됩니다. od -x test1 으로 출력하셔서 보시면 아마 그렇게 나올겁니다. 0002(ET_EXEC) executable file이란 의미죠. /////////////////////////////////////////////////////////////////////////////// - e_machine : e_machine 은 개개의 file에 요구되는 아키텍쳐를 표현한다. ================================================== Name Value Meaning ================================================== ET_NONE 0 No machine <-- 스펙이 잘못된걸까요. EM_NONE 0 No machine (이게 맞겠죠. 소스를 열어 확인해보시길 include/linux/elf.h) EM_M32 1 AT&T WE 32100 EM_SPARC 2 SPARC EM_386 3 Intel Architecture EM_68K 4 Motorola 68000 EM_88K 5 Motorola 88000 EM_860 7 Intel 80860 EM_MIPS 8 MIPS RS3000 Big-Endian EM_MIPS_RS4_BE 10 MIPS RS4000 Big-Endian RESERVED 11-16 Reserved for future use #source : /linux/include/linux/elf.h ================================================== 다른 값들은 new machine을 위해 reserved 상태이다. processor-specific ELF name은 Machine name으로 구분한다. 예를들어, WIDGET 플레그는 EF_XYZ machine 은 EF_XYZ_WIDGET 이라 불린다. 이것도 볼까요. //////////////////////////////////by edward///////////////////////////////// #source : test1.c (위에서 나왔음) #compile gcc -c test1.c #hex dump hexeditor test1.o #dumped screen File test1.o ASCII Offset : 0x00000000 / 0x000002E9 # unsigned char e_ident[16] 00000000 7F 45 4C 46 ............. .......... ........... .ELF........... # Elf32_Half e_machine (2byte) 00000010 .. .. 03 00 ............. .......... ........... ............... 03 00 이면 0003(EM_386) 이 되겠죠. 따라서 machine 은 Intel Architecture 386 계열이란 의미를 갖습니다. 이해가시죠. 크로스 컴파일을 했을경우 어떤 결과가 나올지 궁금하긴하지만 아마도 그 상대 machine 에 맞는 값이 나오겠죠. 안해봐서 모르겠습니다. 시간나면 해보도록 하죠. /////////////////////////////////////////////////////////////////////////////// -e_version : e_version 은 object file version 을 식별한다. ===================================== Name Value Meaning ===================================== EV_NONE 0 Invalid versionn EV_CURRENT 1 Current version ===================================== ========================================== #source : /linux/include/linux/elf.h #define EV_NONE 0 #define EV_CURRENT 1 #define EV_NUM 2 ========================================== e_version 값이 1 이면 original file format을 나타내며, extension 한 경우는 그 이상의 number를 갖게된다. EV_CURRENT 값은 current version number에 따라 반영되게 되므로 필요에 따라 바뀌게 된다. 이것도 볼까요. //////////////////////////////////by edward///////////////////////////////// #source : test1.c (위에서 나왔음) #compile gcc -c test1.c #hex dump hexeditor test1.o #dumped screen File test1.o ASCII Offset : 0x00000000 / 0x000002E9 # unsigned char e_ident[16] 00000000 7F 45 4C 46 ........... .......... ........... .ELF........... # Elf32_Word e_version (4byte) 00000010 .. .. .. .. 01 00 00 00 .......... ........... ............... 4byte LSB 로 맞춰보면 00000001(EV_CURRENT) 이 되죠. /////////////////////////////////////////////////////////////////////////////// - e_entry : e_entry 는 시스템이 처음으로 실행하기위해 제어해야 할 virtual address를 갖게된다. =================================================================== ld .... -e main -e : 프로그램 실행시 젤 처음 시작되는 entry name ld 의 entry point 참조 the `-e' entry command-line option; the ENTRY(symbol) command in a linker control script; the value of the symbol start, if present; the address of the first byte of the .text section, if present; The address 0. =================================================================== 만약 파일에 대한 entry point 명하지 않는다면, zero 값으로 유지된다. //////////////////////////////////by edward///////////////////////////////// #source : test1.c (위에서 나왔음) #compile gcc -c test1.c #hex dump hexeditor test1.o #dumped screen File test1.o ASCII Offset : 0x00000000 / 0x000002E9 # unsigned char e_ident[16] 00000000 7F 45 4C 46 ........... ........... ........... .ELF........... # Elf32_Word e_entry (4byte) 00000010 .. .. .. .. .. .. .. .. 00 00 00 00 ........... ............... e_entry 는 00000000 이네요. entry point 를 명시하지 않았기 때문이겠죠. 그럼 명시를 해볼까요 ? # linker ld -o test1 -e main test1.o # hex dump hexeditor test1 #dumped screen File test1.o ASCII Offset : 0x00000000 / 0x000002E9 # unsigned char e_ident[16] 00000000 7F 45 4C 46 ........... ........... ........... .ELF........... # Elf32_Word e_entry (4byte) 00000010 .. .. .. .. .. .. .. .. 74 80 04 08 ........... ............... 저걸 LSB 표현으로 보면 08048074 가 되겠죠. 이게 entry point 값이라면 map 파일을 열어서 봐야겠죠. # linker ld -o test1 -e main test1.o -M > test1.map # vi display vi test1.map # display screen ........... Linker script and memory map # 여기는 ld 에서 -T linker script를 이용해 만든 데이터가 나오겠죠. 옵션을 주지 않았으므로 데이터가 없습니다. LOAD test.o 0x08048074 . = (0x8048000 + SIZEOF_HEADERS) ............ 욜케 나오죠 ... test.o 가 LOAD 될때의 entry point 값이 저기 나오는군요. 그럼 8048은 base , 0074가 SIZEOF_HEADERS 를 나타내는군요. /////////////////////////////////////////////////////////////////////////////// - e_phoff : e_phoff 는 program header table의 file offset을 갖는다. 만약 파일이 program header table 을 갖고 있지 않다면, 값은 0 이 될것이다. ================================================== #source : /linux/include/linux/elf.h typedef struct elf32_phdr{ 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; ================================================== //////////////////////////////////by edward///////////////////////////////// #source : test1.c #compile gcc -c test1.c #hex dump hexeditor test1.o #dumped screen File test1.o ASCII Offset : 0x00000000 / 0x000002E9 # unsigned char e_ident[16] 00000000 7F 45 4C 46 ........... ........... ........... .ELF........... # Elf32_Word e_phoff (4byte) 00000010 .. .. .. .. .. .. .. .. .. .. .. .. 00 00 00 00 ............... 역시나 relocatable file 의 경우 program header table 을 갖고 있지 않고 그결과 0값을 갖게된다. 그럼 executable file 을 열어보자. #compile gcc -o test1 test1.c #hex dump hexeditor test1 #dumped screen File test1.o ASCII Offset : 0x00000000 / 0x000002E9 # unsigned char e_ident[16] 00000000 7F 45 4C 46 ........... ........... ........... .ELF........... # Elf32_Word e_phoff (4byte) 00000010 .. .. .. .. .. .. .. .. .. .. .. .. 34 00 00 00 ............... 00000034 값이 나왔으니 이는 파일에서 program header table의 offset 을 알려주는 값이다. ////////////////////////////////////////////////////////////////////// 확인작업 ========================= by edward =================================== 위에 test1.c 소스가 있죠 이놈의 program header 를 볼려면, objdump -p test1.o <-- relocatable file 이라고하면 아마 /////////////////////////////////////////////////////////////////////// #[object name] [file format] <-- #처리된 내용은 삽입한 내용입니다. test : file format elf32-i386 /////////////////////////////////////////////////////////////////////// 등으로 아무런 정보가 나오지 않을겁니다. 하지만 ld -o test1 -Ttext 0x0 -Tdata 0x1234 -e main test1.o -M > test1.map 라고 entry point 를 main 으로 주게되면 /////////////////////////////////////////////////////////////////////// #[object name] [file format] <-- #처리된 내용은 삽입한 내용입니다. test : file format elf32-i386 # [프로그램 헤더] Program Header: # [offset] [가상주소] [프로그램주소] LOAD off 0x00000074 vaddr 0x00000000 paddr 0x00000000 align 2**2 # [file size] [mem size] filesz 0x00000005 memsz 0x00000005 flags rwx # [가상주소] [프로그램주소] LOAD off 0x0000007c vaddr 0x00001234 paddr 0x00001234 align 2**2 # [file size] [mem size] filesz 0x00000004 memsz 0x00000004 flags rw- /////////////////////////////////////////////////////////////////////// 와 같이 나올겁니다. 여기서 아까 ld -M옵션으로 인해 생성된 test1.map 을 열어서 젤 윗부분에 보시면 이렇게 되어 있을겁니다. vi test1.map /////////////////////////// map file ////////////////////////////////// ........... Linker script and memory map # ld 의 -Ttext 0x0 -Tdata 0x1234 로 인해 정의된 section 주소 Address of section .text set to 0x0 Address of section .data set to 0x1234 LOAD test.o 0x08048074 . = (0x8048000 + SIZEOF_HEADERS) ............ /////////////////////////////////////////////////////////////////////// relocatable file 을 덤프해보니 program header table offet이 나오지 않음을 알수 있습니다. 이제 executable file 을 덤프해볼까요 ... # compile gcc -o test1 test1.c # objdump objdump -p test1 | more # display screen /////////////////////////////////////////////////////////////////////// #[object name] [file format] <-- #처리된 내용은 삽입한 내용입니다. test : file format elf32-i386 # [프로그램 헤더] Program Header: # [offset] [가상주소] [프로그램주소] PHDR off 0x00000034 vaddr 0x08048034 paddr 0x08048034 align 2**2 # [file size] [mem size] filesz 0x000000c0 memsz 0x000000c0 flags r-x ...................................................... 등등 상당히 많은 정보가 출력된다 /////////////////////////////////////////////////////////////////////// 여튼 프로그램 헤더의 offset 정보는 여기까지다. PHDR off 의 offset 값은 0x00000034 라 하고, 이를 virtual address 로 나타내면 0x08048034 또 physical address 또한 0x08048034 임을 알수있다. # map 에 대해 더 자세히 알기위해서는 아래 help를 참조하세요 ... :) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~help~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ SECTIONS { . = SIZEOF_HEADERS; .interp : { *(.interp) } :text :interp .text : { *(.text) } :text .rodata : { *(.rodata) } /* defaults to :text */ ... . = . + 0x1000; /* move to a new page in memory */ .data : { *(.data) } :data .dynamic : { *(.dynamic) } :data :dynamic ... } OVERLAY 0x1000 : AT (0x4000) { .text0 { o1/*.o(.text) } .text1 { o2/*.o(.text) } } .text0 0x1000 : AT (0x4000) { o1/*.o(.text) } __load_start_text0 = LOADADDR (.text0); __load_stop_text0 = LOADADDR (.text0) + SIZEOF (.text0); .text1 0x1000 : AT (0x4000 + SIZEOF (.text0)) { o2/*.o(.text) } __load_start_text1 = LOADADDR (.text1); __load_stop_text1 = LOADADDR (.text1) + SIZEOF (.text1); . = 0x1000 + MAX (SIZEOF (.text0), SIZEOF (.text1)); ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 이 내용은 위와 같은 ld 매뉴얼을 참조하고, 대충 저의 감으로 때려잡은 내용이므로 틀렸을 경우 무엇이 틀렸는지 알려주세요. -_-;; 해놓고도 확인을 못하는 어리석은 자로부터... _(__)_ ======================================================================== - e_shoff : e_shoff 는 section header table의 file offset을 갖는다. 만약 file이 section header table 을 갖고 있지 않다면, 이 값은 0 이 된다. //////////////////////////////////by edward///////////////////////////////// #source : test1.c #compile gcc -c test1.c #hex dump hexeditor test1.o #dumped screen File test1.o ASCII Offset : 0x00000000 / 0x000002E9 # unsigned char e_ident[16] 00000000 7F 45 4C 46 ........... ........... ........... .ELF........... 00000010 .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ............... # Elf32_Off e_shoff (4byte) 00000020 C0 00 00 00 ........... ........... ........... ............... relocatable file이 갖는 section header table offset값은 0000000C 를 나타낸다. executable file이 갖는 section header table offset값은 어떻게 될까 #source : test1.c #compile gcc -o test1 test1.c #hex dump hexeditor test1 #dumped screen File test1 ASCII Offset : 0x00000000 / 0x00001266 # unsigned char e_ident[16] 00000000 7F 45 4C 46 ........... ........... ........... .ELF........... 00000010 .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ............... # Elf32_Off e_shoff (4byte) 00000020 98 07 00 00 ........... ........... ........... ............... executable file이 갖는 section header table offset 값은 00000798 을 나타낸다. //////////////////////////////////////////////////////////////////////////// - e_flags : e_flags 는 processor-specific flag 이다. flag 명은 "EF_[machine]_flag" 로 정해진다. //////////////////////////////////by edward///////////////////////////////// #source : test1.c #compile gcc -c test1.c #hex dump hexeditor test1.o #dumped screen File test1.o ASCII Offset : 0x00000000 / 0x000002E9 # unsigned char e_ident[16] 00000000 7F 45 4C 46 ........... ........... ........... .ELF........... 00000010 .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ............... # Elf32_Off e_flags (4byte) 00000020 .. .. .. .. 00 00 00 00 ........... ........... ............... relocatable file 의 경우 00000000을 출력 executable file 의 경우도 마찬가지다. ////////////////////////////////////////////////////////////////////////////////// - e_ehsize e_ehsize 는 ELF header의 size를 나타낸다. //////////////////////////////////by edward///////////////////////////////// #hex dump hexeditor test1.o #dumped screen File test1.o ASCII Offset : 0x00000000 / 0x000002E9 # unsigned char e_ident[16] 00000000 7F 45 4C 46 ........... ........... ........... .ELF........... 00000010 .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ............... # Elf32_Half e_ehsize (2byte) 00000020 .. .. .. .. .. .. .. .. 34 00 .. .. ........... ............... #hex dump hexeditor test1 #dumped screen File test1 ASCII Offset : 0x00000000 / 0x00001266 # unsigned char e_ident[16] 00000000 7F 45 4C 46 ........... ........... ........... .ELF........... 00000010 .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ............... # Elf32_Off e_ehsize (4byte) 00000020 .. .. .. .. .. .. .. .. 34 00 .. .. ........... ............... relocatable file 의 경우 0034(decimal 52)을 출력하며, 이는 elf header 기본 사이즈와 일치한다. executable file 의 경우도 0034를 갖는다. ////////////////////////////////////////////////////////////////////////////////// - e_phentsize : e_phentsize 는 file의 program header table 엔트리의 크기를 나타낸다. 모든 entry들은 크기가 같다(?) //////////////////////////////////by edward///////////////////////////////// #hex dump hexeditor test1.o #dumped screen File test1.o ASCII Offset : 0x00000000 / 0x000002E9 # unsigned char e_ident[16] 00000000 7F 45 4C 46 ........... ........... ........... .ELF........... 00000010 .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ............... # Elf32_Half e_phentsize (2byte) 00000020 .. .. .. .. .. .. .. .. .. .. 00 00 .. .. .. .. ............... #hex dump hexeditor test1 #dumped screen File test1.o ASCII Offset : 0x00000000 / 0x00001226 # unsigned char e_ident[16] 00000000 7F 45 4C 46 ........... ........... ........... .ELF........... 00000010 .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ............... # Elf32_Off e_phentsize (2byte) 00000020 .. .. .. .. .. .. .. .. .. .. 20 00 .. .. .. .. ............... 참조 ================================================== #source : /linux/include/linux/elf.h typedef struct elf32_phdr{ 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; ================================================== relocatable 0000, executable 0020(decimal value 32 == phdr) /////////////////////////////////////////////////////////////////////////////// - e_phnum : e_phnum 는 program header table 의 엔트리의 수를 나타낸다. 따라서 e_phentsize와 e_phnum으 알면 table 의 크기를 byte 로 나타낼수 있다. 만약 file에 program header table 이 없다면, e_phnum 값은 0 이 된다. //////////////////////////////////by edward///////////////////////////////// #hex dump hexeditor test1.o #dumped screen File test1.o ASCII Offset : 0x00000000 / 0x000002E9 # unsigned char e_ident[16] 00000000 7F 45 4C 46 ........... ........... ........... .ELF........... 00000010 .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ............... # Elf32_Half e_phnum (2byte) 00000020 .. .. .. .. .. .. .. .. .. .. .. .. 00 00 .. .. ............... #hex dump hexeditor test1 #dumped screen File test1.o ASCII Offset : 0x00000000 / 0x000002E9 # unsigned char e_ident[16] 00000000 7F 45 4C 46 ........... ........... ........... .ELF........... 00000010 .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ............... # Elf32_Half e_phnum (2byte) 00000020 .. .. .. .. .. .. .. .. .. .. .. .. 02 00 .. .. ............... relocatable 0000(program header table 이 없으므로 값이 0 이 된다.) executable 0002(program header table 의 엔트리의 수는 2 가 된다.) [확인작업] objdump -p test1.o <-- relocatable file program header table 이 없으므로 아무런 값 출력이 없다. objdump -p test1 <-- executable file [화면 출력] --------------------------------------------------------------------------- #[object name] [file format] <-- #처리된 내용은 삽입한 내용입니다. test : file format elf32-i386 # [프로그램 헤더] Program Header: LOAD off 0x00000074 vaddr 0x00000000 paddr 0x00000000 align 2**2 filesz 0x00000005 memsz 0x00000005 flags rwx LOAD off 0x0000007c vaddr 0x00001234 paddr 0x00001234 align 2**2 filesz 0x00000004 memsz 0x00000004 flags rw- --------------------------------------------------------------------------- /////////////////////////////////////////////////////////////////////////////// - e_shentsize : e_shentsize 는 section header의 크기를 바이트로 나타낸다. //////////////////////////////////by edward///////////////////////////////// #hex dump hexeditor test1.o #dumped screen File test1.o ASCII Offset : 0x00000000 / 0x000002E9 # unsigned char e_ident[16] 00000000 7F 45 4C 46 ........... ........... ........... .ELF........... 00000010 .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ............... # Elf32_Half e_shentsize (2byte) 00000020 .. .. .. .. .. .. .. .. .. .. .. .. .. .. 28 00 ............... #hex dump hexeditor test1 #dumped screen File test1.o ASCII Offset : 0x00000000 / 0x000002E9 # unsigned char e_ident[16] 00000000 7F 45 4C 46 ........... ........... ........... .ELF........... 00000010 .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ............... # Elf32_Half e_shentsize (2byte) 00000020 .. .. .. .. .. .. .. .. .. .. .. .. .. .. 28 00 ............... ------------------------------------- #source : linux/include/linux/elf.h 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; ------------------------------------- relocatable 0028, executable 0028 section header size 는 0028, 위의 elf.h 에 section header 구조체를 보면 40 byte 가 된다. 0x0028 == 40 이 되죠. section header 는 relocatable 이나 executable 이나 같이 존재하나 보군요. /////////////////////////////////////////////////////////////////////////////// - e_shnum : e_shnum 는 section header table의 entry number를 나타낸다. 따라서 e_shentsize 와 e_shnum 로 section header table 의 size 를 알수 있다. 만약 파일에 section header table 이 없다면, e_shnum의 값은 0 이 된다. //////////////////////////////////by edward///////////////////////////////// #hex dump hexeditor test1.o #dumped screen File test1.o ASCII Offset : 0x00000000 / 0x000002E9 # unsigned char e_ident[16] 00000000 7F 45 4C 46 ........... ........... ........... .ELF........... 00000010 .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ............... 00000020 .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ............... # Elf32_Half e_shnum (2byte) 00000030 09 00 .. .. .. .. .. .. .. .. .. .. .. .. .. .. ............... #hex dump hexeditor test1 #dumped screen File test1.o ASCII Offset : 0x00000000 / 0x000002E9 # unsigned char e_ident[16] 00000000 7F 45 4C 46 ........... ........... ........... .ELF........... 00000010 .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ............... 00000020 .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ............... # Elf32_Half e_shnum (2byte) 00000030 0A 00 .. .. .. .. .. .. .. .. .. .. .. .. .. .. ............... relocatable 0009, executable 000A /////////////////////////////////////////////////////////////////////////////// - e_shstrndx : e_shstrndx 는 entry의 section header table index와 관련된 section name string table을 나타낸다. 만약 파일이 section name string table 을 갖지 않는다면, 이값은 SHN_UNDEF 값을 갖게 된다. 이에 대해서는 아래에 나올 Sections 와 String Table 에서 더 자세히 알아보자 //////////////////////////////////by edward///////////////////////////////// #hex dump hexeditor test1.o #dumped screen File test1.o ASCII Offset : 0x00000000 / 0x000002E9 # unsigned char e_ident[16] 00000000 7F 45 4C 46 ........... ........... ........... .ELF........... 00000010 .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ............... 00000020 .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ............... # Elf32_Half e_shstrndx (2byte) 00000030 .. .. 06 00 .. .. .. .. .. .. .. .. .. .. .. .. ............... #hex dump hexeditor test1 #dumped screen File test1 ASCII Offset : 0x00000000 / 0x000002E9 # unsigned char e_ident[16] 00000000 7F 45 4C 46 ........... ........... ........... .ELF........... 00000010 .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ............... 00000020 .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ............... # Elf32_Half e_shstrndx (2byte) 00000030 .. .. 07 00 .. .. .. .. .. .. .. .. .. .. .. .. ............... relocatable 0006, executable 0007 objdump -h test1.o 0 .text ............ ............ 1 .data ............ ............ 2 .bss ............ ............ 3 .note ............ ............ 4 .comment ............ ............ objdump -h test1 0 .text ............ ............ 1 .data ............ ............ 2 .sbss ............ ............ 3 .bss ............ ............ 4 .note ............ ............ 5 .comment ............ ............ 자세한 설명은 Sections 와 String Table 에서 공부한후 다시 수정 하겠습니다. /////////////////////////////////////////////////////////////////////////////// 1.6 ELF Identification 위에서 언급했듯이 elf 는 다양한 processor,data encoding, machine 들을 지원하기 위해 object file framework를 제공한다. 이 object file family 를 지원하기 위해서 file의 초기 바이트는 이 파일을 어떻게 interpret 할것인가 하는것들을 구체적으로 나타내고, 파일의 나머지 내용은 processor 에 대해 독립적이다. ELF header 의 초기 바이트는 e_ident member의 index는 다음과 같다. (배열 인덱스 같네요 ...) Figure 1-3 재방송. ELF Header ====================================================== #source : /linux/include/linux/elf.h #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; ======================================================= Figure 1-4. e_ident[] Identification Indexes ========================================================= Name Value Purpose ========================================================= EI_MAG0 0 File identification EI_MAG1 1 File identification EI_MAG2 2 File identification EI_MAG3 3 File identification EI_CLASS 4 File class EI_DATA 5 Data encoding EI_VERSION 6 File version EI_PAD 7 Start of padding bytes EI_NIDENT 16 Size of e_ident[] ========================================================= 이 index들은 다음 값들을 갖게 된다. 이 아래 내용 들은 이 index 에 대한 설명이다. - EI_MAG0 to EI_MAG3 : 파일의 첫 4byte는 ELF object file임을 알려주는 magic number를 갖게된다. ================================================= 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] ================================================= ////////////////////////by edward////////////////////////////////////////////// #source : test1.c (위에서 나왔음) #compile gcc -c test1.c #hex dump hexeditor test1.o #dumped screen File test1.o ASCII Offset : 0x00000000 / 0x000002E9 00000000 7F 45 4C 46 ............. .......... ........... .ELF........... 대충 이렇게 나오죠 ... 위의 4byte가 e_ident array 의 첫 4 byte인 ELF MAGIC NUMBER 입니다. 그럼 ELFMAG0는 0x7F 이고 45는 Decimal number 로 바꾸면 69가 되죠. 65부터 'A' 니까 'E'는 69값이 되죠. 4C는 'L' 46은 'F' /////////////////////////////////////////////////////////////////////////////// - EI_CLASS : e_ident[EI_CLASS] 는 파일의 class 또는 capacity 를 알려주게 된다. ================================================= Name Value Meaning ================================================= ELFCLASSNONE 0 Invalid class ELFCLASS32 1 32-bit objects ELFCLASS64 2 64-bit objects ================================================= % 스펙에는 빠져있지만 ELFCLASSNUM 이란것도 있군요. 아마 스펙이후에 재정의된 ELF 라서 그런가봅니다. #define ELFCLASSNUM 3 파일 포맷은 다양한 size의 machine에 대해 portable 하게 디자인 되었는데, 최소 size의 machine 에 최대 size를 사용하지는 않으며, Class ELFCLASS32 는 machine의 file 과 virtual address space를 최대 4gb를 지원한다. ( 기본 타입 : ELFCLASS32 ) Class ELFCLASS 는 불완전하지만 64-bit architecture 를 지원한다. 다른 class 들은 필요에 따라 object file data를 위한 다른 basic type 과 size 를 정의하면 된다. 맞는지 확인해볼까요 ? ////////////////////////by edward////////////////////////////////////////////// #hex dump hexeditor test1.o #dumped screen File test1.o ASCII Offset : 0x00000000 / 0x000002E9 00000000 7F 45 4C 46 01 ........ .......... ........... .ELF........... 이렇게 나오죠 ... 5번째 byte는 e_ident array 의 5번째 바이트로 01 을 나타내고 있군요. EI_CLASS(file class)는 ELFCLASS32 로 32-bit objects 임을 나타냅니다. /////////////////////////////////////////////////////////////////////////////// -EI_DATA : e_ident[EI_DATA]는 object file의 processor-specific data로 data encoding 하는 기능을 제공한다. ================================================ Name Value Meaning ================================================ ELFDATANONE 0 Invalid data encoding ELFDATA2LSB 1 See below ELFDATA2MSB 2 See below ================================================ 다른 값들은 새로운 encoding 방법이 필요할때를 위해 reserved 상태로 남겨둔다. 파일의 data encoding은 basic object 가 어떻게 interpret 해야 하는지를 결정한다. 위에서 서술한대로, class ELFCLASS32 파일은 1,2 그리고 4byte object를 사용한다. 아래 정의된 encoding 표현을 보는 방법은 byte number는 box의 왼쪽 상단 모서리에 표현하고 data 는 box의 중앙에 위치한다. % object ? object 파일이라는 내용으로도 나오지만, 지금은 data encoding type (1byte,2byte,4byte) 이러한 하나 하나를 object라고 부르기도 한다. 여기서 oop 책쓰는 저자들이 자주 범하는 실수를 반복하고 싶지않다. 그저 object 로 표현 해놓았으니... 읽는 여러분이 그때 그때 상황을 보아 ... 잘 이해하기 바란다. 왜냐면 내가 실수로 잘못해놓으면 안그래도 오역들로 넘쳐나는 문서가 여러분에게 피해를 가중시키기 때문이다. Figure 1-5. Data Encoding ELFDATA2LSB ================================================================= ------------ |0 | | | 0x01 | 01 | | | | | ------------ ------------------------ |0 |1 | | | | 0x0102 | 02 | 01 | | | | | | | ------------------------ ------------------------------------------------ |0 |1 |2 |3 | | | | | | 0x01020304 | 04 | 03 | 02 | 01 | | | | | | | | | | | ------------------------------------------------ ================================================================= ELFDATA2LSB는 2의 보수값(2's complement values)를 표현하며, Least Significant Byte 는 lowest address를 차지하게 됨을 알수있다. Figure 1-6. Data Encoding ELFDATA2MSB ================================================================= ------------ |0 | | | 0x01 | 01 | | | | | ------------ ------------------------ |0 |1 | | | | 0x0102 | 01 | 02 | | | | | | | ------------------------ ------------------------------------------------ |0 |1 |2 |3 | | | | | | 0x01020304 | 01 | 02 | 03 | 04 | | | | | | | | | | | ------------------------------------------------ ================================================================= % 이러한 식으로 이루어진다고 한다. -_-;; c calling convension 문서를 보신 분들은 알겠지만 i386은 ELFDATA1LSB를 취한다. 맞나 -_-;; 맞을것이다. 그래도 의심스럽다면 ... C 로 프로그램을 작성하여 덤프해보자. ////////////////////////by edward////////////////////////////////////////////// #hex dump hexeditor test1.o #dumped screen File test1.o ASCII Offset : 0x00000000 / 0x000002E9 00000000 7F 45 4C 46 01 01 .... .......... ........... .ELF........... 6번째 byte는 e_ident array 의 6번째 바이트로 01 을 나타내고 있군요. EI_DATA(data encoding)는 ELFDATA2LSB 를 나타내는군요. /////////////////////////////////////////////////////////////////////////////// - EI_VERSION : e_ident[EI_VERSION]은 ELF header version number를 나타낸다. 현재 이값은 EV_CURRENT 값을 갖는다. 저 위에서 긁어왔음. ===================================== Name Value Meaning ===================================== EV_NONE 0 Invalid versionn EV_CURRENT 1 Current version ===================================== ////////////////////////by edward////////////////////////////////////////////// #hex dump hexeditor test1.o #dumped screen File test1.o ASCII Offset : 0x00000000 / 0x000002E9 00000000 7F 45 4C 46 01 01 01 .. .......... ........... .ELF........... 7번째 byte는 e_ident array 의 7번째 바이트로 01 을 나타내고 있군요. EI_VERSION(file version)는 EV_CURRENT 를 나타내는군요. /////////////////////////////////////////////////////////////////////////////// - EI_PAD : EI_PAD값은 사용되지 않는 바이트의 시작점을 표시하며, 이 값은 reserved 상태이며, 0 으로 set 되어있다. 프로그램은 object file을 읽을때 이 값을 무시한다. 그리고 EI_PAD 값은 지금은 안쓰지만 앞으로는 바뀌게 될것이다. ////////////////////////by edward////////////////////////////////////////////// #hex dump hexeditor test1.o #dumped screen File test1.o ASCII Offset : 0x00000000 / 0x000002E9 00000000 7F 45 4C 46 01 01 01 00 .......... ........... .ELF........... 8번째 byte는 e_ident array 의 8번째 바이트로 00 을 나타내고 있군요. EI_PAD(start of padding bytes)는 0를 나타내는군요. /////////////////////////////////////////////////////////////////////////////// %지금까지 elf ident(e_ident)에 대해서 보았습니다. 대충 맞는거 같죠... 1.7 Sections object file의 section header table은 파일내의 모든 section을 한곳에 위치시킨다. 그리고 section header table은 Elf32_Shdr 라는 구조를 갖는다. ============================================ # source : linux/include/linux/elf.h 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; % 아무튼 ELF 는 참 고마운것 같다. 리눅스 커널처럼 이리저리 왔다갔다 하지 않아도 되게 한파일에 다 정리를 해놓으니 얼마나 좋은가 분석하는 입장에서 -_-;; ============================================ Figure 1-3 재방송2. ELF Header ====================================================== #source : /linux/include/linux/elf.h #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; ======================================================= section header table index 는 아래와 같이 배열되어 있다. ELF header의 e_shoff member는 file의 시작부터 section header table 까지의 byte offset 을 갖는다. e_shnum은 section header table 에 몇개의 entry 가 포함되어 있는지 알려주며, e_shentsize 는 각각의 entry의 byte size를 나타낸다. 몇몇 section header table index는 reserved 상태이다. object file 은 이러한 special section index를 위한 section을 갖지 않을것이다. Figure 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 : 이 값은 undefined, missing, irrelevant 또는 meaningless section reference 에 대해 나타낸다. 예를들어 , symbol이 section number(SHN_UNDEF)로 정의되었다면 undefined symbol 이다. - SHN_LORESERVE : SHN_LORESERVE 값은 reserverd index의 범위중 lower bound를 표현한다. - SHN_LOPROC through SHN_HIPROC: 이 값들은 processor-specific sematic 을 위해 reserved 되어있는 포괄적인 범위의 값이다. - SHN_ABS : SHN_ABS 값은 corresponding reference를 위한 절대값을 나타낸다. 예를들어, SHN_ABS 절대값을 갖고, relocation에 의해 영향을 미치지 않는 symbol 정의를 표현한다. - SHN_COMMON : SHN_COMMON 은 symbol이 마치 FORTRAN_COMMON 또는 할당되지 않은 C external variable 같이 정의됨을 나타낸다. - SHN_HIRESERVE : SHN_HIRESERVE 값은 reserved index 범위의 upper bound 값을 갖게된다. 시스템은 SHN_LORESERVE와 SHN_HIRESERVE사이에 index를 reserve한다. 이 값은 section header table을 참조하지 않으며, 이는 section header table 이 reserved index를 위한 entry 들을 포함 하지 않음을 의미한다. section은 ELF header,program header table, section header table을 제외한 object file 에 대한 모든 정보를 포함할뿐만 아니라, object file의 section들은 몇가지 조건들을 충족시킨다. * object file의 모든 section 들은 정확히 하나의 section header로 묘사된다. * 각각의 section 들은 파일 내에서 순차적으로 이어진 byte 이다. * 파일안에 section들은 중복되지 않는다. * Object file 은 inactive space 를 갖는다. section header 는 다음과 같은 구조를 갖는다. Figure 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_name은 section name을 갖는다. 정확히 말하면 이 값은 section header string table 에 대한 index를 갖는다. - sh_type sh_type은 section의 contents와 semantics로 분류한다. section type과 type에 대한 description은 아래에 나온다. - sh_flags Section들은 갖가지 속성을 묘사하는 1-bit flag를 지원한다. flag에 대해서는 아래에 나온다. - sh_addr 만약 section이 process의 memory image를 나타낼것이라면, sh_addr에는 section의 첫번째 byte 주소가 주어지고, 아니라면 sh_addr에는 0 값을 갖게된다. - sh_offset sh_offset은 file의 시작점에서 부터 section의 첫바이트 까지의 byte offset 값을 갖는다. 아래에 묘사된 SHT_NOBITS 같은 하나의 section type은 파일에서 space를 차지하지 않는다. - sh_size sh_size는 section의 size를 byte로 나타낸다. section type이 SHT_NOBITS가 아니라면, section 은 파일에서 sh_size의 공간을 갖게된다. section type이 SHT_NOBITS일 경우 non-zero size를 갖게되지만, 그것이 파일내에서 공간을 차지하는것은 아니다. (스펙 자체도 너무 축약형태로 설명을 해놓으니 ... 일일이 무슨말인지 확인 작업을 하지 않으면 알수가 없겠군요. 대충보면 값은 0이 아니지만 0이 아닌 다른값이 파일내의 공간을 차지한다는 의미가 아니란건지 ...) - sh_link sh_link는 section type에 의존하는 interpretation을 위한 section header table index link를 갖는다. - sh_info sh_info는 section type에 의존하는 interpretation을 위한 extra information을 갖는다. - sh_addralign 어떤 section들은 address alignment 상태를 갖는다. 예를들어, 한 section이 doubleword를 갖는다면, 시스템은 전체 section을 위해 doubleword alignment 를 지키게 된다. sh_addr 값은 '0'과 '2^양의정수' 값을 갖게 된다. 0 과 1 의 의미는 section이 alignment 대한 제약을 받지 않는다는 의미이다. - sh_entsize 어떤 section들은 symbol table과 같은 고정된 크기의 table 엔트리들을 갖는다 sh_entsize는 어떤 한 section을 위한 각각의 entry의 크기를 byte로 나타낸다. 이 값이 0이라면, section 은 고정된 크기의 table entry들을 갖지 않는다는 것이다. section header의 sh_type 가 나타내는 section's semantics ============================================ Figure 1-9. Section Types, sh_type ============================================ Name Value SHT_NULL 0 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 ============================================ ////////////////////////////////by edward//////////////////////////////////// ELF MAP 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 # unsigned char e_ident[16] 00000000 MAG0 MAG1 MAG2 MAG3 CLASS DATA VERSION PAD .. .. .. .. NIDENT 00000010 [e_type ] [e_machine] [ e_version ] [ e_entry ] [ e_phoff ] 00000020 [ e_shoff ] [ e_flags ] [e_ehsize] [e_phentsize] [e_phnum][e_shentsize] 00000030 [e_shnum][e_shstrndx]