LD_ASSUME_KERNEL

출처 :http://people.redhat.com/drepper/assumekernel.html

 

ExplainingLD_ASSUME_KERNEL

Ulrich Drepper, 2004-5-12

It is frightening how something as simple as the mechanism behindLD_ASSUME_KERNELcan create that much confusion. So here are a few details which should enable everybody to investigate the issue closer by her/himself.

1. First,LD_ASSUME_KERNELis handled by the dynamic linker.

2. The behavior of a specific value ofLD_ASSUME_KERNELisnothardcoded in the dynamic linker.

3. Every DSO (Dynamic Shared Object, aka shared library) can tell the dynamic linker in glibc which minimum OS ABI version is needed. NB: dynamic linkers other than glibc's do not have this feature. The information about the minimum OS ABI version is encoded in a ELF note section usually named.note.ABI-tag. This note section must be referenced by aPT_NOTEentry in the DSO's program header.

   To examine the content of a DSO's note section use thereadelfprogram fromelfutils(the version frombinutilsis not capable enough). On Red Hat system the binary is calledeu-readelf. Using it on a Fedora Core 2 system shows the following:

   $ eu-readelf -n /lib/tls/libc-2.3.3.so Note segment of 32 bytes at offset 0x174: Owner Data size Type GNU 16 VERSION OS: Linux, ABI: 2.4.20

   This means the/lib/tls/libc-2.3.3.soDSO requires at least OS ABI version 2.4.20.

4. The specific ABI version requirements on a RHL9, and Fedora Core 1 and 2 system are as follows (NB: this implies IA-32 is the architecture):

   • DSOs in/lib/tlsneed ABI version 2.4.20.

   • DSOs in/lib/i686need ABI version 2.4.1.

   • DSOs in/libneed ABI version 2.2.5.

   This means noLD_ASSUME_KERNELsetting requesting versions earlier than 2.2.5 will work at all. Versions from 2.2.5 to 2.4.0 will use the DSOs in/lib, versions from 2.4.1 to 2.4.19 will use the DSOs in/lib/i686, versions 2.4.20 and younger will use the DSOs in/lib/tls.

   For the Red Hat releases this layout was chosen to provide the maximum amount of backward compatibility forbrokenapplications (correctly written applications have no problems anyway). The code in/libconsists of the very early LinuxThreads code which had fixed size threads which could not be placed by the application. The version in/lib/i686is the LinuxThreads code which does away with this limitation (aka floating stacks). The code in/lib/tlsis the new NPTL POSIX thread library.

5. The fact that a DSO has a more stringent version requirement does not mean it is automatically chosen. The dynamic only rejects loading DSOs based on the version information, it does not look for the best fit. The above description is true because the dynamic linker always looks in the directories/lib/tls,/lib/i686, and/libin this order. Why this is the case is complicated and not explained here. Read the dynamic linker source code.

6. For architectures other than IA-32 the situation is similar, but less complicated. In RHEL3 only two versions of glibc are needed, one using LinuxThreads and one using NPTL. The very old LinuxThreads code is not needed.

 

 

출처 :http://sung-ho.pe.kr/newhp/?p=19893

 

dynamic linker에 의해 사용되어지는 환경변수
(즉, dynamic linker에 hardcode되어있지않다)

모든 DSO는 dynamic linker가 사용하는 glibc의 최소 OS ABI버젼을 알려줄수있다.
(DSO 내부 header에 기록되어있음)

$ eu-readelf -n /lib/tls/libc-2.3.3.so Note segment of 32 bytes at offset 0x174: Owner Data size Type GNU 16 VERSION OS: Linux, ABI: 2.4.20

2.2.5 이하는 LD_ASSUME_KERNEL이 설정 안되어있어도 문제없고 이상의 버젼은 해당 위치의 DSO를 참조한다. (Redhat layout)
(하위 호환때문)
  DSOs in /lib/tls need ABI version 2.4.20. (NPTL POSIX thread library)
  DSOs in /lib/i686 need ABI version 2.4.1. (LinuxThreads code which does away with this limitation (aka floating stacks))
  DSOs in /lib need ABI version 2.2.5. (very early LinuxThreads code)

dynamic linker는 항상 /lib/tls, /lib/i686, /lib 순으로 찾아본다.

DSO는 엄격한 버젼을 요구하지만 자동으로 선택되어지지는 않는다.
dynamic linker는 오직 DSO의 버젼정보에 의해 reject시킨다.

IA-32 이외의 architecture에서도 이와 유사하다. RHEL3는 오직 2가지 버젼의 glibc만 필요하다. (LinuxThreads 와 NPTL. old LinuxThreads는 필요없음)