Automotive Software

ELF 파일 포맷 - gABI

AutoSW — Sun, 29 Mar 2026 02:59:33 +0900

Generic ABI에서는 ELF의 기본 구조를 정의하고 있는데 그중 주요 구성 요소를 정리하면,

구성 요소	구조 위치	주요 목적	핵심 구성 / 필드	실행 역활
Section	Section Header Table 기반	링크/재배치 단위	.text, .data, .bss, .rodata, .symtab, .rel.*	직접 사용 안 함
Segment	Program Header Table 기반	실행 로딩 단위	PT_LOAD, PT_DYNAMIC, PT_INTERP	메모리에 로드됨
Symbol Table	Section (.symtab, .dynsym)	심볼 관리	name, value(addr), size, type, binding	함수/변수 주소 해석
Relocation	Section (.rel., .rela.)	주소 수정	offset, type, symbol index, addend	로딩 시 주소 재계산
Dynamic Linking	Segment (PT_DYNAMIC)	런타임 링크	.dynamic, .got, .plt	shared lib 연결
Hash Table	Section (.hash, .gnu.hash)	심볼 검색 최적화	bucket, chain	심볼 lookup 속도 향상
실행 파일 구조	ELF 전체	실행 진입점	ELF Header + Segment	프로세스 생성

Section (링커 관점에서의 구조로 컴파일/링크 단계에서만 중요)

Section Header : name, type, flags(R/W/X), addr, offset, size

대표 Section

Section	역활
.text	코드
.data	초기화된 데이터
.bss	미초기화 데이터
.rodata	읽기 전용 데이터
.symtab	전체 심볼
.dynsym	동적 심볼
.rel/.rela	relocation 정보

Segment (실행 관점에서의 구조로 물리적인 로딩 단위 / OS 로더가 사용)
- Segment Header : type, offset, vaddr, memsz, flags (R/W/Z)
- 대표 Segment
  
  타입 의미
  
  PT_LOAD 메모리에 로드
  
  PT_DYNAMIC 동적 링크 정보
  
  PT_INTERP 인터프리터 경로
  
  PT_PHDR Program Header 자체
Symbol Table
- 심볼 명을 주소로 매핑
  
  타입 의미
  
  st_name 문자열 테이블 인덱스
  
  st_value 주소
  
  st_size
  
  st_info type + binding
  
  st_shndx 소속 section
  
  .symtab 전체 심볼
  
  .dynsym 동적 링크용
Relocation
- 주소 수정(재배치) 명령 리스트
- REL : Offset, info
- RELA : Offset, info, addend (추가값)
Dynamic Linking
- 구성요소
  
  요소 역활
  
  .dynamic dynamic table (DT_NEEDED, DT_SYMTAB, DT_STRTAB, DT_RELA)
  
  .got Global Offset Table
  
  .plt Procedure Linkage Table
  함수 호출 trampoline
Hash Table : 심볼 검색 최적화

Ref.
- https://thelinuxcode.com/understanding_elf_file_format/
- https://jeffjerseycow.github.io/2017/12/what-are-the-got-and-plt-pt1

ELF 파일 포맷 기초

AutoSW — Sun, 29 Mar 2026 01:06:49 +0900

ELF (Executable and Linkable Format)은 유닉스 기반 시스템에서 구동되는 한 애플리케이션의 실행, 객체 코드 그리고 공유 라이브러리등의 데이터를 묶어 놓은 표준화된 바이너리 파일 포맷으로, 하나의 포맷같이 보이지만, 실제로는 gABI + psABI + osABI의 조합으로 구성되어 확장 가능한 컨테이너 포맷으로 해당 애플리케이션의 구동관련 정보를 포함

ELF = Generic ABI (gABI, 공통 표준) + Processor-specific ABI (psABI, CPU 별 확장) + osABI (OS 별 확장)
- gABI
  - 공통적인 구조 정의, System V Application Binary Interface (1971년 4.1 버전 이휴 변경 없음)
  - ELF 포맷의 기본 구조 정의
  - Section / Segment / Symbol Table / Relocation / Dynamic Linking / Hash Table / 실행 파일
- psABI
  - CPU별 ELF 동작 규칙, 지속적인 업데이트 중
    - x86-64 ps ABI, ARM ELF ABI, RISC-V ELF ps ABI
    - CPU 아키텍쳐별 규칙 정의
    - calling convention, 레지스터 사용, 재배치 타입 등
