개체파일

Object file

오브젝트 파일은 컴파일 또는 어셈블리 프로세스 중에 소스 코드에서 컴파일러 또는 어셈블러에 의해 생성된 기계 코드 또는 바이트 코드, 기타 데이터 및 메타데이터를 포함하는 파일입니다. 생성된 기계 코드를 객체 코드라고 합니다.

객체 코드는 일반적으로 재배치 가능하며, 일반적으로 직접 실행할 수 없습니다. 객체 파일에는 다양한 형식이 있으며, 동일한 기계 코드를 다른 객체 파일 형식으로 패키징할 수 있습니다. 객체 파일은 공유 라이브러리처럼 작동할 수도 있습니다.

객체 파일이 포함할 수 있는 메타데이터는 링크 또는 디버깅을 위해 사용될 수 있으며, 여기에는 서로 다른 모듈 간의 심볼 교차 참조를 해결하기 위한 정보, 재배치 정보, 스택 풀림 정보, 코멘트, 프로그램 심볼, 디버깅 또는 프로파일링 정보가 포함됩니다. 기타 메타데이터는 컴파일 날짜 및 시간, 컴파일러 이름 및 버전, 기타 식별 정보를 포함할 수 있습니다.

"오브젝트 프로그램"이라는 용어는 적어도 1950년대부터 시작되었습니다.

프로그래머가 작성한 소스 프로그램을 대수적 표기와 유사한 언어로 번역하여 기계가 제작한 기계어 프로그램에 대한 자동 프로그래밍 용어.[1]

링커는 객체 코드를 필요에 따라 미리 컴파일된 시스템 라이브러리에서 하나의 실행 프로그램 또는 라이브러리 풀링으로 결합하는 데 사용됩니다.

개체 파일 형식

여러 가지 다른 객체 파일 형식이 있습니다. 원래 컴퓨터의 각 유형은 고유한 형식을 가지고 있었지만 유닉스와 다른 휴대용 운영 체제가 등장하면서 ELF와 COFF와 같은 일부 형식이 다른 종류의 시스템에서 정의되고 사용되었습니다.

일부 시스템은 직접 실행 가능한 형식과 링커에 의한 처리가 필요한 형식을 구분합니다. 예를 들어, OS/360 및 후속 시스템에서는 첫 번째 포맷을 로드 모듈(load module), 두 번째 포맷을 오브젝트 모듈(object module)이라고 부릅니다. 이 경우 파일의 형식은 완전히 다릅니다.[2] 또한 DOS와 Windows에는 실행 파일과 객체 파일에 대한 파일 형식(예: 32비트 및 64비트 Windows의 실행 파일에 대한 휴대용 실행 파일 및 COFF)이 다릅니다.

유닉스와 유닉스 계열의 시스템들은 원래의 a.out 형식을 시작으로 실행 파일과 객체 파일에 동일한 형식을 사용해 왔습니다. 일부 형식에는 다양한 프로세서에 대한 기계 코드가 포함될 수 있으며, 프로그램이 로드될 때 운영 체제에서 올바른 코드를 선택합니다.[3][4]

객체 파일 형식의 설계 및/또는 선택은 전체 시스템 설계의 핵심적인 부분입니다. 그것은 링커의 성능에 영향을 미치고 따라서 프로그램이 개발되는 동안 프로그래머가 턴어라운드합니다. 형식이 실행 파일에 사용되는 경우, 설계는 프로그램이 실행되기 시작하는 데 걸리는 시간, 따라서 사용자의 응답성에도 영향을 미칩니다.

GNU Project의 BFD 라이브러리(Binary File Descriptor Library)는 객체 파일을 다양한 형식으로 조작하기 위한 공통 API를 제공합니다.

절대 파일

