┗System∑Sec†ion┛

[ ELF 헤더 출력 ]

헤더 종류

옵션

긴 옵션

ELF 파일 헤더

-h

--file-header

프로그램 헤더

-l (엘)

--program-headers, --segments

섹션 헤더

-S

--section-headers, --sections

위 세가지 헤더

-e

--headers

[ ELF 정보 출력 ]

종보 종류

옵션

긴 옵션

심볼 테이블

-s

--syms, --symbols

재배치 정보

-r

--relocs

동적 세그먼트

-d

--dynamic

버전 섹션

-V

--version-info

아키텍처 의존정보

-A

--arch-specific

버킷 리스트 길이 히스토그램

-I(아이)

--histogram

모든 헤더 및 정보

-a

--all

코어 노트(core notes)

-n

--notes

unwind 정보

-u

--unwind

▷ 일반적으로 심볼 정보는 심볼 섹션에 있는 심볼 정보를 이용하지만,

-D 옵션 (--use-dynamic 옵션)을 사용하면 동적 섹션에 있는 심볼 정보를 이용하게 됨.

[ ELF 섹션 덤프 ]

▷ -x 옵션 (--hex-dump 옵션)을 이용해 지정한 섹션의 내용을 덤프.

(섹션은 섹션 번호로 표시하고, -S 옵션으로 출력된 섹션 헤더에 섹션 번호가 표시된다.)
 

▶ 사용 예)

[ DWARF2 디버그 섹션 출력 ]

▷ -w 옵션(--debug-dump 옵션)으로 DWARF2 디버그 섹션 정보를 출력.

-w

--debug-dump=

섹션

l

line

.debug_line

i

info

.debug_info

a

abbrev

.debug_abbrev

p

pubnames

.debug_pubnames

r

aranges

.debug_aranges

R

Ranges

.debug_ranges

m

macro

.debug_macinfo

f

frames

.debug_frame

F

frames-interp

.debug_frame

s

str

.debug_str

o

loc

.debug_loc

[ 긴 이름의 심볼 출력 ]

▷ -W 옵션 (--wide 옵션)을 사용하면 80문자 이상의 행도 출력이 가능

(기본적으로 긴 이름의 심볼은 1행 이내에 출력되도록 뒷부분이 잘린다.)

♧ 공유 라이브러리 의존관계란,

실행 파일 또는 공유 라이브러리에서 필요로 하는 공유 라이브러리의 SONAME이

ELF 정보 내의 동적 섹션에 있는 NEEDED에 기록된 정보로 관리되고 있음을 의미한다.

[ objdump 와 readelf로 공유 라이브러리 의존 관계 확인 ]

♧ 공유 라이브러리를 이용할 때, 실행 파일 또는 공유 라이브러리 자체는

이를 실행 하려 할 때 필요한 공유 라이브러리에 대한 정보를 갖고 있다.

▷ 그 정보는 ELF 동적 섹션의 NEEDED에 기록.

▶ [/bin/ls]를 objdump/readelf 명령을 사용하여 확인

objdump -p ::

readelf -d ::

▷ 이와 같이 /bin/ls는 [librt.so.1, libselinux.so.1, libacl.so.1, libc.so.6]

4개의 공유 라이브러리를 필요로 함.

▷ 그러나 /bin/ls 실행할 때 이 4개의 공유 라이브러리만 필요한 것은 아니다.

(4개의 공유 라이브러리는 각각의 또 다른 공유 라이브러리를 필요로 하기 때문.)

▷ NEEDED로 표시되 어 있는 것은 SONAME이므로, SONAME으로부터 실제 파일을 찾아야 한다.

▷ 특히 설정되어 있지 않은 경우에는

/usr/lib(또는 /lib)에 SONAME에 해당하는 파일이 공유 라이브러리다.

(실제로는 /lib/tls 또는 /lib/tls/i686/cmov 등에 있는 공유 라이브러리가 사용 되기도 함)

▷ 환경변수 LD_LIBRARY_PATH에 라이브러리 경로를 설정한 경우 해당 디렉토리를 참조.

▷ /etc/ld.so.cache에 기록 정보를 참조.

