GCC -fPIC 옵션

코드 생성 규칙 에 대한 GCC의 옵션에 대해 읽었 지만 "PIC (위치 독립적 코드 생성)"의 기능을 이해할 수 없습니다. 그것이 무엇을 의미하는지 설명하는 예를 들어주십시오.

위치 독립적 인 코드는 생성 된 기계 코드가 작동하기 위해 특정 주소에있는 것에 의존하지 않음을 의미합니다.

예를 들어 점프는 절대가 아닌 상대적인 것으로 생성됩니다.

의사 조립 :

PIC : 코드가 100 또는 1000인지에 관계없이 작동합니다.

100: COMPARE REG1, REG2
101: JUMP_IF_EQUAL CURRENT+10
...
111: NOP

비 PIC : 코드가 주소 100 인 경우에만 작동합니다.

100: COMPARE REG1, REG2
101: JUMP_IF_EQUAL 111
...
111: NOP

편집 : 의견에 대한 답변.

코드가 -fPIC으로 컴파일 된 경우 라이브러리에 포함하기에 적합합니다. 라이브러리는 메모리의 원하는 위치에서 다른 주소로 재배치 할 수 있어야합니다. 라이브러리가 선호하는 주소에 이미로드 된 라이브러리가있을 수 있습니다.

나는 이미 말한 것을 더 간단한 방법으로 설명하려고 노력할 것입니다.

공유 라이브러리가로드 될 때마다 로더 (실행중인 모든 프로그램을로드하는 OS의 코드)는 객체가로드 된 위치에 따라 코드의 일부 주소를 변경합니다.

위의 예에서 비 PIC 코드의 "111"은 처음로드 될 때 로더에 의해 작성됩니다.

공유 객체가 아닌 경우 컴파일러가 해당 코드에서 일부 최적화를 수행 할 수 있기 때문에이를 원할 수 있습니다.

공유 객체의 경우 다른 프로세스가 해당 코드에 "링크"하려는 경우 동일한 가상 주소로 해당 프로세스를 읽어야합니다. 그렇지 않으면 "111"이 의미가 없습니다. 그러나 가상 공간은 이미 두 번째 프로세스에서 사용 중일 수 있습니다.

공유 라이브러리에 내장 된 코드는 일반적으로 위치 독립적 인 코드 여야하므로 공유 라이브러리를 메모리의 모든 주소에 쉽게로드 할 수 있습니다. 이 -fPIC옵션은 GCC가 그러한 코드를 생성하도록합니다.

더 추가 중 ...

모든 프로세스는 동일한 가상 주소 공간을 갖습니다 (리눅스 OS에서 플래그를 사용하여 가상 주소의 임의 추출이 중지 된 경우 )

따라서 공유 링크가없는 하나의 exe 인 경우 (가설 시나리오), 우리는 항상 동일한 가상 주소를 동일한 asm 명령에 해를 끼치 지 않을 수 있습니다.

그러나 공유 객체를 exe에 연결하려면 공유 객체가 링크 된 순서에 따라 공유 객체에 할당 된 시작 주소를 확신하지 못합니다. 연결되는 프로세스에 따라 다른 가상 주소.

따라서 하나의 프로세스는 자체 가상 공간에서 0x45678910으로 시작 주소를 지정할 수 있으며 동시에 다른 프로세스는 0x12131415의 시작 주소를 제공 할 수 있으며 상대 주소 지정을 사용하지 않으면 전혀 작동하지 않습니다.

따라서 항상 상대 주소 지정 모드와 fpic 옵션을 사용해야합니다.

동적 라이브러리의 함수에 대한 링크는 라이브러리가로드되거나 런타임에 해결됩니다. 따라서 프로그램 실행시 실행 파일과 동적 라이브러리가 모두 메모리에로드됩니다. 고정 주소가 동일한 주소를 요구하는 다른 동적 라이브러리와 충돌 할 수 있으므로 동적 라이브러리가로드되는 메모리 주소를 미리 결정할 수 없습니다.

이 문제를 처리하기 위해 일반적으로 사용되는 두 가지 방법이 있습니다.

