2013-02-04 4 views
1

Foo라는 새로운 언어 용 컴파일러를 설계하고 작성했다고 가정합니다. 그 중 장점은 컴파일러 구현에 특히 유용하기위한 것입니다. 고전적인 접근법은 컴파일러의 첫 번째 버전을 C로 작성한 후이를 사용하여 Foo에서 두 번째 버전을 작성한 후 자체 컴파일합니다.크로스 플랫폼 컴파일러 부트 스트랩

이것은 원본의 백업 복사본 만 보관해야하는 대부분의 프로그램과는 달리 바이너리의 백업 복사본을 유지해야한다는 것을 의미합니다. 언어가 첫 번째 버전에서 멀어지면 바이너리의 모든 복사본을 잃어 버리면 현재 버전을 컴파일 할 수 없습니다. 그러면 그렇게 해.

그러나 Linux와 Windows를 모두 지원한다고 가정합니다. 실제로 두 플랫폼 모두에서 실행되는 한 각 플랫폼에서 문제없이 컴파일 할 수 있습니다. 그러나 한 플랫폼에서 바이너리를 잃어버린다면 (또는 공격자가 침입했다고 의심 할만한 이유가있는 경우); 지금 문제가 있습니다. 그리고 지원되는 모든 플랫폼에 대해 바이너리를 보호해야한다는 점이 내가 느끼는 것보다 적어도 하나 더 많은 오류 지점입니다.

한 가지 해결책은 크로스 컴파일러로 만들어 두 플랫폼에서 바이너리가 두 플랫폼 모두를 대상으로 할 수 있도록하는 것입니다.

이진 출력 형식을 선택하는 데 문제가 없지만 각 플랫폼은 C 헤더 파일 형태로 시스템 API를 제공합니다. 시스템 API는 일반적으로 고유 플랫폼에만 존재합니다. Windows stdio.h에 대해 컴파일 된 보증 코드가 Linux 바이너리 형식으로 컴파일 된 경우에도 Linux에서 작동합니다.

아마도이 문제는 Linux 헤더 파일을 Windows 상자에 다운로드하고 Windows 바이너리를 사용하여 Linux 바이너리를 크로스 컴파일하면 해결할 수 있습니다.

누락 된 해결책이있는주의 사항이 있습니까?

또 다른 해결책은 Foo를 이식 가능한 C로 컴파일하고 메인 Foo 컴파일러가 필요로하는 언어의 하위 집합 만 받아들이고 최소한의 오류 검사 및 최적화를 수행하지 않고 별도의 최소 부트 스트랩 컴파일러를 Python에서 유지하는 것입니다. 따라서 부트 스트랩 컴파일러는 후속 언어 버전 전반에 걸쳐 유지 보수가 비용이 많이 들지 않을 정도로 간단하게 유지됩니다.

다시 말씀 드리지만 해결책이 누락되었습니다.

과거에이 문제를 해결하기 위해 사람들은 어떤 방법을 사용 했습니까?

+1

정말 문제입니까? 분명히 해결책은 "원래 소스 코드를 유지 보수하기 위해 리비전 컨트롤을 사용하는 것"입니다. –

+1

왜 바이너리를 잃어 버릴 까 걱정하지? 아직도 원래 소스가 있니? 그리고 Foo 컴파일러가없는 시스템에서 컴파일러를 부트 스트랩 할 수 있도록 원래의 C 소스 코드를 배포해야합니다. –

+0

시간이 지남에 따라 언어는 컴파일러의 원래 C 버전이 더 이상 이해할 수없는 방식으로 발전 할 것이기 때문에. – rwallace

답변

3

이것은 C 컴파일러 자체의 문제입니다. 일반적으로 제안 된대로 교차 컴파일러를 사용하여 해결됩니다.

컴파일러를 크로스 컴파일하는 과정은 다른 프로젝트를 크로스 컴파일하는 것보다 어렵지 않습니다. 즉, 원하는 것보다 더 까다 롭지 만 불가능한 것은 아닙니다.

물론 크로스 컴파일러가 필요합니다. 이것은 아마도 빌드 구성 시스템의 주요 수술을 의미하며 대상 (헤더, 라이브러리, 빌드에서 참조해야하는 모든 것)에서 가져온 일종의 "sysroot"가 필요합니다.

그래서 결국 컴파일러의 구조에 따라 다릅니다. 이력 소스를 사용하여 다시 부트 스트랩하는 것이 더 쉬워졌으며 처음부터 통과 한 언어 호환성의 각 단계를 반복하거나 크로스 컴파일러 구성을 구현하는 것이 더 쉽습니다. 나는 여기에서 당신에게 말할 수 없다.

GCC 컴파일러는 수년 동안 항상 정확히이 표준을 준수하는 C 코드로만 작성되었습니다. 즉, 해당 시스템의 네이티브 C 컴파일러 만 있으면 모든 OS에서이 코드를 생성 할 수 있기를 원합니다. 2012 년에만 C++가 이제 충분히 널리 퍼져서 컴파일러 자체가 작성 될 수 있다고 결정되었습니다. 그렇다하더라도, 그들은 자신들을 언어의 일부분으로 만 인정하고 있습니다. 앞으로 GCC를 C++이 아닌 플랫폼으로 이식하기를 원한다면 크로스 컴파일러 나 첫 번째 포트 GCC 4.7 (마지막 주요 C 전용 버전)을 사용해야하고 최신 버전으로 이동해야합니다. .

또한 GCC 빌드 프로세스는 빌드 된 컴파일러를 "신뢰"하지 않습니다. "make"를 입력하면, 먼저 자신의 축소 버전을 빌드하고, 그 다음 전체 버전 빌드를 사용합니다. 마지막으로 전체 버전을 사용하여 정식 버전을 다시 작성하고 두 바이너리를 비교합니다. 두 개가 일치하지 않으면 원래 컴파일러가 버그가 있음을 알고 잘못된 코드가 추가되어 빌드가 실패한 것입니다.