(/etc/ld.so.conf의 설정을 이용해 ldconfig를 실행할 때 갱신)

▷ 예를 들어 [ librt.so.1 ]의 경우, /lib/librt.so.1이라는 파일(심볼릭 링크)이 존재하므로,

이것이 SONAME librt.so.1에 해당하는 공유 라이브러리 파일이다.

▶ [ librt.so.1 ]이 필요로 하는 라이브러리 확인.

...(중략)...

▶ [ /bin/ls ]의 다른 공유 라이브러리도 의존 관계를 확인.

(※ 공유 라이브러리 의존관계는 CPU종류, OS 배포판에 따라 조금씩 다르다.)

[ ldd로 공유 라이브러리 의존 관계 확인 ]

♧ 앞에서 살펴본 바와 같이 objdump / readelf를 사용해 공유 라이브러리 의존 관계를 확인할 수는

있지만, 각각의 공유 라이브러리에 대한 의존관계를 개별적으로 확인해야 하므로 다소 번거롭다.

또한 실제 실행될 때 사용되는 공유 라이브러리의 디렉토리 경로를 정확히 얻기도 어렵다.

▶ ldd로 공유 라이브러리 의존 관계 확인.

(※ ldd는 실행 파일 외에도 공유 라이브러리에도 사용 가능)

- 이와 같이 실행파일이 필요로 하는 공유 라이브러리의 SONAME, 경로명과 할당된 메모리 주소를 확인.

▷ 사실 GNU/리눅스에서 ldd 명령은 단순히

환경변수(LD_TRACE_LOADED_OBJECTS)를 이용한 셸 스크립트이다.

▷ LD_TRACE_LOADED_OBJECTS에 1을 설정해서 프로그램을 실행하면 프로그램 실행 시점에

ELF 인터프리터(런타임 로더 /lib/ld_linux.so.2)가 필요한 공유 라이브러리를 찾아

메모리에 로딩해서 그 정보를 표시한 후, 실제 프로그램이 실행되기 전에 종료하게 된다.

▶ LD_TRACE_LOADED_OBJECTS를 이용한 공유 라이브러리 의존성 확인.

- 이와 같이 ldd와 동일한 결과를 얻을 수 있다.

▷ LD_TRACE_LOADED_OBJECTS는 실행 파일이 아닌 공유 라이브러리에의 경우 실행할 수 없다.

▷ 이런 경우에는 런타임 로드 /lib/ld-linux.so.2를 실행한다.

[ 정적 라이브러리 (static library) ]

♧ 정적 라이브러리는 여러 프로그램에서 사용되는 함수를 포함하는

오브젝트 파일을 하나의 파일로 다룰 수 있도록 정리해 놓은 것.

▷ 프로그램을 작성할 때는 소스 파일을 분류해서 일정한 분량으로 나누어

각각의 오브젝트 파일로 컴파일 한 후, 이를 최종적으로 링크해서 하나의 실행 가능한 파일을 생성한다.

이때 다른 프로그램에서도 사용될 만한 모듈이 여러 개의 오브젝트 파일로 나뉘어 있으면

이것들을 한 덩어리로 다루기가 번거로워진다. 그래서 생각해낸 것이 아카이브 파일이다.

▷ archive(아카이브) 파일(.a) - 여러 개의 오브젝트 파일을 하나의 파일로 모아놓은 것.

▷ ar(1) 명령을 사용해 여러 개의 오브젝트 파일을 하나의 아카이브 파일로 합칠 수 있다.

▷ OS에 따라 ranlib(1)를 사용하면 이 아카이브 파일 내의 오브젝트가 제공하는 심볼 정보를 해시화해서,

심볼을 제공하는 오브젝트 파일을 효율적으로 검색할 수 있게 된다. (ar -s와 같음)

이와 같은 아카이브 파일을 정적 라이브러리라 한다.

▶ 정적라이브러리 생성

ⓐ 오브젝트 파일 생성.

ⓑ 아카이브 파일로 묶어 줌 / 확인.

ⓒ 실행 가능한 파일 생성

▷ 정적 라이브러리를 링크할 경우,