- osABI
  - OS 동작 방식 정의, 지속적인 업데이트 중
    - 같은 코드 Linux용 컴파일시, Syscall/Loader가 상이하여 구동불가 이유
  - OS가 ELF에 추가하는 규칙
    - Linux ABI, QNX ABI, FreeBSD ABI 등
    - System call 인터페이스, Dynamic Link 동작, Shared library 규칙 등
ELF 포맷의 기본 구조
- ELF Header
- Program Header Table (Segment 기반, 실행 관점)
- Section Header Table (Section 기반, 링크 관점)
- 실제 데이터 (코드/데이터)
ELF Header 주요 필드
- Magic (0x7F 'ELF')
- Class (32/64-bit)
- Endianness
- OS ABI
- Type (ET_EXEC, ET_DYN 등)
- Entry poin
Segment 와 Section 구분

구분 Segment Section (컴파일의 결과)

목적 실행 링크/재배치

단위 LOAD segment .text, .data 등

사용 시점 로딩/실행 컴파일/링크
주요 ELF 타입

타입 의미

ET_REL Relocatable (.o)

ET_EXEC Executable

ET_DYN Shared Object (.so, PIE), 최근 ASLR 대응을 위해 많이 사

ET_CORE Core dump

XCP Granularity

AutoSW — Thu, 12 Mar 2026 18:58:55 +0900

ODT 엔트리(DAQ로 전송할 신호)의 “크기 단위(step)”를 바이트로 선언하는 파라미터
Granularity는 “버스에 실리는 ODT 엔트리 데이터의 최소 단위(패킹 단위)”
- 슬레이브 내부의 구조체 정렬/크기와는 별
마스터는 각 엔트리의 길이를 이 단위의 배수로 패킹.
구현 관점(슬레이브 스택)
- 슬레이브가 보장해야 할 것
  - GET_DAQ_PROCESSOR_INFO/GET_DAQ_RESOLUTION_INFO 등에서 Granularity의 일관성
  - 측정 데이터 읽기 시, 마스터가 패딩해온 레이아웃에 맞춰 정확한 오프셋에서 복사.
  - 언알라인드 접근이 위험한 플랫폼은 내부 복사 시 안전한 로딩 경로 사용(memcpy 또는 정렬된 임시 버퍼).
- 안전한 로드/스토어
  - C에서 직접 캐스팅 로드를 피하고, 크기별 안전 복사 함수를 사용.
  - 주변장치 레지스터는 문서화된 정렬로만 접근(8/16bit windows 등).
- DTO 빌더의 패킹 로직
  - 마스터가 Granularity 단위로 패킹한다고 가정하지만, 슬레이브 자체가 데이터 소스를 읽어 DTO 버퍼에 채울 때도 동일 규칙 준수
- 성능
  - memcpy를 많이 쓰면 CPU 부하↑.
  - 가능하면 같은 정렬의 신호를 같은 ODT로 묶어 패딩 손실과 복사 비용 모두를 최소화.
  - DMA 사용 시 버퍼 정렬과 캐시 일관성 확보.
- 에러 처리
  - MAX_ODT_ENTRY_SIZE_DAQ 초과 시 명확한 에러 리턴.
  - 지원하지 않는 크기/정렬 요청에 대한 에러 코드 및 이벤트 로깅.

동적 DAQ(Dynamic DAQ) 전송

AutoSW — Fri, 6 Mar 2026 04:11:39 +0900

1. 전송 활성화 및 시작 절차

설정된 지도를 바탕으로 데이터를 송출하기 위한 마지막 3단계

① SET_DAQ_LIST_MODE (모드 설정)

이 명령은 특정 DAQ 리스트 동작 방식 정의

