2013-09-26 7 views
0

공유 라이브러리를 이해하려고합니다. 내가 아는 바로는 공유 라이브러리는 기본 주소가 0이므로 실행 중 임의의 주소에로드 될 수 있으므로 런타임 또는로드 시간 동안 변수가 올바르게 재배치됩니다. 따라서 라이브러리를로드하기 전에 모든 심볼에 라이브러리의 기본 부분이 제공됩니다. 따라서 기존의 라이브러리를 조사해보고 하나의 라이브러리를 만들려고했습니다. 그러나 나는 약간의 차이점을 발견했다. libc.so의 경우 다음과 같습니다.공유 라이브러리에 주소 할당

$ objdump -D /lib64/libc.so.6 

    /lib64/libc.so.6:  file format elf64-x86-64 


    Disassembly of section .note.gnu.build-id: 

    0000003b47a00270 <.note.gnu.build-id>: 
     3b47a00270: 04 00     add $0x0,%al 
     3b47a00272: 00 00     add %al,(%rax) 
     3b47a00274: 14 00     adc $0x0,%al 
     3b47a00276: 00 00     add %al,(%rax) 
     3b47a00278: 03 00     add (%rax),%eax 
    [More contents...] 

내가 아는 바로는 엘프 헤더가 약간의 공간을 차지한다는 것입니다. 하지만 그렇게하더라도 0에서 0x3b47a00270까지 주소를 차지하지 않습니다. 그래서, 나는 (-fPIC 및 -shared 플래그를 사용하여) 내 자신의 라이브러리를 생성하고 나는이 보았다

$ objdump -D ./libvector.so 
./libvector.so:  file format elf64-x86-64 


Disassembly of section .note.gnu.build-id: 

00000000000001c8 <.note.gnu.build-id>: 
1c8: 04 00     add $0x0,%al 
1ca: 00 00     add %al,(%rax) 
1cc: 14 00     adc $0x0,%al 
1ce: 00 00     add %al,(%rax) 
1d0: 03 00     add (%rax),%eax 
[More contents...] 

이 하나가 주소의 측면에서 더 합리적인 것입니다. .note.gnu.build-id는 0x1c8에서 시작합니다. 그렇다면 libpthread 나 libpthread와 같은 다른 기존 라이브러리의 경우 왜 다른 경우입니까? 나는 fedora 18 x86_64를 사용하고 있습니다. 나는 이것이 사전 연결의 경우일지도 모른다라고 생각한다. 그러나 나는 그것이 미리 링크되는 것을 발견하는 방법 일지라도 확실하지 않다? 미리 감사 ...

답변

1

objdump -D /lib64/libc.so.6

당신은 코드를 포함하지 않는 부분을 분해한다. 자신이하는 일을 (아직) 이해하지 못했기 때문에 objdump -d을 고수하면 혼란 스럽습니다. 제로

위의 문이 잘못된 것처럼 내가 아는 바로는

, 공유 라이브러리는 기본 주소가 : 공유 라이브러리 가 제로로 자신의 기본 주소를 가질 수 있지만, 그들이 필요 없어 . 이 라이브러리는 사전 링크 되었기 때문에

이유는 libc의 또는 점 libpthread와 같은 기존의 다른 라이브러리의 경우, 경우

다르다. "man prelink"를 참조하십시오. here.

readelf -l으로 더 명확하게 볼 수 있습니다. 첫 번째 LOAD 세그먼트는 VirtAddr입니다.

사전 링크가없는 라이브러리의 경우 해당 주소는 0이됩니다. 사전 연결된 libc.so.6의 경우에는 0x3b47a00000이됩니다. 또한 RedHat 시스템은 2 주마다 prelink를 다시 실행하도록 설정되기 때문에 사전에 libc.so.6 주소가 변경 될 수 있습니다.

관련 문제