링커는 다른 오브젝트 파일에서 정의되지 않은 심볼을 찾아 지정된 정적 라이브러리에서

해당 심볼을 정의하고 있는 오브젝트 파일의 사본을 추출해서 실행 파일 내에 포함.

▷ 이 경우에는 baz.o 내에 정의되지 않은 심볼이

libfoo.a에 포함되어 있는 오브젝트 파일들 중에 정의되어 있다면,

그 오브젝트 파일을 찾아 실행 파일 baz에 복사해서 링크 한다.

▷ 여기서 핵심은 라이브러리 내의 오브젝트 파일 단위로 처리된다는 점,

링크 시에는 실행 파일 내에 오브젝트 파일의 사본이 포함된다는 점.

▷ 정적 라이브러리를 링크해서 생성된 실행 바이너리를 실행할 경우에는

정적 라이브러리가 없어도 관계 없다. 필요한 코드는 실행 바이너리에 복사되어 포함되기 때문.

[ 공유 라이브러리 (shared library) ]

♣ 정적 라이브러리의 경우 여러 오브젝트 파일의 아카이브였다면, 공유 라이브러리는

여러 오브젝트 파일을 하나의 거대한 오브젝트 파일로 만들어 이를 공유할 수 있도록 한 것.

- OS의 가상 메모리 관리 시스템이 진보함에 따라, 하나의 파일을 mmap(2)등을 이용해

여러 프로세스에서 메모리를 공유해서 참조할 수 있게 되었다.

이를 활용할 수 있도록 한 것이 공유 라이브러리(or 공유 오브젝트)이다.

(최근의 OS에서는 일단 메모리맵을 설정해 두는 것만으로 실제로 그 메모리 내용이 참조되기까지

디스크 액세스를 지연시킬 수 있으므로, 거대한 오브젝트 파일이라도 그다지 문제가 되지 않는다.)

▶ 공유 라이브러리 생성

-shared옵션 : 공유 오브젝트를 만들게 된다.

-Wl,-soname옵션 : 공유 오브젝트에 특정 SONAME을 지정.

(SONAME에 따라 실행 시에 링크할 공유 라이브러리가 결정)

▷ 공유 라이브러리는 정적 라이브러리와 같은 방법으로 링크 할 수 있다.

- 그러나 실제 내부적인 처리는 많이 다르다.

- 이 경우 baz.o 내에 정의되지 않은 심볼이 공유 오브젝트에 정의되어 있다면,

해당 공유 오브젝트의 SONAME을 실행 파일의 NEEDED에 설정할 뿐,

공유 오브젝트에 포함되어 있는 코드 자체를 복사하지는 않는다.

(정적 라이브러리와 달리 *.so 내에 어떤 오브젝트 파일이 있는지는 기본적으로 남지 않는다)

- 여기서 핵심은 공유 라이브러리 단위로 처리된다는 점,

링크 시에는 필요한 공유 라이브러리의 SONAME만을 실행 파일에 NEEDED로 등록해 둔다는 점이다.

- 공유 라이브러리를 링크한 실행 파일을 실행할 경우에는 동적 링커 로더가

NEEDED의 정보를 이용해 필요한 공유 라이브러리를 찾아내어,

실행 시에 해당 프로세스의 메모리맵을 조작해서 공유 라이브러리를

링크한 실행 파일을 실행할 경우에는 공유 라이이브러리가 시스템에 반드시 존재해야 한다.

실제 라이브러리 코드는 실행 파일에 포함되어 있지 않고 공유 라이브러리에만 존재.

(※ /etc/ld.so.conf 수정, ldconfig)

[ 라이브러리 차이점]

♣ 메모리 크기

▷ 실행 시에 필요한 메모리 크기도, 최근의 OS에서는 공유 라이브러리 쪽이 유리.

▷ 특히 PIC(Position Independent Code)로 생성해 두면 코드 부분이 어느 주소에 위치하더라도

변경할 필요가 없기 때문에, 공유 라이브러리를 하나의 물리적인 메모리 페이지에 읽어 들이는 것만으로

각각의 메모리 공간에 있는 프로세스에서 공유 라이브러리의 메모리 페이지를 공유 할 수 있게 된다.