많은 초기 컴퓨터 또는 소형 마이크로컴퓨터는 절대 객체 형식만 지원합니다. 프로그램은 재배치할 수 없습니다. 미리 정의된 특정 주소에서 실행되도록 조립하거나 컴파일해야 합니다. 파일에는 재배치 또는 연결 정보가 없습니다. 이러한 파일은 읽기/쓰기 메모리에 로드하거나 읽기 전용 메모리에 저장할 수 있습니다. 예를 들어 Motorola 6800 MIKBUG 모니터에는 종이 테이프에서 절대 객체 파일(SREC Format)을 읽는 루틴이 포함되어 있습니다.[5] DOS COM 파일은 절대 객체 파일의 보다 최근의 예입니다.[6]

분할

대부분의 객체 파일 형식은 데이터의 개별 섹션으로 구성되며 각 섹션에는 특정 유형의 데이터가 포함됩니다. 이러한 섹션은 이전에는 일반적인 메모리 관리 형태였던 "메모리 세그먼트"라는 용어로 인해 "세그먼트"로 알려져 있습니다. 로더에 의해 프로그램이 메모리에 로드되면 로더는 프로그램에 메모리의 다양한 영역을 할당합니다. 이러한 영역 중 일부는 개체 파일의 섹션에 해당하므로 일반적으로 동일한 이름으로 알려져 있습니다. 스택과 같은 다른 것들은 런타임에만 존재합니다. 실제 메모리 주소를 지정하기 위해 로더(또는 링커)에 의해 재배치가 수행되는 경우도 있습니다. 그러나 많은 프로그램이나 아키텍처의 경우 메모리 관리 유닛이나 위치 독립 코드에 의해 처리되기 때문에 재배치가 필요하지 않습니다. 일부 시스템에서는 추가 처리 없이 객체 파일의 세그먼트를 메모리로 복사(페이지)하여 실행할 수 있습니다. 이러한 시스템에서, 이것은 게으르게, 즉 예를 들어 객체 파일에 의해 백업되는 메모리 매핑 파일을 통해 실행 중에 세그먼트가 참조되는 경우에만 수행될 수 있습니다.

일반적인 개체 파일 형식에서 지원되는 데이터 유형:[7]

상이한 객체 파일들 내의 세그먼트들은 세그먼트들이 정의될 때 지정된 규칙들에 따라 링커에 의해 결합될 수 있습니다. 객체 파일 간에 공유된 세그먼트에 대한 규칙이 존재합니다. 예를 들어, 도스에는 특별한 세그먼트의 이름과 결합 가능 여부를 지정하는 다양한 메모리 모델이 있습니다.[8]

디버깅 정보의 디버깅 데이터 형식은 COFF와 같이 객체 파일 형식의 필수적인 부분이거나, stabs나 DWARF와 같은 여러 객체 형식과 함께 사용될 수 있는 반독립적인 형식일 수 있습니다.

참고 항목

참고문헌

  1. ^ Wrubel, Marshal H. (1959). A primer of programming for digital computers. New York, USA: McGraw-Hill. p. 222. Retrieved 2020-07-31.
  2. ^ IBM OS Linkage Editor and Loader (PDF). IBM Corporation. 1973. p. 16. Retrieved 2012-08-06.
  3. ^ "Universal Binaries and 32-bit/64-bit PowerPC Binaries". OS X ABI Mach-O File Format Reference. Apple Inc. 2009-02-04 [2003]. Archived from the original on 2014-09-04.
  4. ^ "FatELF: Universal Binaries for Linux". Retrieved 2020-08-02.
  5. ^ Wiles, Mike; Felix, Andre. MCM6830L7 MIKBUG/MINIBUG ROM (PDF). Motorola Semiconductor Products, Inc. Retrieved 2020-07-31.
  6. ^ Godse, Deepali A.; Godse, Atul P. (2008). Microprocessor (1 ed.). Pune, India: Technical Publications. pp. 3–15. ISBN 978-81-8431-355-0.
  7. ^ Mauerer, Wolfgang (2010). "Appendix E. The ELF Binary Format". Professional Linux Kernel Architecture. John Wiley & Sons. p. Appendix E. ISBN 978-0-470-34343-2. Retrieved 2020-08-01.
  8. ^ Irvine, Kip R. (1993). Assembly language for the IBM-PC (2 ed.). New York, USA: Macmillan. ISBN 0-02-359651-1.

더보기