[OS] "동적연결 & 공유" 라이브러리

MeroZemory 님의 한마디 !

공유라이브러리는 가상메모리 상에서는 공유메모리영역에 Load되고, 이 영역은 32bit 운영체제 기준으로 0x80000000 부터 1GB이다. 공유메모리자체는 모든 프로세스가 각각 가지는 것이고, 실제 DLL이 로딩되는건 물리메모리에 한 번 올라간다.
각 프로세스의 공유메모리영역으로부터 저 물리메모리의 DLL 메모리에 매핑된다. ( 페이지 단위로 )
모든 프로세스가 해당 DLL을 해제하기 전까지 해당 DLL은 물리메모리 상에 유지된다.

 

 

 

 

공유 라이브러리가 필요한 이유는 무엇일까 ?

 A) Object 파일은 자체만으로 실행이 불가능하다.

     왜냐하면 printf의 구현코드를 모르기 때문이다 !

 

 

그러면 Object 파일을 실행시키고 싶다면 어떻게 해야할까 ?

 A) printf의 실행코드(또 다른 Object 파일)을 찾아서 Object 파일과 연결시켜줘야한다.

    우리는 이 작업을 Linker에 의한 Linking 작업이라고 말한다.

    동적 라이브러리가 아닌 정적 라이브러리는 printf의 실행코드를 Object 파일자체에 포함시킨다.

     ( 장,단점은 말 안해도 되겠지..? ) 

 

 

Dynamic Link는 라이브러리를 하나의 메모리공간에 매핑해 여러 프로세스에서 공유할 수있도록 한다. 

( 밑에 조금 더 구체적인 설명이 있으므로 아~ 그렇구나 하고 넘어가면된다 ! )

 

위 과정을 함수 호출시 Stub이 발생한다고 표현한다.

라이브러리를 어떻게 찾을 것인가를 알려주는 작은 코드조각이다.

 

 

Call printf@plt 라는 명령어가 실행되었을 때, CPU는 공유 메모리가 매핑되어있는 plt 테이블로 이동해 해당 Procedure의 주소로 이동하고자 한다. 그러나 printf라는 함수가 한 번도 호출된 적이 없으면 아직 got 테이블에 printf 함수의 실제주소가 아니라 실제주소를 알아내기위한 데이터가 들어있다.

 

printf라는 함수의 실제 주소를 알아낸 뒤 그 주소값을 got 테이블에 작성하고 printf를 호출한다.

이렇게 하면 이후에 printf 함수를 호출했을 떄에는 dl_resolve과정 없이 바로 printf의 함수를 참조할 수 있다.

 

이렇게 plt, got을 나누는 이유는 코드작성시 printf의 위치가 어디냐에 따라 실제 코드가 달라질 수 있는데, 이 때 코드의 일관성을 위해 plt라는 테이블을 거치는 것이다. ( maybe.... ) 

 

 

 

핵심 정리 !

실제로 가상메모리기법이 적용되어서 System Library의 공유가 이루어지는데, 각 프로세스는 이 라이브러리들이 각자의 메모리에 존재한다고 생각하지만, 실제로는 물리메모리의 한 부분을 사상한다. ( Read-Only )

이 때 plt는 Text Section에 위치하고, 실제 got에 들어오는 Procedure의 코드들은 스택과 힙의 사이에 위치하게 된다. 해당 코드들이 그 사이에 위치하는 것처럼 느끼는것 뿐이지 실제로는 물리메모리의 한 부분을 사상한다는 것이다.