주요 설정 값: 전송 방향(DAQ), 타임스탬프 포함 여부, 전송 주기(Event Channel)
패킷 예시: [0xE0] [0x01] [0x00 0x00] [0x01 0x00] [0x01] [0x00]
- 0xE0: CMD (SET_DAQ_LIST_MODE)
- 0x01: Mode (타임스탬프 활성화 등)
- 0x00 0x00: DAQ List 번호 (#0)
- 0x01 0x00: Event Channel 번호 (데이터를 추출할 시점/주기)

② START_STOP_DAQ_LIST (개별 준비)

설정된 DAQ 리스트를 "전송 대기(Selecting)" 상태로 전환

패킷 예시: [0xDE] [0x01] [0x00 0x00]
- 0xDE: CMD (START_STOP_DAQ_LIST)
- 0x01: Mode (0x01 = Start / Select)
- 0x00 0x00: DAQ List 번호 (#0)

③ START_STOP_SYNCH (일괄 시작)

대기 중인 모든 DAQ 리스트를 동시에 시작(Synchronous Start)시킵니다. 이 명령이 떨어지는 순간부터 ECU는 데이터 전송 시작

패킷 예시: [0xDD] [0x01]
- 0xDD: CMD (START_STOP_SYNCH)
- 0x01: Mode (0x01 = Start all selected)

2. 실제 전송되는 데이터 프레임 (DTO)

모든 명령 완료시, ECU는 설정된 Event Channel 주기마다 DTO 포맷의 패킷을 전송

[최종 전송 패킷 분석 (앞서 설정한 RPM/Temp 기준)]

| Hex 값 | 00 | 55 66 | B8 0B 5A |

| 의미 | ODT #0 | 시간 정보 (예: 26201 ticks) | RPM(3000) + 온도(90) |

ID Field: ALLOC_ODT 단계에서 할당된 절대적 또는 상대적 번호
Timestamp Field: SET_DAQ_LIST_MODE시 타임스탬프 활성화 여부에 따라 결정
Data Field: ALLOC_ODT_ENTRY에서 정의한 2개의 데이터(3바이트)가 순서대로 배치

3. 전체 흐름 요약 (Sequence)

Configuration: FREE_DAQ → ALLOC_... → WRITE_DAQ (데이터 지도 작성)
Activation: SET_DAQ_LIST_MODE (타임스탬프/주기 설정)
Preparation: START_STOP_DAQ_LIST (전송할 리스트 선택)
Execution: START_STOP_SYNCH (실제 데이터 전송 시작)

동적 DAQ(Dynamic DAQ) 설정

AutoSW — Fri, 6 Mar 2026 03:58:24 +0900

마스터(PC)가 슬레이브(ECU)의 메모리 리소스를 효율적으로 할당하고, 읽어올 데이터의 지도를 그리는 과정

1. 동적 DAQ 설정 6단계 절차

설정은 보통 FREE_DAQ -> ALLOC_DAQ -> ALLOC_ODT -> ALLOC_ODT_ENTRY -> SET_DAQ_PTR -> WRITE_DAQ 순으로 진행

동적 DAQ 설정은 '큰 바구니(DAQ) -> 작은 바구니(ODT) -> 그 안의 칸막이(ODT Entry)'를 만드는 과정

순서	명령어 (CMD)	값 (Hex)	설명
1	FREE_DAQ	D6	기존 모든 DAQ 구성을 초기화
2	ALLOC_DAQ	D5 00 01 00	DAQ 리스트를 1개(0x0001) 할당
3	ALLOC_ODT	D4 00 00 00 01	DAQ #0에 ODT를 1개(0x01) 할당
4	ALLOC_ODT_ENTRY	D3 00 00 00 02	DAQ #0의 ODT #0에 2개의 Entry(데이터 칸) 생성
5	SET_DAQ_PTR	E2 00 00 00 00	편집할 지점을 'DAQ #0, ODT #0, Entry #0'으로 지정
6	WRITE_DAQ	E1 01 02 00 [Addr]	Entry #0에 RPM(2바이트) 주소 설정 (포인터 자동 증가)
7	WRITE_DAQ	E1 01 01 00 [Addr]	Entry #1에 Temp(1바이트) 주소 설정

2. 실제 패킷 예시 (데이터 2개 읽기)

가정:

데이터 1: 엔진 RPM (주소: 0x12345678, 크기: 2바이트)
데이터 2: 냉각수 온도 (주소: 0x1234567A, 크기: 1바이트)
설정 대상: DAQ 리스트 #0, ODT #0

① SET_DAQ_PTR (포인터 지정)

"DAQ #0의 ODT #0, 그 안의 0번 자리에 데이터를 정의하겠다"라고 선언합니다.

Packet: [0xE2] [0x00] [0x00] [0x00] [0x00] (CMD, Reserved, DAQ_L, ODT, Element)

② WRITE_DAQ (RPM 매핑)

"그 자리에 2바이트짜리 RPM 주소를 넣겠다"는 명령

Packet: [0xE1] [0x01] [0x02] [0x00] [78 56 34 12] (CMD, Bitmask, Size, Address)

③ WRITE_DAQ (Temp 매핑)

다음 위치(Element 1)에 1바이트짜리 온도 주소 배정 (포인터는 자동으로 다음으로 넘어감)

Packet: [0xE1] [0x01] [0x01] [0x00] [7A 56 34 12] (CMD, Bitmask, Size, Address)

3. 설정 완료 후 전송되는 DTO 프레임 구조

설정이 끝나고 START_STOP_DAQ_LIST 명령으로 측정을 시작시, ECU는 다음과 같은 DTO 패킷 전송

[실제 데이터 패킷 예시]

PID (ODT 번호): 0x00 (Absolute 모드 가정)
Timestamp: 0x0001 (2바이트 가정)
Data: RPM(0x0BB8 = 3000), Temp(0x5A = 90도)

ID Field (1B)	Timestamp Field (2B)	Data Field (3B)
00	01 00	B8 0B 5A

ID Field: 이 데이터가 ODT #0번임을 나타내는 PID 값
Timestamp Field: 데이터가 생성된 시점의 타이머 값
Data Field: 설정한 순서대로 RPM(2B)과 온도(1B)가 연속 배치

XCP DAQ : 동기화 데이터 전송 모델

AutoSW — Mon, 5 Jan 2026 22:30:33 +0900

슬레이브 메모리, ODT 그리고 DAQ 리스트 연관관계

DTO 패킷 (DAQ 와 STIM 에 사용)

Identification Field		Timestamp Field	Data Field
PID (DAQ = 0x00 ... 0xFB)	DAQ 리스트 번호 (상대적 ODT 경우)	데이터 전송 또는 샘플링 시간	실제 측정값 ODT 정의된 순서에 따라
02		2B 1A	B8 0B 2D 87

절대적 ODT vs 상대적 ODT

구분	Absolute ODT	Relative ODT
식별자 구성	오직 PID (1 Byte)	PID + DAQ List Number
ODT 번호 성격	시스템 전체의 고유 번호	특정 DAQ 리스트 내의 순번
최대 ODT 개수	최대 251개 (DAQ 기준)	이론상 수만 개 가능
통신 효율	높음 (식별 필드가 짧음)	낮음 (식별 필드가 길어짐)
언제 쓰는가?	소규모/중규모 데이터 측정 시	대규모/복잡한 데이터 측정 시

DAQ 로 사용될 경우 (슬레이브 --> 마스터)
- PID 는 0x00 <= DAQ <= 0xFB 내의 ODT 번호
- ODT 번호는 데이터 필드에 담겨질 수집된 데이터 요소를 정의
STIM으로 사용될 경우 (마스터 --> 슬레이브)
- PID는 0x00 <= STIM <= 0xBF 내의 ODT 번호
- ODT 번호는 데이터 필드에 담겨질 제어(STIM) 데이터 요소를 정의
DAQ : Data AcQuisition
- 슬레이브 메모리상의 데이터 개체 --> 동기화된 방식으로 전송 ---> 마스터
개체 기술표 (ODT ; Object Description Table)
- 동기화된 데이터 전송 개체들과 슬레이브 메모리간의 매핑 정보를 기술
- 다중 ODT entry들을 하나의 ODT로 그룹화
  - 동적 DAQ 리스트를 사용할 경우 : 최대 ODT Entry (MAX_ODT_ENTRIES) 의 수는 0으로 기록
  - 정적 DAQ 리스트를 사용할 경우 : 최대 ODT Entry (MAX_ODT_ENTRIES) 의 수는 해당 DAQ 리스트에 포함되는 ODT 중 가장 많은 ODT Entry 갯수를 표시
패킷 아이디 (PID ; Packet IDentifier)
- ODT에 기술된 개체들의 내용을 식별하는데 사용되는 ID
이벤트 채널 (Event Channel)
- XCP는 동시에 활성화된 다중 DAQ 리스트들을 허용 --> 각 DAQ 리스트별 샘플링과 전송은 슬레이브상의 개별 이벤트에 의해 처리
DAQ 방식

구분	CTO 명령			DTO 명령
구분	DAQ 리스트 개수 생성 (ALLOC_DAQ)	각 DAQ 리스트 별 ODT 개수 할당 (ALLOC_ODT, ALLOC_ODT_ENTRY)	ODT에 담을 변수 정의 (SET_DAQ_PTR, WRTIE_DAQ 등)	데이터 전송
정적 DAQ	사전 정의	사전 정의	런타임 정의	런타임 정의
동적 DAQ	런타임 정의	런타임 정의	런타임 정의	런타임 정의

정적 DAQ (Static DAQ) : DAQ 리스트 형태 사전 정의 --> 런타임시 ODT 변수 정의 필요 !!!
1. 초기화 : FREE_DAQ (0xD6)-기존에 설정된 모든 DAQ 내용을 초기화합니다. (구조는 유지)
2. 포인터 설정 : SET_DAQ_PTR (0xE2)00 00 00 01"DAQ 리스트 0번의 0번 ODT, 1번 Entry를 가리켜라"
3. 주소 기입 (내용물 채우기) : WRITE_DAQ (0xF2)04 00 12 34 56 78"방금 지정한 곳에 0x12345678 주소의 4바이트 데이터를 담아라"
4. 시작 : START_STOP_DAQ_LIST (0xDE)01 00 00 ..."0번 DAQ 리스트를 시작(Select)해라"
동적 DAQ (Dynamic DAQ) : 가용 HEAP 크기만 전달 후 DAQ 리스트 형태 런타임 정의 --> 런타임시 ODT 변수 정의
1. 초기화 : FREE_DAQ (0xD6)-동적 DAQ에서는 기존 할당된 모든 메모리를 해제합니다.
2. 리스트 할당 : ALLOC_DAQ (0xD5)00 0A"DAQ 리스트를 총 10개 생성해라"
3. ODT 할당 : ALLOC_ODT (0xD4)00 01 05"1번 DAQ 리스트 안에 ODT를 5개 만들어라"
4. Entry 할당 : ALLOC_ODT_ENTRY (0xD3)00 01 00 08"1번 DAQ의 0번 ODT에 데이터를 담을 칸(Entry)을 8개 만들어라"
5. 주소 기입 (내용물 채우기) : WRITE_DAQ (0xF2)04 00 11 22 33 44(이후 과정은 정적 DAQ와 동일
6. 시작 : START_STOP_DAQ_LIST (0xDE)01 00 00 ..."0번 DAQ 리스트를 시작(Select)해라"

프로토콜 활성화

AutoSW — Mon, 29 Dec 2025 22:30:16 +0900

Wireshark에서 특정 프로토콜 (예, XCP)를 지원함에도 불구하고 화면 상에 해당 프로토콜이 표시되지 않는 경우는 해당 프로토콜에 대한 설정을 추가해 주어야 한다.

편집 -> 설정 -> Protocols -> XCP
- XCP -> UDP/TCP Mapping -> 편집
- + 버튼을 클릭하여 IP 주소, 프로토콜, 포트 등을 추가

와이어샤크 업데이트 (우분투)

AutoSW — Mon, 29 Dec 2025 16:44:19 +0900

Advanced Update (Using Wireshark PPA for Latest Versions)

Open Terminal. Press Ctrl + Alt + T

Add Wireshark Stable PPA:

bash

sudo add-apt-repository ppa:wireshark-dev/stable

Update Repository List:
bash
sudo apt update
Install/Upgrade Wireshark:
bash
sudo apt install wireshark

XCP 기초 (Universal Measurement and Calibration Protocol)

AutoSW — Mon, 29 Dec 2025 15:10:52 +0900

XCP는 차량 환경을 포함하는 임베디드 시스템에서 제어기의 특정 메모리 값이나 애플리케이션의 변수값을 거의 실시간으로 측정하고 필요시 수정할 수 있도록 ASAM 네트워킹 그룹에서 고안된 프로토콜로써, 이전 CAN 프로토콜만을 지원하던 CCP의 프로토콜 한계를 보완하여 Ethernet, Flexray 등의 다양한 통신 프로토콜을 지원하고 있다.

XCP 동작 구조
- 마스터(Master)-슬레이브(Slave) 구조로, 하나의 마스터가 여러 슬레이브 ECU에 연결 후 실시간 데이터를 제어 가능
XCP 데이터 베이스
- ASAM A2L 파일이라는 데이터베이스를 사용해 ECU 내부 변수의 물리적 주소와 데이터 타입을 관리
XCP 패킷
- CTO(Command Transfer Object) : 명령과 응답을 담당
- DTO(Data Transfer Object) : 실시간 데이터 전송을 담당
XCP 측정 (Measurement)
- 폴링 (Polling)
  - 정해진 주기에 따라 마스터가 전송 요청하고 슬레이브가 답하는 방식
- 동기화 데이터 전송 (Synchronous Data Transfer)
  - DAQ(Data Acquisition)
    - 슬레이브가 특정 주기나 이벤트 발생 시마다 마스터의 요청 없이도 데이터를 자동 전송
    - 효율적인 데이터 전송을 위해 ODT(Object Descriptor Table) 구조 적용 후 다중 변수를 단일 패킷으로 전송
  - STIM(Stimulation)
    - DAQ가 슬레이브 메모리상의 변수 측정을 위해 슬레이브에서 마스터로 데이터 전송
    - STIM은 슬레이브 메모리상의 변수값 자극(Stimulation)을 위해 마스터에서 슬레이브로 데이터 전송
XCP 보정 (Calibration)
- 마스터가 슬레이브의 메모리 값을 직접 수정하여 제어 로직의 파라미터를 실시간으로 변경하는 과정
XCP는 'Universal' 명칭과 같이 물리 계층(CAN, Ethernet, FlexRay 등)에 독립적으로 동작하는 프로토콜
이더넷 기반의 XCP on Ethernet은 높은 대역폭을 제공하여 수천 개의 신호를 수 밀리초() 단위로 동시 모니터링 가능
전송 계층과 표준 응용 계층의 독립화로, 하드웨어가 변경 여부와 무관하게 상위 소프트웨어의 재사용 가능

참고
- XCP 마스터 : https://github.com/christoph2/pyxcp
- XCP 슬레이브 : https://github.com/vectorgrp/XCPlite/tree/master
- https://www.vector.com/int/en/know-how/protocols/xcp-measurement-and-calibration-protocol/xcp-book/#

TCP/IP 프로토콜 테스트

AutoSW — Mon, 22 Apr 2024 05:08:32 +0900

테스트 프로토콜
- ARP : Address Resolution Protocol
- ICMPv4 : Internet Control Message Protocol Version 4
- IPv4 : Internet Protocol Version 4
- Dynamic configuration of IPv4 Link Local Address
- UDP : User Datagram Protocol
- DHCPv4 : Dynamic Host configuration Protocol Version 4 Client
- TCP : Transmission Control Protocol
테스트 항목
- 패킷 생성/수신
- 에러 처리
- 프로토콜 항목 (헤더, 체크섬, TTL) 검사 등
테스트 설정
- 하드웨어
- 소프트웨어
  - 테스트 대상
    - 테스트 대상이 될 프로토콜 스택
      - 클래식 오토사의 경우 (SD, TcpIp, EthIf 그리고 EthDrv)
      - 아답티브 오토사의 경우 (ara::com 그리고 POSIX 운영체제별 네트워크 스택)
    - 테스트 진행을 위해 필요한 AUTOSAR Testability 프로토콜 스택
  - 테스트 벤치
    - 테스트 진행을 위해 필요한 AUTOSAR Testability 프로토콜 스택
    - AUTOSAR Testability 프로토콜을 기반으로 하는 각 테스트 케이스별 스크립트

타입	의미
PT_LOAD	메모리에 로드
PT_DYNAMIC	동적 링크 정보
PT_INTERP	인터프리터 경로
PT_PHDR	Program Header 자체

타입	의미
st_name	문자열 테이블 인덱스
st_value	주소
st_size
st_info	type + binding
st_shndx	소속 section
.symtab	전체 심볼
.dynsym	동적 링크용

요소	역활
.dynamic	dynamic table (DT_NEEDED, DT_SYMTAB, DT_STRTAB, DT_RELA)
.got	Global Offset Table
.plt	Procedure Linkage Table 함수 호출 trampoline

구분	Segment	Section (컴파일의 결과)
목적	실행	링크/재배치
단위	LOAD segment	.text, .data 등
사용 시점	로딩/실행	컴파일/링크

타입	의미
ET_REL	Relocatable (.o)
ET_EXEC	Executable
ET_DYN	Shared Object (.so, PIE), 최근 ASLR 대응을 위해 많이 사
ET_CORE	Core dump