1. 재배치. 필요한 경우 실제로드 주소에 맞게 코드의 모든 포인터와 주소가 수정됩니다. 재배치는 링커와 로더에 의해 수행됩니다.

2. 위치 독립적 코드. 코드의 모든 주소는 현재 위치를 기준으로합니다. 유닉스 계열 시스템의 공유 객체는 기본적으로 위치 독립적 인 코드를 사용합니다. 특히 32 비트 모드에서 프로그램을 장시간 실행하는 경우 재배치보다 효율성이 떨어집니다.

" 위치 독립적 코드 " 라는 이름은 실제로 다음을 의미합니다.

• 코드 섹션에는 재배치가 필요한 절대 주소가 아니라 자체 상대 주소 만 있습니다. 따라서 코드 섹션을 임의의 메모리 주소에로드하고 여러 프로세스간에 공유 할 수 있습니다.

• 데이터 섹션은 종종 쓰기 가능한 데이터를 포함하므로 여러 프로세스간에 공유되지 않습니다. 따라서 데이터 섹션에는 재배치가 필요한 포인터 나 주소가 포함될 수 있습니다.

• Linux에서 모든 공용 함수 및 공용 데이터를 대체 할 수 있습니다. 주 실행 파일의 함수가 공유 객체의 함수와 이름이 같은 경우 main에서 호출 할 때뿐만 아니라 공유 객체에서 호출 할 때 main의 버전이 우선합니다. 마찬가지로 main의 전역 변수가 공유 객체의 전역 변수와 이름이 같으면 공유 객체에서 액세스 할 때도 main의 인스턴스가 사용됩니다.

이 소위 기호 삽입은 정적 라이브러리의 동작을 모방하기위한 것입니다.

공유 객체에는이 "재정의"기능을 구현하기 위해 프로 시저 연결 테이블 (PLT)이라는 함수에 대한 포인터 테이블과 전역 오프셋 테이블 (GOT)이라는 변수에 대한 포인터 테이블이 있습니다. 함수 및 공용 변수에 대한 모든 액세스는이 테이블을 통과합니다.

ps 동적 연결을 피할 수없는 경우 위치 독립적 인 코드의 시간 소모적 인 기능을 피할 수있는 다양한 방법이 있습니다.

이 기사에서 더 많은 내용을 읽을 수 있습니다 : http://www.agner.org/optimize/optimizing_cpp.pdf

이미 게시 된 답변에 약간의 추가 사항 : 위치 독립적으로 컴파일되지 않은 객체 파일은 재배치 가능합니다. 재배치 테이블 항목이 포함되어 있습니다.

이러한 항목을 사용하면 로더 (프로그램을 메모리에로드하는 코드 비트)가 가상 주소 공간의 실제로드 주소에 맞게 절대 주소를 다시 쓸 수 있습니다.

운영 체제는 동일한 공유 객체 라이브러리에 연결된 모든 프로그램과 메모리에로드 된 "공유 객체 라이브러리"의 단일 복사본을 공유하려고합니다.

코드 주소 공간 (데이터 공간의 섹션과 달리)이 인접 할 필요는 없으며 특정 라이브러리에 링크 된 대부분의 프로그램은 상당히 고정 된 라이브러리 종속성 트리를 가지므로 대부분의 경우 성공합니다. 드물지만 불일치가있는 경우에는 메모리에 공유 객체 라이브러리의 사본이 두 개 이상 필요할 수 있습니다.

분명히, 프로그램 및 / 또는 프로그램 인스턴스 사이에서 라이브러리의로드 주소를 무작위 화하려고 시도하면 (이용 가능한 패턴을 만들 가능성을 줄이기 위해) 시스템이이 기능을 활성화 한 경우는 드물지 않습니다. 모든 공유 객체 라이브러리를 컴파일하려는 모든 시도가 위치 독립적이되도록해야합니다.

기본 프로그램 본문에서 이러한 라이브러리에 대한 호출도 재배치 가능하게되므로 공유 라이브러리를 복사해야 할 가능성이 훨씬 줄어 듭니다.