RealView Compilation Tools - ARM architectureinfocenter.arm.com/help/topic/com.arm.doc.dui0206ik/DUI... · † RealView Compilation Tools 컴파일러 참조 설명서 (ARM DUI 0348)

RealView � Compilation Tools버전 4.0

링커 사용 설명서

Copyright © 2002-2008 ARM Limited. All rights reserved.ARM DUI 0206IK

RealView Compilation Tools링커 사용 설명서

Copyright © 2002-2008 ARM Limited. All rights reserved.

릴리스 정보

이 설명서에서 변경된 내용은 다음과 같습니다.

소유권 고지 사항

이 소유권 고지 사항의 아래 부분에서 달리 명시되지 않는 한 � 또는 ™ 표시가 있는 단어와 로고는 EU, 대한민국 및 기타 국가에서 ARM Limited의 등록 상표 또는 상표입니다. 이 설명서에 언급된 기타 브랜드와 이름은 해당 소유자의 상표일 수 있습니다.

이 설명서에 포함된 전체 또는 일부 정보나 설명된 제품은 해당 저작권 소유자의 사전 서면 승인 없이는 어떤 형태로도 개조되거나 복제될 수 없습니다.

이 설명서에 설명된 제품은 지속적으로 개발 및 개선될 수 있습니다. 이 설명서에 포함된 모든 제품 명세와 해당 사용법은 ARM의 신뢰하에 제공됩니다. 그러나 ARM에서는 상품성 또는 특정 목적에의 적합성을 비롯하여 그 밖의 묵시적이거나 명시적인 모든 보증을 부인합니다.

이 설명서는 제품 사용자를 지원하는 용도로만 만들어졌습니다. ARM은 이 설명서 정보의 사용, 정보의 오류나 누락 또는 제품의 잘못된 사용에 따른 어떠한 손실이나 손상도 책임지지 않습니다.

ARM이라는 단어가 사용되는 경우 "ARM이나 해당하는 자회사"를 의미합니다.

변경 내역

날짜 발행판 기밀 상태 변경 내용

2002년 8월 A 기밀 문서 아님 릴리스 1.2

2003년 1월 B 기밀 문서 아님 릴리스 2.0

2003년 9월 C 기밀 문서 아님 ARM � RealView � Developer Suite 릴리스 2.0.1

2004년 1월 D 기밀 문서 아님 RealView Developer Suite용 릴리스 2.1

2004년 12월 E 기밀 문서 아님 RealView Developer Suite용 릴리스 2.2

2005년 5월 F 기밀 문서 아님 RealView Development Suite용 릴리스 2.2 SP1

2006년 3월 G 기밀 문서 아님 RealView Development Suite용 릴리스 3.0

2007년 3월 H 기밀 문서 아님 RealView Development Suite용 릴리스 3.1

2008년 9월 I 기밀 문서 아님 RealView Development Suite용 릴리스 4.0

ii Copyright © 2002-2008 ARM Limited. All rights reserved. ARM DUI 0206IKNon-Confidential Unrestricted Access

기밀 상태

이 설명서는 기밀 문서가 아닙니다. 이 설명서의 사용, 복사 및 공개 권한은 ARM과 설명서 사용 당사자의 동의하에 라이센스 제한을 받습니다.

액세스 제한 없음은 ARM의 내부 분류입니다.

제품 상태

이 설명서의 정보는 개발이 완료된 제품에 대한 최종 정보입니다.

웹 주소

http://www.arm.com

ARM DUI 0206IK Copyright © 2002-2008 ARM Limited. All rights reserved. iiiUnrestricted Access Non-Confidential

iv Copyright © 2002-2008 ARM Limited. All rights reserved. ARM DUI 0206IKNon-Confidential Unrestricted Access

목차RealView Compilation Tools링커 사용 설명서

서문설명서 정보 .................................................................................................. viii사용자 의견 .................................................................................................... xi

1 장 소개1.1 ARM 링커 개요 ............................................................................................ 1-21.2 레거시 객체 및 라이브러리와의 호환성 ...................................................... 1-5

2 장 ARM 링커 시작2.1 모델 연결 ..................................................................................................... 2-22.2 명령 행 옵션 사용 ........................................................................................ 2-7

3 장 기본 링커 기능 사용3.1 이미지 구조체 지정 ..................................................................................... 3-23.2 섹션 배치 ..................................................................................................... 3-83.3 섹션 제거 ................................................................................................... 3-113.4 피드백 ....................................................................................................... 3-143.5 RW 데이터 압축 ........................................................................................ 3-173.6 베니어 ....................................................................................................... 3-203.7 인라인 ....................................................................................................... 3-23

ARM DUI 0206IK Copyright © 2002-2008 ARM Limited. All rights reserved. vUnrestricted Access Non-Confidential

3.8 명령 행 옵션을 사용하여 단순 이미지 만들기 ........................................... 3-263.9 명령 행 옵션을 사용하여 C++ 예외 처리 .................................................. 3-323.10 이미지에 대한 정보 얻기 ........................................................................... 3-333.11 라이브러리 검색 , 선택 및 스캔 ................................................................ 3-36

4 장 이미지 기호 액세스4.1 ARM/Thumb 동의어 .................................................................................... 4-24.2 링커 정의 기호 액세스 ................................................................................ 4-34.3 다른 이미지의 기호 액세스 ......................................................................... 4-94.4 전역 기호 숨기기 및 이름 바꾸기 .............................................................. 4-124.5 $Super$$ 및 $Sub$$ 를 사용하여 기호 정의 재정의 ................................ 4-144.6 기호 버전 관리 .......................................................................................... 4-15

5 장 스캐터 로딩 설명 파일 사용5.1 스캐터 로딩 개요 ........................................................................................ 5-25.2 영역 및 섹션 주소 지정의 예제 ................................................................... 5-95.3 단순 이미지에 대한 해당 스캐터 로딩 설명 .............................................. 5-32

vi Copyright © 2002-2008 ARM Limited. All rights reserved. ARM DUI 0206IKNon-Confidential Unrestricted Access

서문

이 서문에서는 RealView Compilation Tools 링커 사용 설명서에 대해 소개합니다. 이 서문은 다음 단원으로 구성되어 있습니다.

• viii페이지의 설명서 정보

• xi페이지의 사용자 의견

ARM DUI 0206IK Copyright © 2002-2008 ARM Limited. All rights reserved. viiUnrestricted Access Non-Confidential

서문

설명서 정보

이 설명서에서는 ARM RealView � Compilation Tools와 함께 제공되는 ARM � 링커인 armlink에 대한 사용자 정보를 제공하며 명령 행 옵션에 대해서도 간략히 설명합니다. 명령 행 옵션, 조정 파일 명령, 스캐터 로딩 설명 파일, BPABI (기본 플랫폼 ABI) 및 SysV (System V 릴리스 4) 공유 라이브러리와 실행 파일에 대한 자세한 내용은 링커 참조 설명서를 참조하십시오.

대상 독자

이 설명서는 RealView Compilation Tools를 사용하여 응용 프로그램을 만드는 모든 개발자를 위한 것입니다. 여기에서는 사용자가 경험 있는 소프트웨어 개발자이고 RealView Compilation Tools 핵심 설명서에 설명된 ARM 개발 도구에 익숙하다고 가정합니다.

설명서 사용

이 설명서는 다음 장으로 구성되어 있습니다.

1장 소개

이 장에서는 링커 및 관련 입력/출력 파일에 대해 소개합니다.

2장 ARM 링커 시작

이 장에서는 링커에서 지원하는 연결 모델, 파일 명명 규칙 및 명령 행 옵션을 간략히 설명합니다.

3장 기본 링커 기능 사용

이 장에서는 이미지 구조체, 메모리 맵, 섹션 배치, 링커 최적화 및 라이브러리 파일 사용에 대해 간략히 설명합니다.

4장 이미지 기호 액세스

이 장에서는 링커 정의 기호 액세스, 조정 파일을 사용하여 출력 파일의 기호 이름을 관리하는 방법 및 기호 버전 관리에 대해 간략히 설명합니다.

5장 스캐터 로딩 설명 파일 사용

이 장에서는 스캐터 로딩 설명 파일 및 이 파일을 사용하여 간단하거나 복잡한 이미지의 메모리 맵을 지정하는 방법에 대해 간략히 설명합니다.

viii Copyright © 2002-2008 ARM Limited. All rights reserved. ARM DUI 0206IKNon-Confidential Unrestricted Access

서문

이 설명서에서는 ARM 소프트웨어가 기본 위치에 설치되어 있다고 가정합니다. 예를 들어 Windows의 경우 기본 위치는 volume:\Program Files\ARM일 수 있습니다. 예를 들어 install_directory\Documentation\...과 같은 경로 이름을 참조할 때 install_directory는 이 위치를 가리키는 것으로 가정합니다. ARM 소프트웨어를 다른 위치에 설치한 경우에는 이 위치를 변경해야 합니다.

표기 규칙

이 설명서에서는 다음과 같은 표기 규칙을 사용합니다.

monospace 명령, 파일 및 프로그램 이름, 소스 코드와 같이 키보드로 입력할 수 있는 텍스트를 나타냅니다.

monospace 명령 또는 옵션 대신 사용할 수 있는 약어를 나타냅니다. 밑줄이 그어진 텍스트는 전체 명령이나 옵션 이름 대신 입력할 수 있습니다.

monospace italic

명령 및 함수의 인수를 나타냅니다. 인수는 특정 값으로 대체할 수 있습니다.

고정 폭 굵은 글꼴

외부 예제 코드가 사용될 경우 언어 키워드를 나타냅니다.

기울임 글꼴 중요한 사항을 강조 표시하고, 특수 용어를 소개하며, 내부 상호 참조 및 인용 부분을 나타냅니다.

굵은 글꼴 메뉴 이름과 같은 인터페이스 요소를 강조 표시합니다. 적절한 경우 설명 목록의 내용을 강조할 때와 ARM 프로세서 신호 이름을 표시할 때도 사용됩니다.

추가 정보

이 단원에는 ARM 계열 프로세서용 코드를 개발하는 데 대한 추가 정보를 제공하는 ARM Limited 및 타사 게시물 목록이 나와 있습니다.

ARM Limited는 설명서의 내용을 정기적으로 업데이트하고 수정합니다. http://infocenter.arm.com/help/index.jsp에서 정오표, 추가 목록 및 ARM FAQ (질문과 대답)를 참조하십시오.

ARM DUI 0206IK Copyright © 2002-2008 ARM Limited. All rights reserved. ixUnrestricted Access Non-Confidential

서문

ARM 게시물

이 설명서에는 RealView Compilation Tools와 함께 제공되는 ARM 링커를 사용하는 방법에 대한 정보가 포함되어 있습니다. 이 제품군에 포함된 다른 게시물은 다음과 같습니다.

• RealView Compilation Tools 핵심 설명서 (ARM DUI 0202)

• RealView Compilation Tools 컴파일러 사용 설명서 (ARM DUI 0205)

• RealView Compilation Tools 컴파일러 참조 설명서 (ARM DUI 0348)

• RealView Compilation Tools 라이브러리 및 부동 소수점 지원 설명서 (ARM DUI 0349)

• RealView Compilation Tools 링커 참조 설명서 (ARM DUI 0381)

• RealView Compilation Tools 유틸리티 설명서 (ARM DUI 0382)

• RealView Compilation Tools 어셈블러 설명서 (ARM DUI 0204)

• RealView Compilation Tools 개발자 설명서 (ARM DUI 0203)

ARM에서 지원하는 기본 표준, 소프트웨어 인터페이스 및 기타 표준에 대한 자세한 내용은 install_directory\Documentation\Specifications\...를 참조하십시오.

또한 ARM 제품과 관련된 구체적인 내용은 다음 설명서를 참조하십시오.

• ARM 아키텍처 참조 문서, ARMv7-A™ 및 ARMv7-R™ edition (ARM DDI 0406)

• ARM7-M™ 아키텍처 참조 문서 (ARM DDI 0403)

• ARM6-M™ 아키텍처 참조 문서 (ARM DDI 0419)

• ARM 아키텍처 참조 문서 (ARM DDI 0100)

• 하드웨어 장치에 대한 ARM 데이터시트 또는 기술 참조 문서

x Copyright © 2002-2008 ARM Limited. All rights reserved. ARM DUI 0206IKNon-Confidential Unrestricted Access

서문

사용자 의견

RealView Compilation Tools와 해당 설명서에 대한 의견이 있으시면 ARM Limited에 알려 주시기 바랍니다.

RealView Compilation Tools에 대한 사용자 의견

RealView Compilation Tools와 관련된 문제가 있으시면 해당 공급업체에 문의하십시오. 문의 시 다음 사항을 함께 알려 주시면 보다 신속하고 유용한 답변을 받으실 수 있습니다.

• 사용자 이름 및 회사

• 제품 일련 번호

• 사용 중인 릴리스 정보

• 실행 중인 플랫폼의 세부 사항 (예: 하드웨어 플랫폼, 운영 체제 종류 및 버전)

• 문제를 재현하는 작은 독립 실행형 코드 샘플

• 의도한 결과와 실제로 발생한 결과에 대한 명확한 설명

• 사용한 명령 (명령 행 옵션 포함)

• 문제를 보여 주는 샘플 출력

• 도구의 버전 문자열 (버전 번호 및 빌드 번호 포함)

설명서에 대한 사용자 의견

이 설명서에 오류나 누락이 있으면 다음 사항을 기재하여 [email protected]으로 전자 메일을 보내 주시기 바랍니다.

• 설명서 제목

• 설명서 번호

• 문의 내용에 해당하는 페이지 번호

• 문제에 대한 간략한 설명

추가 및 향상되었으면 하는 기능에 대한 일반적인 제안도 환영합니다.

ARM DUI 0206IK Copyright © 2002-2008 ARM Limited. All rights reserved. xiUnrestricted Access Non-Confidential

서문

xii Copyright © 2002-2008 ARM Limited. All rights reserved. ARM DUI 0206IKNon-Confidential Unrestricted Access

1장 소개

이 장에서는 RealView � Compilation Tools와 함께 제공되는 ARM � 링커인 armlink에 대해 소개합니다. 이 장은 다음 단원으로 구성되어 있습니다.

• 1-2페이지의 ARM 링커 개요

• 1-5페이지의 레거시 객체 및 라이브러리와의 호환성

ARM DUI 0206IK Copyright © 2002-2008 ARM Limited. All rights reserved. 1-1Unrestricted Access Non-Confidential

소개

1.1 ARM 링커 개요

ARM 링커에서는 ARM 코드, Thumb � 코드 및 Thumb-2 코드를 링크할 수 있으며 필요한 경우 프로세서 상태를 전환하기 위해 인터워킹 베니어를 자동으로 생성합니다. 또한 인라인 베니어 또는 긴 분기 베니어를 필요한 위치에 생성하여 분기 명령어 범위를 확장합니다.

ARM 링커에서는 링크하고 있는 객체의 빌드 속성을 기반으로, 링크할 적합한 표준 C 또는 C++ 라이브러리 변형을 자동으로 선택합니다.

ARM 링커에서는 시스템 메모리 맵 안에 코드 및 데이터의 위치를 지정할 수 있도록 하는 명령 행 옵션을 지원합니다. 또는 스캐터 로딩 설명 파일을 사용하여 로드 시간 및 실행 시간에 출력 이미지에 있는 개별 코드 및 데이터 섹션의 메모리 위치를 지정할 수 있습니다. 이렇게 하면 여러 메모리에 걸친 복잡한 이미지를 만들 수 있습니다.

ARM 링커는 ROM 크기를 최소화하기 위해 읽기/쓰기 데이터 압축을 지원합니다.

ARM 링커에서는 사용하지 않는 섹션을 제거하여 출력 이미지의 크기를 줄일 수 있습니다. 뿐만 아니라 링커를 사용하여 다음과 같은 작업을 수행할 수 있습니다.

• 링크된 파일에 대한 디버그 및 참조 정보 생성

• 정적 콜 그래프를 생성하고 스택 사용량 표시

• 출력 이미지에서 기호 테이블의 내용 제어

• 출력에 코드 및 데이터의 크기 표시

ARM 링커에서는 다음에 파일이 컴파일될 경우에 사용하지 않는 함수에 대해 컴파일러에 알려 주는 피드백을 제공할 수 있습니다. 사용하지 않는 함수는 링커에서 나중에 제거할 수 있도록 이후에 컴파일할 때 별도의 섹션에 배치됩니다.

자세한 내용은 2장 ARM 링커 시작을 참조하십시오.

1.1.1 ARM 링커에 대한 입력

armlink에 대한 입력은 다음으로 구성됩니다.

• ARM ELF (Executable and Linkable Format)에 포함된 하나 이상의 객체 파일. 이 형식에 대한 설명은 ARM ELF 사양에 나와 있습니다.

• armar을 사용하여 생성되는 하나 이상의 라이브러리 (유틸리티 설명서의 3장 armar 사용에서 설명)

• 기호 정의 파일

1-2 Copyright © 2002-2008 ARM Limited. All rights reserved. ARM DUI 0206IKNon-Confidential Unrestricted Access

소개

• 스캐터 로딩 설명 파일

1.1.2 ARM 링커의 출력

armlink의 호출이 성공한 경우 출력은 다음 중 하나입니다.

• ELF 실행 가능 형식의 실행 가능 이미지

• ELF 공유 객체 형식의 공유 객체

• ELF 객체 형식의 부분적으로 링크된 객체

• ELF 객체 형식의 재배치 가능 객체

단순 이미지의 경우, ELF 실행 가능 파일에는 이미지의 RO 및 RW 출력 섹션에 대략적으로 해당하는 세그먼트가 포함됩니다. ELF 실행 가능 파일에는 이미지 출력 섹션을 포함하는 ELF 섹션도 있습니다.

fromelf를 사용하여 ELF 실행 가능 형식의 실행 가능 이미지를 다른 파일 형식으로 변환할 수 있습니다. 자세한 내용은 유틸리티 설명서에서 2장 fromelf 사용을 참조하십시오.

실행 가능 이미지 생성

링커를 사용하여 실행 가능 이미지를 생성하는 경우 링커에서는 다음을 수행합니다.

• 입력 객체 파일 사이의 기호 참조를 확인합니다.

• 라이브러리에서 객체 모듈을 추출하여 다른 방식으로는 충족되지 않는 기호 참조를 충족시킵니다.

• 해당 특성 및 이름에 따라 입력 섹션을 정렬하고 유사한 특성과 이름을 가진 섹션을 연속적 청크로 병합합니다.

• 사용하지 않는 섹션을 제거합니다.

• 중복되는 공통 그룹과 공통 코드, 데이터 및 디버그 섹션을 제거합니다.

• 제공된 그룹화 및 배치 정보에 따라 객체 조각을 메모리 영역으로 구성합니다.

• 재배치 가능 값에 주소를 할당합니다.

• 실행 가능 이미지를 생성합니다.

자세한 내용은 3-2페이지의 이미지 구조체 지정을 참조하십시오.


소개

부분적으로 링크된 객체 생성

링커를 사용하여 부분적으로 링크된 객체를 생성하는 경우 링커에서는 다음을 수행합니다.

• 중복되는 디버그 섹션의 복사본을 제거합니다.

• 기호 테이블을 하나로 병합합니다.

• 확인되지 않은 참조를 확인되지 않은 상태로 둡니다.

• Comdat 그룹을 병합합니다.

• 이후 링크 단계에 입력으로 사용할 수 있는 객체를 생성합니다.

참고

부분적 링크를 사용하는 경우 스캐터 로딩 설명 파일의 이름별로 구성요소 객체를 참조할 수 없습니다.


소개

1.2 레거시 객체 및 라이브러리와의 호환성

이전 릴리스에서 RealView Compilation Tools로 업그레이드하는 경우 RealView Compilation Tools 핵심 설명서에서 최신 정보를 읽어 보십시오.

RealView Compilation Tools 버전 4.0에서 사용되는 ABI (응용 프로그램 바이너리 인터페이스)는 버전 2.0 이전의 도구에 포함된 ABI와는 다릅니다. 따라서 레거시 객체와 라이브러리는 호환되지 않으므로 다시 빌드해야 합니다.

자세한 내용은 라이브러리 설명서의 1-3페이지의 ABI for the ARM Architecture 규격 준수 및 RealView Compilation Tools 핵심 설명서의 레거시 객체 및 라이브러리와의 호환성에 대한 단원을 참조하십시오.


소개


2장 ARM 링커 시작

이 장에서는 ARM � 링커 armlink에서 허용하는 명령 행 옵션에 대해 간략히 설명합니다. 또한 명령 행 옵션 순서 지정, 링커를 호출하는 방법, 환경 변수를 구성하는 방법 및 ARM RealView � Compilation Tools 명명 규칙에 대해서도 설명합니다.

링커는 하나 이상의 객체 파일 내용과 하나 이상의 객체 라이브러리에서 선택한 부분을 결합하여 이미지 또는 객체 파일을 생성합니다. 이 장은 다음 단원으로 구성되어 있습니다.

• 2-2페이지의 모델 연결

• 2-7페이지의 명령 행 옵션 사용


ARM 링커 시작

2.1 모델 연결

이 단원에서는 ARM 링커에서 지원하는 연결 모델에 대해 설명하며 특정 동작 및 그에 적용되는 제한에 대해서도 간략히 설명합니다. 모든 연결 모델에 공통적으로 적용되는 옵션에 대해서는 따로 설명하지 않습니다.

연결 모델은 링커 동작을 제어하는 명령 행 옵션, 내부 옵션 및 메모리 맵입니다.

베어 메탈 이 모델은 특정 플랫폼을 타겟으로 하지 않습니다. 이 모델을 사용하면 필요에 따라 운영 체제, 메모리 맵 및 응용 프로그램 코드를 사용자가 직접 지정하여 이미지를 만들 수 있습니다. 또한 제한적인 일부 동적 연결도 지원됩니다. 스캐터 로딩 파일 사용 여부에 따라서 옵션을 더 적용할 수도 있습니다.

부분 연결

후속 연결 단계에서 링커에 대한 입력에 적합한 플랫폼 독립적 객체를 생성하는 모델로, 개발 프로세스에서 중간 단계로 사용할 수 있으며 제한적인 입력 객체 처리를 수행하여 단일 출력 객체를 생성합니다.

BPABI DLL 계열 BPABI를 지원하는 모델입니다. 복잡성이 서로 다른 플랫폼 OS에서 실행할 응용 프로그램 및 DLL을 생성하는 데 사용됩니다. BPABI 사양에 따라 메모리 모델이 제한됩니다.

SysV ARM Linux에서 사용하는 ELF를 통해 지정되는 SysV 모델을 지원하는 모델입니다. ELF 사양에 따라 메모리 모델이 제한됩니다.

각 모델에서 관련 옵션을 조합하여 출력을 보다 상세하게 제어할 수 있습니다. 다음 단원에서는 이러한 옵션 조합에 대해 보다 상세하게 설명합니다.

자세한 내용은 링커 참조 설명서에서 4장 BPABI 및 SysV 공유 라이브러리와 실행 가능 파일을 참조하십시오.

2.1.1 베어 메탈

베어 메탈 모델은 전체 프로그램 (RTOS 포함 가능)이 단일 패스로 연결되는 일반적인 임베디드 시장에 주력합니다. 링커를 통해서는 베어 메탈 시스템의 메모리에 대해 가정할 수 있는 내용이 거의 없으므로, 보다 세밀한 제어가 필요한 경우에는 스캐터 로딩 메커니즘을 사용해야 합니다.


ARM 링커 시작

링커는 기본적으로 모든 재배치를 정적으로 확인하려고 합니다. 그러나 서로 다른 주소에서 실행 가능하고, 로드 또는 런타임 시 재배치를 확인할 수 있는 위치 독립적이거나 재배치 가능한 이미지를 만들 수도 있습니다. 이렇게 하려면 동적 모델을 사용하면 됩니다.

이러한 모델 형식은 다음과 같은 세 부분으로 구성됩니다.

• 스캐터 로딩 설명 파일이나 명령 행 옵션을 통해 재배치하거나 위치 독립적으로 지정할 수 있는 영역 식별

• 조정 파일을 사용하여 가져오고 내보낼 수 있는 기호 식별

• 조정 파일을 사용하여 ELF 파일에 필요한 공유 라이브러리 식별

추가 참고

베어 메탈 시스템에서는 다음과 같은 옵션을 사용할 수 있습니다.

• 링커 참조 설명서의 2-19페이지의 --edit=file_list

• 링커 참조 설명서의 2-56페이지의 --scatter=file

• 링커 참조 설명서의 2-70페이지의 조정 파일 명령

스캐터 로딩을 사용하지 않을 때는 다음 옵션도 사용할 수 있습니다.

• 링커 참조 설명서의 2-52페이지의 --reloc

• 링커 참조 설명서의 2-53페이지의 --ro_base=address

• 링커 참조 설명서의 2-54페이지의 --ropi

• 링커 참조 설명서의 2-54페이지의 --rosplit

• 링커 참조 설명서의 2-55페이지의 --rw_base=address

• 링커 참조 설명서의 2-55페이지의 --rwpi

• 링커 참조 설명서의 2-60페이지의 --split

2.1.2 부분 연결

부분 연결을 적용하면 모든 입력 파일에 공통적으로 적용되는 중복 정보가 제거되며 기호 테이블이 단일 테이블에 병합됩니다. 후속 링크 단계에 입력으로 사용할 수 있는 단일 파일이 생성됩니다. 출력 파일에는 진입점이 하나만 있을 수 있으므로, 링커가 입력 파일에서 여러 진입점을 찾으면 오류가 생성됩니다.


ARM 링커 시작

명령 행 옵션

부분 연결 시에는 다음 옵션을 사용할 수 있습니다.

• 링커 참조 설명서의 2-45페이지의 --partial

• 링커 참조 설명서의 2-19페이지의 --edit=file_list

• 링커 참조 설명서의 2-22페이지의 --[no_]exceptions_tables=action

2.1.3 BPABI 및 SysV에 공통적으로 적용되는 개념

BPABI 및 SysV 모두에서 이미지 및 공유 객체는 일반적으로 기존 운영 체제에서 실행됩니다.

BPABI와 SysV 모델 간에는 공통점이 많습니다. 예를 들어 두 모델은 모두 예외 테이블을 매핑하는 프로그램 헤더를 생성합니다. 두 모델 간의 가장 큰 차이점은 메모리 모델과 PLT (프로시저 연결 테이블) 및 GOT (전역 오프셋 테이블) 구조체입니다. 그리고 많은 옵션이 두 모델에 공통적으로 적용됩니다.

제한

BPABI와 SysV 모델에는 다음 제한이 적용됩니다.

• 공유 라이브러리 및 DLL에 대해서는 사용하지 않는 섹션 제거가 해제됩니다.

• 가상 함수 제거가 해제됩니다.

• 읽기 쓰기 데이터 압축이 허용되지 않습니다.

• 스캐터 로딩이 허용되지 않습니다.

• __AT 섹션이 허용되지 않습니다.

추가 참고

--bpabi 및 --sysv에는 다음과 같은 옵션을 사용할 수 있습니다.

• 링커 참조 설명서의 2-19페이지의 --dynamic_debug

• 링커 참조 설명서의 2-26페이지의 --[no_]force_so_throw

• 링커 참조 설명서의 2-55페이지의 --runpath=pathlist

• 링커 참조 설명서의 2-59페이지의 --soname=name

• 링커 참조 설명서의 2-63페이지의 --symver_script=file

• 링커 참조 설명서의 2-63페이지의 --symver_soname


ARM 링커 시작

2.1.4 BPABI

BPABI는 자체 플랫폼 관련 이미지 형식을 생성하는 타사의 메타 표준입니다. 즉, BPABI 모델은 특정 플랫폼을 중심으로 하지 않고 최대한 많은 정보를 생성합니다.

예외

공유 객체의 경우에는 예외가 발생하지 않는 것으로 간주됩니다. 자세한 내용은 링커 참조 설명서에서 2-26페이지의 --[no_]force_so_throw를 참조하십시오.

기호 버전 관리

필요한 모든 기호를 로드 타임에 사용할 수 있도록 하려면 기호 버전 관리를 사용해야 합니다.

추가 참고

--bpabi에는 다음과 같은 옵션을 사용할 수 있습니다.

• 링커 참조 설명서의 2-18페이지의 --dll

• 링커 참조 설명서의 2-46페이지의 --pltgot=type

• 링커 참조 설명서의 2-53페이지의 --ro_base=address

• 링커 참조 설명서의 2-54페이지의 --rosplit

• 링커 참조 설명서의 2-55페이지의 --rw_base=address

• 링커 참조 설명서의 2-55페이지의 --rwpi

2.1.5 SysV

SysV 모델은 SysV 공유 객체 및 실행 파일을 생성합니다. 또한 ARM Linux 호환 공유 객체 및 실행 파일을 생성하는 데도 사용할 수 있습니다.

스레드 로컬 저장소

이 모델에서는 스레드 로컬 저장소가 지원됩니다.

예외

공유 객체의 경우에는 예외가 발생하는 것으로 간주됩니다. 자세한 내용은 링커 참조 설명서에서 2-26페이지의 --[no_]force_so_throw를 참조하십시오.


ARM 링커 시작

추가 참고

다음 옵션은 --sysv에서만 사용됩니다.

• 링커 참조 설명서의 2-27페이지의 --fpic

• 링커 참조 설명서의 2-39페이지의 --linux_abitag=version_id

• 링커 참조 설명서의 2-58페이지의 --shared


ARM 링커 시작

2.2 명령 행 옵션 사용

옵션 유형에 따라 다음 규칙이 적용됩니다.

단일 문자 옵션

모든 단일 문자 옵션이나 인수가 지정된 단일 문자 옵션 앞에 대시 (-)를 한 개 추가합니다. 옵션과 인수 사이에 공백을 추가하거나 옵션 바로 뒤에 인수를 지정할 수 있습니다.

키워드 옵션

모든 키워드 옵션이나 인수가 있는 키워드 옵션 앞에 이중 대시 (--)를 추가합니다. 옵션과 인수 사이에 공백이나 = 문자를 추가해야 합니다. 예를 들면 다음과 같습니다.

--scatter=file

--scatter file

선행이 아닌 - 또는 _이 포함된 옵션에는 이들 문자 중 하나를 사용할 수 있습니다. 예를 들어 --force_so_throw는 --force-so-throw와 같습니다.

이름이 대시로 시작하는 파일 이름의 경우 POSIX 옵션 (--)을 사용하여 뒤에 나오는 모든 인수를 명령 스위치가 아닌 파일 이름으로 처리하도록 지정합니다. 예를 들어 이름이 -ifile_1인 파일을 연결하려면 다음을 사용합니다. armlink -- -ifile_1

2.2.1 ARM 링커 호출

ARM 링커를 호출하는 명령은 다음과 같습니다.

armlink [help-options] [license-option] [project-template-options] [library-options] [linker-control-options] [output-options] [memory-map-options] [debuq-options] [image-content-options] [veneer-generation-options] [byte-addressing-mode] [image-info-options] [diagnostic-options] [via-file-options] [miscellaneous-options] [arm-linux-options] [input-file]

이러한 각 옵션에 대한 자세한 내용은 링커 참조 설명서에서 2장 링커 명령 행 옵션을 참조하십시오.

help-options

기본 명령 행 옵션, 컴파일러의 버전 번호 및 컴파일러에서 명령 행을 처리하는 방법을 보여 줍니다.

• 2-28페이지의 --help

• 2-58페이지의 --show_cmdline


ARM 링커 시작

• 2-68페이지의 --vsn

license-option

floating 라이센스를 추가로 얻으려면 다음 옵션을 사용합니다.

• 2-39페이지의 --licretry

project-template-options

프로젝트 템플릿은 특정 구성에 대한 명령 행 옵션과 같은 프로젝트 정보가 포함된 파일입니다. 이러한 파일은 프로젝트 템플릿 작업 디렉토리에 저장됩니다.

프로젝트 템플릿의 사용을 제어하려면 다음 옵션을 사용합니다.

• 2-49페이지의 --[no_]project=filename

• 2-52페이지의 --reinitialize_workdir

• 2-68페이지의 --workdir=directory

library-options

라이브러리 파일 및 경로를 제어하려면 다음 옵션을 사용합니다.

• 2-38페이지의 --libpath=pathlist

• 2-38페이지의 --library_type=lib

• 2-50페이지의 --[no_]reduce_paths

• 2-56페이지의 --[no_]scanlib

• 2-65페이지의 --userlibpath=pathlist

linker-control-options

객체가 링크되는 방식을 제어하려면 다음 옵션을 사용합니다.

• 2-42페이지의 --match=crossmangled

• 2-61페이지의 --strict

• 2-62페이지의 --[no_]strict_relocations

• 2-65페이지의 --unresolved=symbol

output-options

다음 옵션은 출력 파일의 형식과 이름을 지정합니다.

• 2-6페이지의 --bpabi

• 2-12페이지의 --[no_]combreloc

• 2-18페이지의 --dll

• 2-44페이지의 --output=file


ARM 링커 시작

• 2-45페이지의 --partial

• 2-48페이지의 --[no_]prelink_support

• 2-52페이지의 --reloc

• 2-58페이지의 --shared

• 2-64페이지의 --sysv

memory-map-options

메모리 맵을 지정하려면 다음 옵션을 사용합니다.

• 2-4페이지의 --[no_]autoat

• 2-27페이지의 --fpic

• 2-47페이지의 --predefine=”string”

• 2-53페이지의 --ro_base=address

• 2-54페이지의 --ropi

• 2-54페이지의 --rosplit

• 2-55페이지의 --rw_base=address

• 2-55페이지의 --rwpi

• 2-56페이지의 --scatter=file

• 2-60페이지의 --split

debug-options

이미지의 디버그 정보를 제어하려면 다음 옵션을 사용합니다.

• 2-5페이지의 --[no_]bestdebug

• 2-13페이지의 --[no_]compress_debug

• 2-15페이지의 --[no_]debug

• 2-19페이지의 --dynamic_debug

image-content-options

이미지 내용에 영향을 미치는 기타 요소를 제어하려면 다음 옵션을 사용합니다.

• 2-6페이지의 --[no_]branchnop

• 2-13페이지의 --[no_]cppinit

• 2-13페이지의 --cpu=list

• 2-14페이지의 --cpu=name

• 2-14페이지의 --datacompressor=opt

• 2-19페이지의 --edit=file_list


ARM 링커 시작

• 2-20페이지의 --entry=location

• 2-21페이지의 --[no_]exceptions

• 2-22페이지의 --[no_]exceptions_tables=action

• 2-22페이지의 --[no_]export_all

• 2-25페이지의 --[no_]filtercomment

• 2-25페이지의 --fini=symbol

• 2-26페이지의 --first=section_id

• 2-26페이지의 --[no_]force_so_throw

• 2-27페이지의 --fpu=list

• 2-27페이지의 --fpu=name

• 2-31페이지의 --init=symbol

• 2-31페이지의 --[no_]inline

• 2-34페이지의 --keep=section_id

• 2-36페이지의 --last=section_id

• 2-40페이지의 --[no_]locals

• 2-41페이지의 --ltcg

• 2-42페이지의 --max_visibility=type

• 2-43페이지의 --[no_]merge

• 2-43페이지의 --[no_]muldefweak

• 2-44페이지의 --override_visibility

• 2-44페이지의 --pad=num

• 2-46페이지의 --pltgot=type

• 2-46페이지의 --pltgot_opts=mode

• 2-49페이지의 --profile=filename

• 2-51페이지의 --[no_]ref_cpp_init

• 2-53페이지의 --[no_]remove

• 2-59페이지의 --soname=name

• 2-59페이지의 --sort=algorithm

• 2-61페이지의 --[no_]startup=symbol

• 2-63페이지의 --symver_script=file

• 2-63페이지의 --symver_soname

• 2-64페이지의 --[no_]tailreorder

• 2-66페이지의 --vfemode=mode


ARM 링커 시작

veneer-generation-options

베니어 생성을 제어하려면 다음 옵션을 사용합니다.

• 2-32페이지의 --[no_]inlineveneer

• 2-45페이지의 --[no_]piveneer

• 2-66페이지의 --[no_]veneershare

byte-addressing-mode

바이트 주소 지정 모드를 제어하려면 다음 옵션을 사용합니다.

• 2-5페이지의 --be8

• 2-5페이지의 --be32

image-info-options

--callgraph를 제외하고, 링커에서는 기본적으로 표준 출력 스트림인 stdout에 요청하는 정보를 출력합니다. --list 명령 행 옵션을 사용하여 정보를 텍스트 파일로 리디렉션할 수 있습니다.

이미지에 대한 정보를 추출하고 나타내는 방법을 제어하려면 다음 옵션을 사용합니다.

• 2-8페이지의 --[no_]callgraph

• 2-9페이지의 --callgraph_file=filename

• 2-10페이지의 --callgraph_output=fmt

• 2-10페이지의 --cgfile=type

• 2-11페이지의 --cgsymbol=type

• 2-12페이지의 --cgundefined=type

• 2-23페이지의 --feedback=file

• 2-23페이지의 --feedback_image=option

• 2-28페이지의 --info=topic[,topic,...]

• 2-30페이지의 --info_lib_prefix=opt

• 2-40페이지의 --[no_]list_mapping_symbols

• 2-41페이지의 --ltcg

• 2-41페이지의 --[un]mangled

• 2-41페이지의 --[no_]map

• 2-57페이지의 --section_index_display=type

• 2-62페이지의 --[no_]symbols

• 2-62페이지의 --symdefs=file

• 2-69페이지의 --[no_]xref


ARM 링커 시작

• 2-69페이지의 --[no_]xrefdbg

• 2-69페이지의 --xref{from|to}=object(section)

diagnostic-options

링커에서 진단을 내보내는 방법을 제어하려면 다음 옵션을 사용합니다.

• 2-17페이지의 --diag_style=arm|ide|gnu

• 2-17페이지의 --diag_suppress=tag[,tag,...]

• 2-18페이지의 --diag_warning=tag[,tag,...]

• 2-21페이지의 --errors=file

• 2-39페이지의 --list=file

• 2-66페이지의 --verbose

via-file-options

링커에 대한 추가 명령 행 인수를 포함하는 via 파일을 지정하려면 다음 옵션을 사용합니다.

• 2-68페이지의 --via=file

miscellaneous-options

• 2-36페이지의 --[no_]legacyalign

arm-linux-options

ARM Linux 응용 프로그램에는 다음 옵션을 사용합니다.

• 2-2페이지의 --[no_]add_needed

• 2-3페이지의 --arm_linux

• 2-19페이지의 --dynamiclinker=name

• 2-37페이지의 --library=name

• 2-39페이지의 --linux_abitag=version_id

• 2-55페이지의 --runpath=pathlist

• 2-57페이지의 --[no_]search_dynamic_libraries

input-file 이것은 객체, 라이브러리 또는 기호 정의 (symdefs) 파일의 공백으로 구분된 목록입니다. 자세한 내용은 2-32페이지의 input_file_list를 참조하십시오.


ARM 링커 시작

2.2.2 명령 행 옵션 순서 지정

일반적으로 명령 행 옵션은 순서에 상관없이 지정할 수 있습니다. 그러나 일부 옵션의 효과는 관련된 다른 옵션과 어떻게 결합되는지에 따라 달라집니다.

여기서 옵션은 동일한 명령 행에 지정된 이전 옵션을 재정의하며 마지막 옵션이 항상 우선적으로 사용됩니다. 옵션이 이 규칙을 따르지 않는 경우에는 해당 내용이 설명에 기록됩니다. --show_cmdline 옵션을 사용하면 명령 행에서 옵션이 처리되는 방법을 확인할 수 있습니다. 명령은 표준화된 상태로 표시되고 via 파일의 내용은 확장됩니다.

입력 파일의 순서 우선순위에 대한 자세한 내용은 링커 참조 설명서에서 2-32페이지의 input_file_list를 참조하십시오.

2.2.3 환경 변수를 통한 명령 행 옵션 지정

RVCTver_LINKOPT 환경 변수 값을 설정하여 명령 행 옵션을 지정할 수 있습니다. 이 구문은 명령 행 구문과 동일합니다. 링커에서는 RVCTver_LINKOPT의 값을 읽고 명령 문자열의 맨 앞에 삽입합니다. 이는 RVCTver_LINKOPT에 지정된 옵션을 명령 행의 인수로 재정의할 수 있음을 의미합니다.

2.2.4 파일에서 명령 행 옵션 읽기

운영 체제에서 명령 행 길이가 제한되는 경우 추가 명령 행 옵션을 컴파일러 옵션이 포함된 파일에 포함시킬 수 있습니다.

--via filename

컴파일러에서 지정된 파일을 열고 추가 명령 행 옵션을 읽습니다.

자세한 내용은 컴파일러 참조 설명서에서 부록 A via 파일 구문을 참조하십시오.


ARM 링커 시작


3장 기본 링커 기능 사용

이 장에서는 ARM � RealView � Compilation Tools와 함께 제공되는 ARM 링커 armlink의 기본 기능을 설명합니다. 이 장은 다음 단원으로 구성되어 있습니다.

• 3-2페이지의 이미지 구조체 지정

• 3-8페이지의 섹션 배치

• 3-11페이지의 섹션 제거

• 3-14페이지의 피드백

• 3-17페이지의 RW 데이터 압축

• 3-20페이지의 베니어

• 3-23페이지의 인라인

• 3-26페이지의 명령 행 옵션을 사용하여 단순 이미지 만들기

• 3-32페이지의 명령 행 옵션을 사용하여 C++ 예외 처리

• 3-33페이지의 이미지에 대한 정보 얻기

• 3-36페이지의 라이브러리 검색, 선택 및 스캔


기본 링커 기능 사용

3.1 이미지 구조체 지정

이미지의 구조체는 다음으로 정의합니다.

• 해당 구성 영역 및 출력 섹션의 수

• 이미지가 로드될 때 이러한 영역 및 섹션의 메모리 내 위치

• 이미지가 실행될 때 이러한 영역 및 섹션의 메모리 내 위치

메모리 맵에 대해 설명할 경우

• 루트 영역이라는 용어는 로드 및 실행 주소가 동일한 영역을 설명하는 데 사용됩니다.

• 로드 영역은 ELF 세그먼트에 해당합니다.

3.1.1 객체 및 이미지의 구성요소

실행 가능 파일은 이미지, 영역, 출력 섹션 및 입력 섹션의 계층으로 구성됩니다.

• 이미지는 하나 이상의 영역으로 구성됩니다. 각 영역은 하나 이상의 섹션으로 구성됩니다.

• 각 출력 섹션은 하나 이상의 입력 섹션을 포함합니다.

• 입력 섹션은 객체 파일의 코드 및 데이터 정보입니다.

그림 3-1은 영역, 출력 섹션 및 입력 섹션 사이의 관계를 보여 줍니다.

그림 3-1 이미지의 구성요소

Memory

Region 1

Region 2 Output section 2.1

Output section 1.1

Output section 1.2

Output section 1.3

Input section 2.1.1

Input section 2.1.2

Input section 2.1.2

Input section 1.2.1

Input section 1.1.1

Input section 1.1.2

Input section 1.3.1

Input section 1.3.2



3-2페이지의 그림 3-1은 이미지를 구성하는 구성요소를 보여 줍니다.

입력 섹션

입력 섹션은 코드 또는 초기화된 데이터를 포함하거나, 초기화되지 않았거나 이미지가 실행되기 위해 0으로 설정해야 하는 메모리 조각을 설명합니다. 이러한 속성은 RO, RW 및 ZI 같은 특성으로 나타냅니다. 자세한 내용은 3-9페이지의 특성별 입력 섹션 정렬을 참조하십시오. 이러한 특성은 armlink에서 입력 섹션을 상위 구성요소인 출력 섹션 및 영역으로 그룹화하는 데 사용됩니다.

출력 섹션

출력 섹션은 동일한 RO, RW 또는 ZI 특성을 가진 입력 섹션의 연속적 시퀀스입니다. 출력 섹션은 출력 섹션을 구성하는 입력 섹션과 동일한 특성을 갖습니다. 출력 섹션 안에서 입력 섹션은 3-8페이지의 섹션 배치에서 설명하는 규칙에 따라 정렬됩니다.

영역 영역은 1, 2 또는 3개의 출력 섹션으로 이루어진 연속적 시퀀스입니다. 영역 안의 출력 섹션은 해당 특성에 따라 정렬됩니다. RO 출력 섹션이 첫 번째이고 그 다음이 RW 출력 섹션, 마지막이 ZI 출력 섹션입니다. 영역은 일반적으로 ROM, RAM, 주변 장치와 같은 실제 메모리 장치에 매핑됩니다.

3.1.2 이미지의 로드 뷰 및 실행 뷰

이미지 영역은 로드 타임에 시스템 메모리 맵에 배치됩니다. 이미지를 실행할 수 있으려면 영역의 일부를 실행 주소로 이동하고 ZI 출력 섹션을 생성해야 할 수 있습니다. 예를 들어, 초기화된 RW 데이터를 ROM의 로드 주소에서 RAM의 실행 주소로 복사해야 할 수 있습니다.

이미지의 메모리 맵에는 3-4페이지의 그림 3-2에 표시된 대로 다음과 같은 별개의 뷰가 있습니다.

로드 뷰 이미지가 메모리로 로드될 때의 위치를 나타내는 주소, 즉 이미지가 실행을 시작하기 전 위치의 측면에서 이미지의 각 영역과 섹션을 설명합니다.

실행 뷰 이미지가 실행되는 동안 위치하는 주소의 측면에서 이미지의 각 영역과 섹션을 설명합니다.



그림 3-2 로드 및 실행 메모리 맵

표 3-1은 로드 및 실행 뷰를 비교합니다.

3.1.3 이미지 메모리 맵 지정

이미지는 임의 개수의 영역과 출력 섹션으로 구성될 수 있습니다. 이러한 임의 개수의 영역들은 서로 다른 로드 및 실행 주소를 가질 수 있습니다. 이미지의 메모리 맵을 구성하려면 armlink에 다음에 대한 정보가 있어야 합니다.

그룹화 입력 섹션이 출력 섹션과 영역으로 그룹화되는 방식

배치 이미지 영역이 메모리 맵에서 위치할 곳

RW section

RO section RO section0x00000

Execution viewLoad view

RW section

ROM

ZI section

0x08000

0x0FFFF

0x0A000

0x06000

RAM

Memory initializedto zero

표 3-1 로드 및 실행 뷰 비교

로드 설명 실행 설명

로드 주소 섹션 또는 영역이 자신을 포함하는 이미지가 실행을 시작하기 전에 메모리로 로드되는 주소. 섹션 또는 루트가 아닌 영역의 로드 주소는 실행 주소와 다를 수 있습니다.

실행 주소 섹션 또는 영역이 자신을 포함하는 이미지가 실행되는 동안 위치하는 주소

로드 영역 로드 주소 공간의 영역 실행 영역 실행 주소 공간의 영역



이미지의 메모리 맵의 복잡성에 따라 이 정보를 armlink에 전달하는 두 가지 방법이 있습니다.

명령 행 옵션 사용

다음 옵션은 이미지에 하나 또는 두 개의 로드 영역과 최대 세 개의 실행 영역이 있는 단순한 경우에 사용할 수 있습니다.

• --ro-base

• --rw-base

• --ropi

• --rwpi

• --first

• --last

• --split

• --rosplit

위에 나열된 옵션은 단순한 이미지에 대해 스캐터 로딩 설명과 동일한 설정을 단순화된 표시로 제공합니다. 자세한 내용은 3-26페이지의 명령 행 옵션을 사용하여 단순 이미지 만들기를 참조하십시오.

스캐터 로딩 설명 파일 사용

스캐터 로딩 설명 파일은 이미지 구성요소의 그룹화 및 배치를 완전하게 제어해야 하는 보다 복잡한 경우에 사용합니다. 스캐터 로딩 설명 파일을 사용하려면 명령 행에서 --scatter=filename을 지정하십시오. 자세한 내용은 5장 스캐터 로딩 설명 파일 사용에서 설명합니다.

3.1.4 이미지 진입점

이미지의 진입점은 프로그램 실행이 시작될 수 있는 위치입니다. 다음과 같은 두 가지 유형의 진입점이 있습니다.

초기 진입점

이미지의 초기 진입점은 ELF 헤더 파일에 저장된 단일 값입니다. 운영 체제 또는 부트 로더가 RAM으로 로드한 프로그램의 경우, 로더는 이미지의 초기 진입점으로 제어권을 이전하여 이미지 실행을 시작합니다.

이미지에는 초기 진입점이 하나만 있을 수 있습니다. 초기 진입점은ENTRY 지시어가 설정하는 진입점 중 하나일 수는 있지만 반드시 그럴 필요는 없습니다.



ENTRY 지시어가 설정한 진입점

이들은 ENTRY 지시어로 어셈블리 언어 소스에서 설정되는 진입점입니다. 임베디드 시스템에서 이 지시어는 일반적으로 RESET, IRQ 및 FIQ와 같은 프로세서 예외 벡터를 통해 입력되는 코드를 표시하는 데 사용됩니다.

ENTRY 지시어로 이미지에 여러 진입점을 지정할 수 있습니다. 이 지시어는 사용하지 않는 섹션 제거를 수행할 때 섹션을 제거하지 말라고 링커에 지시하는 ENTRY 키워드로 출력 코드 섹션을 표시합니다.

C 및 C++ 프로그램의 경우, C 라이브러리의 __main () 함수도 진입점입니다.

ENTRY 지시어에 대한 자세한 내용은 어셈블러 설명서를 참조하십시오.

임베디드 이미지는 로더에 의해 사용될 경우 헤더에 지정된 단일한 초기 진입점을 가져야 합니다. 자세한 내용은 초기 진입점 지정을 참조하십시오.

초기 진입점 지정

프로그램에 대해 최소한 하나의 초기 진입점을 지정해야 합니다. 그렇지 않으면 링커에서 경고가 생성됩니다. 모든 소스 파일에 진입점이 있을 필요는 없습니다. 단일 소스 파일에 여러 개의 진입점을 사용할 수는 없습니다.

0에 ROM이 있는 임베디드 응용 프로그램의 경우 --entry 0x0을 사용하십시오. 또는 높은 벡터를 가진 CPU의 경우 선택적으로 0xFFFF0000을 사용할 수 있습니다.

초기 진입점은 다음과 같은 조건을 충족해야 합니다.

• 이미지 진입점은 항상 실행 영역 안에 있어야 합니다.

• 실행 영역은 오버레이가 아니어야 하며 루트 실행 영역 (로드 주소가 실행 주소와 동일)이어야 합니다.

초기 진입점을 지정하는 데 --entry 옵션을 사용하지 않을 경우,

• 입력 객체에 ENTRY 지시어가 설정한 진입점이 하나 있으면 링커는 해당 진입점을 이미지의 초기 진입점으로 사용합니다.

• 링커는 다음 중 한 가지 경우에 초기 진입점을 포함하지 않는 이미지를 생성합니다.

— ENTRY 지시어를 사용하여 둘 이상의 진입점이 지정된 경우



— ENTRY 지시어를 사용하여 지정된 진입점이 없는 경우

자세한 내용은 다음 항목을 참조하십시오.

• 링커 참조 설명서의 2-20페이지의 --entry=location

• 어셈블러 설명서의 7-76페이지의 ENTRY



3.2 섹션 배치

링커는 해당 특성에 따라 영역 내에서 모든 입력 섹션을 정렬합니다. 동일한 특성을 가진 입력 섹션은 영역 내에서 연속적 블록을 형성합니다.

각 입력 섹션의 기본 주소는 링커가 정의한 정렬 순서로 결정되며 해당 입력 섹션을 포함하는 출력 섹션 내에 올바르게 정렬됩니다.

일반적으로, 링커는 이미지를 생성할 때 다음 순서로 입력 섹션을 정렬합니다.

1. 특성별

2. 입력 섹션 이름별

3. 입력 목록의 위치별 (FIRST 또는 LAST에 의해 무시되는 경우는 제외). 자세한 내용은 3-9페이지의 FIRST 및 LAST를 사용하여 섹션 배치를 참조하십시오.

참고

이 정렬 순서는 스캐터 로딩 설명 파일 또는 객체 파일 이름 내 순서의 영향을 받지 않습니다.

실행 영역에 4MB의 Thumb 코드, 16MB의 Thumb-2 코드 또는 32MB 이상의 ARM 코드가 있는 경우 링커는 긴 분기 베니어의 수를 최소한으로 줄이기 위해 정렬 순서를 변경할 수 있습니다. 자세한 내용은 3-20페이지의 베니어를 참조하십시오.

기본적으로 링커는 RO, RW 및 선택적으로 ZI 출력 섹션으로 구성되는 이미지를 생성합니다. RO 출력 섹션은 메모리 관리 하드웨어가 있는 시스템에서 런타임에 보호될 수 있습니다. RO 섹션은 타겟의 ROM 으로 배치될 수도 있습니다.



3.2.1 특성별 입력 섹션 정렬

이미지의 부분들이 모여 최소 개수의 인접 영역을 이룹니다. armlink는 다음과 같이 특성별로 입력 섹션을 정렬합니다.

1. 읽기 전용 코드

2. 읽기 전용 데이터

3. 읽기- 쓰기 코드

4. 읽기- 쓰기 데이터

5. 0으로 초기화된 데이터

동일한 특성을 가진 입력 섹션은 이름별로 정렬됩니다. 이름은 대소문자를 구분하는 것으로 간주되고 문자의 ASCII 대조 시퀀스를 사용하여 알파벳 순서로 비교됩니다.

동일한 속성과 이름을 가진 입력 섹션은 입력 파일 내의 상대적 위치에 따라 정렬됩니다.

이러한 규칙은 라이브러리에서 포함된 동일한 특성과 이름을 가진 입력 섹션의 위치는 예측할 수 없음을 의미합니다. 보다 정확한 위치 지정이 필요할 경우 개별 모듈을 명시적으로 지정하여 입력 목록에 포함시킬 수 있습니다.

3.2.2 FIRST 및 LAST를 사용하여 섹션 배치

스캐터 로딩을 사용하지 않는 경우 --first 및 --last 링커 옵션을 사용하여 입력 섹션을 배치하십시오.

스캐터 로딩을 사용하는 경우, 배치 순서가 중요하다면 파일의 FIRST 및 LAST 속성을 사용하여 실행 영역의 첫 번째와 마지막 입력 섹션을 표시하십시오.

그러나 FIRST 및 LAST는 특성별 입력 섹션 정렬에 설명된 대로 기본 특성 정렬 순서를 위반하면 안 됩니다. 예를 들어 FIRST RW는 읽기 전용 코드 또는 읽기 전용 데이터 뒤에 배치됩니다.

3.2.3 섹션 정렬

입력 섹션이 정렬되면 기본 주소가 고정되기 전에 필요할 경우 armlink에서 패딩을 삽입하여 각 입력 섹션이 입력 섹션 정렬의 배수인 주소에서 강제로 시작되도록 합니다.



ARM 링커는 ELF 프로그램 헤더 및 출력 섹션이 입력 섹션의 최대 정렬과 관계없이 4바이트 경계를 기준으로 정렬되도록 합니다. 따라서 armlink는 이미지로 삽입하는 패딩의 양을 최소화할 수 있습니다.

ELF 사양을 엄격하게 준수해야 하는 경우 --no_legacyalign 옵션을 사용하십시오. 사양을 준수하기 위해 패딩을 삽입할 수 있도록 영역의 기본 주소를 정렬하지 않으면 링커에서 오류가 발생합니다. --no_legacy_align을 사용하는 경우 영역 정렬은 영역에 포함된 모든 입력 섹션의 최대 정렬이 됩니다.

ALIGN을 사용하여 영역의 정렬을 확장할 수는 있지만 (예: 4바이트 정렬을 8바이트 정렬로 변경) 기본 정렬을 감소시킬 수는 없습니다 (예: 4바이트 정렬을 2바이트 정렬로 변경). 자세한 내용은 5-30페이지의 페이지 경계에 영역 만들기를 참조하십시오.

또한 입력 섹션의 정렬을 늘릴 수도 있습니다. 어셈블러 설명서의 지시어 참조에 나와 있는 ALIGN에 대한 설명을 참조하십시오.

3.2.4 Thumb 코드를 포함하는 실행 영역 정렬

Thumb 분기 범위는 4MB입니다. 실행 영역이 4MB를 초과하는 Thumb 코드를 포함할 경우, armlink는 유사한 평균 호출 깊이에 있는 섹션을 정렬하고 가장 일반적으로 호출되는 섹션을 중앙에 배치하려고 합니다. 이에 따라 생성되는 베니어의 수가 최소화됩니다. 자세한 내용은 3-20페이지의 베니어를 참조하십시오.

Thumb-2 분기 범위는 16MB입니다. 섹션 재정렬은 제한을 초과한 경우에만 필요합니다.



3.3 섹션 제거

이 단원에서는 중복된 섹션, 사용하지 않는 섹션, 디버그 섹션을 위한 링커 최적화에 대해 설명합니다.

3.3.1 공통 디버그 섹션 제거

DWARF 2에서 컴파일러와 어셈블러는 컴파일 단위가 되는 각 소스 파일에 대해 디버그 섹션 한 세트를 생성합니다. armlink는 특정 소스 파일에 대해 디버그 섹션의 복사본을 여러 개 찾아서 최종 이미지의 복사본 하나만 제외하고 모두 제거할 수 있습니다. 결과적으로 이미지 디버그 크기가 크게 줄어들 수 있습니다.

DWARF 3에서 공통 디버그 섹션은 공통 그룹에 배치됩니다. armlink는 서명이 같은 각 그룹의 복사본 하나만 제외하고 모두 제거합니다.

3.3.2 공통 그룹 또는 섹션 제거

C++ 소스에서 인라인 함수 또는 템플릿이 사용된 경우 ARM 컴파일러는 각 객체가 각각 필요한 인라인 함수 및 템플릿 함수의 라인 외부 복사본을 포함하는 방식으로 링크하기 위한 완전한 객체를 생성합니다. 이러한 함수가 공통 헤더 파일에서 선언되면 함수는 이후에 함께 링크되는 별도의 객체에서 여러 번 정의될 수 있습니다. 중복을 제거하기 위해 컴파일러는 이들 함수를 공통 코드 섹션 또는 그룹의 개별 인스턴스로 컴파일합니다.

공통 코드 섹션 또는 그룹의 개별 인스턴스가 동일하지 않을 수 있습니다. 예를 들어, 복사본 중 일부는 다른 (그러나 호환되는) 빌드 옵션, 다른 최적화 또는 다른 디버그 옵션으로 빌드된 라이브러리에 있을 수 있습니다.

복사본이 동일하지 않으면 armlink는 입력 객체의 특성을 기준으로 각 공통 코드 섹션 또는 그룹에 대한 가능한 최상의 변형을 유지합니다. armlink는 나머지는 제거합니다.

복사본이 동일하면 armlink가 배치된 첫 번째 섹션 또는 그룹을 유지합니다.

이 최적화는 다음 링커 옵션으로 제어합니다.

• --bestdebug 옵션을 사용하여 최대 Comdat 그룹을 사용합니다 (최상의 디버그 뷰를 제공할 수 있음).

• --no_bestdebug 옵션을 사용하여 최소 Comdat 그룹을 사용합니다 (최소 코드 크기를 제공할 수 있음). 기본값입니다.



--no_bestdebug가 기본값이기 때문에 최종 이미지는 --debug로 컴파일하는 동안 디버그 테이블을 생성하는지 여부에 관계없이 동일합니다.


— 컴파일러 사용 설명서의 5-18페이지의 함수 인라인

— 컴파일러 참조 설명서의 2-36페이지의 --[no_]debug

3.3.3 사용하지 않는 섹션 제거

사용하지 않는 섹션 제거는 최종 이미지에서 액세스할 수 없는 코드 및 데이터를 제거합니다. 이 최적화는 --remove, --no_remove, --first, --last 및 --keep 링커 옵션과 --entry (간접적)로 제어할 수 있습니다. --info unused 링커 옵션을 사용하면, 사용하지 않는 섹션 중에 제거된 섹션의 목록을 생성할 수 있습니다.

사용하지 않는 섹션 제거는 모든 섹션 제거라는 결과를 가져올 수 있는 경우에는 사용하지 않습니다.

입력 섹션은 다음과 같은 경우 최종 이미지에서 유지됩니다.

• 진입점을 포함하는 경우

• 진입점을 포함하는 입력 섹션의 비 weak 참조에 의해 직접 또는 간접적으로 참조되는 경우

• --first 또는 --last 옵션 (또는 스캐터 로딩 해당 옵션)으로 첫 번째 또는 마지막 입력 섹션으로 지정된 경우

• --keep 옵션에 의해 제거할 수 없음으로 표시된 경우

참고

일반적으로 컴파일러는 함수와 데이터를 함께 수집하여 각 범주에 대해 한 섹션을 내보냅니다. 링커는 완전히 사용되지 않는 섹션만 제거할 수 있습니다.

3.3.4 사용하지 않는 가상 함수 제거

VFE (가상 함수 제거)는 C++ 코드에서 생성된 이미지의 ROM 크기를 줄이기 위해 사용하지 않는 섹션 제거를 개선한 것입니다. 이 최적화는 코드에서 사용하지 않는 가상 함수와 RTTI 객체를 제거하는 데 사용될 수 있습니다.

둘 이상의 함수가 있는 입력 섹션은 모든 함수가 사용되지 않는 경우에만 제거할 수 있습니다. 링커는 섹션 내에서 사용하지 않는 함수를 제거할 수 없습니다. 이후 부분에서 함수는 자체 섹션에서 컴파일된 것으로 가정됩니다.



사용하지 않는 섹션 제거는 C 코드에서 사용하지 않는 함수를 효율적으로 제거합니다. C++ 응용 프로그램에서는 포인터 테이블 (vtable)이 가상 함수와 RTTI 객체를 참조합니다. 추가 정보가 없으면 링커는 런타임에 액세스할 vtable 항목을 확인할 수 없습니다. 즉, 링커가 사용하는 표준 미사용 섹션 제거 알고리즘이 사용하지 않는 가상 함수와 RTTI 객체를 반드시 제거한다고 보장할 수 없습니다.

VFE는 ARM 컴파일러와 링커 간의 협력으로 이루어집니다. 즉, 컴파일러가 사용하지 않는 가상 함수에 대한 추가 정보를 제공하면 링커가 이 정보를 사용합니다. 이 분석을 기준으로 링커는 사용하지 않는 가상 함수 및 RTTI 객체를 제거할 수 있습니다.

참고

VFE 주석이 C++ 라이브러리를 참조하지 않는 경우 어셈블러 소스 파일에서는 VFE 주석이 필요하지 않습니다. 이것은 링커가 C++ 라이브러리를 참조하지 않는 객체 파일에서는 가상 함수 호출을 수행하지 않는다고 가정하기 때문입니다. 마찬가지로 이전 버전의 armcc로 컴파일된 C 소스 파일은 C++ 라이브러리를 참조하지 않는 경우 VFE에 참여할 수 있습니다.

VFE는 다음 네 가지 모드로 작동합니다.

• On

• Off

• Force

• Force no RTTI

자세한 내용은 링커 참조 설명서에서 2-66페이지의 --vfemode=mode를 참조하십시오.

컴파일러가 접두사 .arm_vfe로 시작하는 섹션에 추가 정보를 배치합니다. 이러한 섹션은 VFE 인식이 아닌 경우 링커가 무시합니다.



3.4 피드백

이 단원에서는 반복되는 컴파일을 위해 링커 피드백을 사용하는 방법을 설명합니다.

armlink는 다음에 파일이 컴파일될 때를 위해 피드백을 제공하여 사용하지 않는 함수에 대해 컴파일러에 알려줍니다. 사용하지 않는 함수는 링커에서 나중에 제거할 수 있도록 별도의 섹션에 배치됩니다.

링커의 --inline 최적화가 설정되면 (3-23페이지의 인라인 참조) 링커가 인라인한 함수도 피드백 파일에 내보내집니다. 인라인된 함수는 자체 섹션에도 배치됩니다.

--feedback file 옵션은 각 출력 파일 이름을 포함하는 피드백 파일을 주석으로 생성하고 파일에 있는 사용하지 않은 기호를 생성합니다. 예를 들면 다음과 같습니다.

;#<FEEDBACK># ARM Linker, RVCT ver [Build num]: Last Updated: Date;VERSION 0.2;FILE foo.ounused_func1 <= USED 0inlined_func <= LINKER_INLINED;FILE bar.ounused_func2 <= USED 0

다음에 소스를 컴파일할 때 컴파일러 옵션 --feedback file 을 사용하여 사용할 링커 생성 피드백 파일을 지정할 수 있습니다. 피드백 파일이 없으면 컴파일러에서 경고 메시지를 생성합니다.

3.4.1 예제

피드백 작동 방법을 확인하려면

1. 예제 3-1에 표시된 코드를 포함하는 fb.c 파일을 만듭니다.

예제 3-1 피드백 예제

#include <stdio.h>

void legacy (){ printf ("This is a legacy function, that is no longer used.\n");}

int cubed (int i)



{ return i*i*i;}

void main (){ int n = 3; printf ("%d cubed = %d\n",n,cubed (n));}

2. 프로그램을 컴파일합니다 (피드백 파일이 없다는 경고 무시).

armcc --asm -c --feedback fb.txt fb.c

이것은 기본적으로 cubed () 함수를 인라인하고 어셈블러 파일 fb.s와 객체 파일 fb.o를 생성합니다. 어셈블러 파일에서 legacy () 및 cubed ()의 코드는 여전히 존재합니다. 인라인 때문에 main에서 cubed ()에 대한 호출은 없습니다.

cubed ()의 라인 외부 복사본은 static으로 선언되지 않았기 때문에 보관됩니다.

3. 다음 명령 행을 사용하여 객체 파일을 링크하여 링커 피드백 파일을 만듭니다.

armlink --info sizes --list fbout1.txt --feedback fb.txt fb.o -o fb.axf

링커 진단이 fbout1.txt 파일에 출력됩니다.

다음과 같이 링커 피드백 파일은 컴파일러에서 사용하지 않는 함수가 포함된 소스 파일을 주석으로 표시하고 legacy () 및 cubed () 함수에 대한 항목을 포함합니다.

;#<FEEDBACK># ARM Linker, RVCT ver [Build num]: Last Updated: Date;VERSION 0.2;FILE fb.ocubed <= USED 0legacy <= USED 0

이것은 함수를 사용하지 않음을 나타냅니다.

4. 다음과 같이 다른 진단 파일로 컴파일 및 링크 단계를 반복하십시오.

armcc --asm -c --feedback fb.txt fb.c

armlink --info sizes --list fbout2.txt fb.o -o fb.axf

5. 두 개의 진단 파일 fbout1.txt와 fbout2.txt를 비교하여 이미지 구성요소의 크기를 확인합니다 (예: Code, RO Data, RW Data 및 ZI Data). Code 구성요소는 더 작습니다.



어셈블러 파일에서 fb.s, legacy () 및 cubed () 함수는 더 이상 주 .text 영역에 없습니다. 이들 함수는 자체 ELF 섹션으로 컴파일됩니다. 따라서 armlink는 최종 이미지에서 legacy () 및 cubed () 함수를 제거할 수 있습니다.

참고

링커 피드백을 최대한 이용하려면 컴파일 및 링크 작업 전체를 적어도 두 번 실행해야 합니다. 그러나 일반적으로 이전 빌드의 피드백을 사용하는 단일 컴파일 및 링크로도 충분합니다.



3.5 RW 데이터 압축

이 단원에서는 데이터 압축을 위한 링커 최적화에 대해 설명합니다.

RW 데이터 영역은 일반적으로 많은 수의 반복 값 (예: 0)을 포함하므로 압축에 적합합니다. RW 데이터 압축은 ROM 크기를 최소화하도록 기본적으로 활성화되어 있습니다.

ARM 라이브러리에는 압축 해제 알고리즘이 포함되어 있으며, 링커는 이미지가 실행될 때 데이터 영역을 압축 해제하기 위해 이미지에 추가할 최적의 압축 해제 알고리즘을 선택합니다. 그러나 링커가 선택한 알고리즘을 무시할 수 있습니다.

3.5.1 압축기 선택

armlink는 데이터 섹션의 내용 정보를 수집하여 최적의 압축 알고리즘을 선택하며, 이를 통해 가장 작은 크기의 이미지를 생성합니다. 압축하는 것이 적절한 경우 링커는 이미지의 압축 가능한 모든 데이터 섹션에 대해 하나의 데이터 압축기만 사용할 수 있으며 전체 크기를 최적화하기 위해 이러한 섹션에서 다른 압축이 시도될 수 있습니다. 압축은 다음과 같은 경우 자동으로 적용됩니다.

Compressed data size + Size of decompressor < Uncompressed data size

압축기가 선택되면 armlink가 이미지의 코드 영역에 해독기를 추가합니다. 최종 이미지에 압축된 데이터가 없으면 해독기는 추가되지 않습니다.

다음 중 한 가지 방법으로 링커가 사용하는 압축을 무시할 수 있습니다.

• --datacompressor off 옵션을 사용하여 압축 해제

• 사용자가 선택한 압축기 지정

명령 행 옵션 --datacompressor list를 사용하여 링커에서 사용할 수 있는 압축기 목록을 생성할 수 있습니다. 예를 들면 다음과 같습니다.

Num Compression algorithm========================================================0 Run-length encoding1 Run-length encoding, with LZ77 on small-repeats2 Complex LZ77 compression



3.5.2 압축이 적용되는 방식

Run-length 압축은 반복되지 않는 바이트와 반복되는 0바이트로 데이터를 인코딩합니다. 반복되지 않는 바이트는 변경 없이 출력되며 그 뒤에 0바이트 개수가 옵니다. Limpel-Ziv 1977 (LZ77) 압축은 확인된 데이터의 마지막 n바이트를 추적하여 이미 확인된 구를 만나면 이전에 확인된 데이터 버퍼에서의 구의 위치와 구의 길이에 해당하는 값 쌍을 출력합니다.

압축기를 지정하려면 링커 명령 행에서 필요한 ID를 사용하십시오. 예를 들면 다음과 같습니다.

armlink --datacompressor 2 ...

압축기를 선택할 때 다음 사항을 유의하십시오.

• 0 압축기는 0바이트 영역이 넓지만 0이 아닌 바이트가 적은 데이터에서 효과적인 압축률을 제공합니다.

• 1 압축기는 0이 아닌 바이트가 반복되는 데이터에서 효과적인 압축률을 제공합니다.

• 2 압축기는 반복되는 값을 포함하는 데이터에서 효과적인 압축률을 제공합니다.

링커는 데이터가 대부분 (75% 이상) 0바이트를 포함하는 경우 0 또는 1 압축기를 선호합니다. 2 압축기는 데이터에 0바이트가 적을 경우 (10% 이하) 선택됩니다. 이미지가 ARM 코드로만 이루어진 경우 ARM 해독기가 자동으로 사용됩니다. 이미지에 Thumb 코드가 포함되는 경우 Thumb 해독기가 사용됩니다. 분명한 선호가 없으면 최상의 전체 크기를 생성하기 위해 모든 압축기가 테스트됩니다 (3-17페이지의 압축기 선택 참조).

참고

사용자의 자체 압축기를 링커에 추가할 수는 없습니다. 사용 가능한 알고리즘과 링커가 알고리즘을 사용하기 위해 선택하는 방법은 향후에 변경될 수 있습니다.

3.5.3 RW 데이터 압축 작업

RW 데이터 압축 작업을 할 경우에는 다음 사항이 적용됩니다.

• 링커 옵션 --map을 사용하여 압축이 코드 영역에서 어디에 적용되었는지 확인합니다.



• Load$$region_name$$Base 기호가 사용되는 경우 링커는 압축을 적용하지 않습니다. 여기서 region_name은 동일한 로드 영역의 압축된 데이터를 포함하는 실행 영역 뒤에 옵니다.

• 온칩 캐시가 탑재된 ARM 프로세서를 사용하는 경우 코드 일관성 문제가 발생하지 않도록 압축 해제 후에 캐시를 사용하십시오.

자세한 내용은 개발자 설명서에서 3장 임베디드 소프트웨어 개발을 참조하십시오.

RW 데이터 압축에서는 루트 영역에 배치해야 하는 __dc*.o 등의 라이브러리 코드를 사용합니다. 스캐터 로딩 설명 파일에 InRoot$$Sections를 사용하면 이 작업을 가장 효율적으로 수행할 수 있습니다.

스캐터 로딩 설명 파일을 사용하는 경우 NOCOMPRESS 속성을 추가하여 압축하지 않아야 하는 로드 또는 실행 영역을 지정합니다. 자세한 내용은 3장 스캐터 로딩 설명 파일의 형식적 구문을 참조하십시오.



3.6 베니어

베니어는 링커가 생성하고 프로그램으로 삽입되는 작은 코드 섹션입니다. armlink는 분기에 현재 상태의 분기 범위를 벗어나는 대상이 포함될 경우 베니어를 생성해야 합니다.

BL 명령어의 범위는 ARM의 경우 32MB이고, Thumb-2의 경우 16MB, Thumb의 경우 4MB입니다. 따라서 베니어는 명령어의 중간 타겟이 된 다음 PC를 대상 주소로 설정함으로써 분기 범위를 확장할 수 있습니다. ARM 및 Thumb이 혼합되면 베니어가 프로세서 상태도 변경합니다.

armlink는 다음과 같은 베니어 유형을 지원합니다.

• ARM 대 ARM

• ARM 대 Thumb (인터워킹 베니어)

• Thumb 대 ARM (인터워킹 베니어)

• Thumb 대 Thumb

armlink는 각 베니어에 대해 Veneer$$Code라고 하는 하나의 입력 섹션을 생성합니다. 베니어는 요구 사항을 충족시킬 수 있는 다른 기존 베니어가 없는 경우에만 생성됩니다. 두 개 입력 섹션에 동일한 대상에 대한 긴 분기가 포함되는 경우에는 한 개 베니어만 생성됩니다. 베니어는 두 섹션 모두가 도달할 수 있는 경우에만 이런 식으로 공유됩니다.

ARMv4T를 사용 중인 경우 armlink는 분기에 ARM과 Thumb 사이의 상태 변화가 포함될 때 베니어를 생성합니다. ARMv5 이상에서는 BLX 명령어가 사용됩니다.

3.6.1 베니어 공유

명령 행 옵션 --no_veneershare를 사용하여 베니어가 공유되지 않도록 지정할 수 있습니다. 이로써 생성된 베니어 섹션의 소유권이 베니어를 생성한 객체에 할당되므로 스캐터 로딩 설명 파일의 특정 객체에서 베니어를 선택할 수 있습니다. 예를 들면 다음과 같습니다.

LR 0x8000{

ER_ROOT +0{

object1.o (Veneer$$Code)}

}



베니어를 공유하면 소유 객체를 할당할 수 없습니다. 따라서 --no_veneershare를 사용하면 보다 일관성 있는 이미지 레이아웃이 제공됩니다. 대신 코드 크기는 현저하게 증가합니다.

3.6.2 베니어 변형

베니어는 사용자가 필요로 하는 분기 범위에 따라 다른 변형을 갖습니다.

• 인라인 베니어의 특징은 다음과 같습니다.

— 베니어는 타겟 섹션이 범위 안에 있기 직전에 삽입되어야 합니다.

— ARM-Thumb 인터워킹 베니어는 범위가 256바이트이므로 함수 코드가 베니어 코드 바로 뒤의 첫 번째 256바이트에 나타나야 합니다.

— Thumb-ARM 인터워킹 베니어는 범위가 0바이트이므로 함수 코드가 베니어 코드 바로 뒤에 나타나야 합니다.

— 인라인 베니어는 항상 위치 독립적입니다.

이러한 제한으로 인해 스캐터 로딩 설명 파일을 사용하는 실행 영역 밖으로 인라인 베니어를 이동할 수 없습니다. 명령 행 옵션 --no_inlineveneer를 사용하면 인라인 베니어가 생성되지 않도록 할 수 있습니다.

• 짧은 분기 베니어의 특징은 다음과 같습니다.

— ARM-Thumb 짧은 분기 베니어는 범위가 4MB입니다.

— 짧은 분기 베니어는 항상 위치 독립적입니다.

• 긴 분기 베니어의 특징은 다음과 같습니다.

— ARM-Thumb과 Thumb-ARM 인터워킹 베니어는 모두 범위가 232바이트입니다.

— armlink는 긴 분기 기능을 상태 변경 기능과 결합하므로 모든 긴 분기 베니어는 인터워킹 베니어이기도 합니다.

— 긴 분기 베니어는 절대적이거나 위치 독립적입니다.

베니어를 사용 중인 경우 다음을 유의하십시오.

• 모든 베니어는 결과적인 베니어 입력 섹션이 다른 입력 섹션 범위 내에 있을 수 없기 때문에 하나의 입력 섹션으로 모일 수 없습니다. 섹션이 주소 지정 범위 내에 없으면 긴 분기는 가능하지 않습니다.

• 링커는 베니어의 위치 독립적 변형을 자동으로 생성합니다. 그러나 이러한 베니어는 위치 독립적이지 않은 변형보다 크기 때문에 링커는 필요한 경우, 즉 소스와 대상 실행 영역이 둘 다 위치 독립적이고 엄격하게 관련된 경우에만 이 작업을 수행합니다.



베니어는 코드 크기를 최적화하기 위해 생성됩니다. 따라서 armlink는 선호 순으로 변형을 선택합니다.

1. 인라인 베니어

2. 짧은 분기 베니어

3. 긴 베니어

3.6.3 절대 베니어에 대한 PI

일반적인 호출 명령어는 타겟의 주소를 호출 주소의 오프셋으로 인코딩합니다. PI 코드에서 절대 코드로 호출하는 경우 링크 타임에 오프셋을 계산할 수 없기 때문에 링커에서 긴 분기 베니어를 삽입해야 합니다.

절대 베니어에 PI를 생성하는 작업은 --piveneer 옵션을 사용하여 제어할 수 있습니다. 이 옵션은 기본적으로 설정되어 있습니다. --no_piveneer를 사용하여 이 옵션을 해제할 경우 링커는 PI 코드에서 절대 코드로의 호출이 감지되면 오류를 생성합니다.

3.6.4 오버레이 실행 영역과 함께 베니어 재사용

스캐터 로딩 설명 파일을 사용하면 오버레이 영역, 즉 RAM의 같은 영역을 공유하는 영역을 만들 수 있습니다. 링커는 가능한 경우에는 항상 베니어를 재사용하며, 오버레이된 영역에서 베니어를 재사용할 때는 몇 가지 제한이 적용됩니다. 그러나 재사용 시 다음 두 가지 조건이 모두 적용됩니다.

• 오버레이 실행 영역은 다른 오버레이 실행 영역에 배치된 베니어는 재사용할 수 없습니다.

• 다른 실행 영역은 오버레이 실행 영역에 배치된 베니어는 재사용할 수 없습니다.

이러한 조건이 충족되지 않으면 기존 베니어를 재사용하는 대신 새로운 베니어가 생성됩니다. 스캐터 로딩을 사용하여 베니어를 특정한 임의 위치에 배치하도록 지시한 경우를 제외하고, 베니어는 항상 해당 베니어를 필요로 하는 호출이 포함된 실행 영역에 배치됩니다. 이것은 다음을 의미합니다.

• 오버레이 실행 영역의 경우 모든 해당하는 베니어는 실행 영역 안에 포함됩니다.

• 오버레이 실행 영역은 다른 실행 영역의 베니어가 필요하지 않습니다.



3.7 인라인

링커는 작은 함수에 대한 분기 명령어 대신 해당 함수를 인라인할 수 있습니다. 링커가 이 작업을 수행하려면 복귀 명령어가 없는 함수가 분기 명령어의 4바이트에 맞아야 합니다.

다음 명령 행 옵션을 사용하여 분기 인라인을 제어하십시오.

• 2-6페이지의 --[no_]branchnop

• 2-31페이지의 --[no_]inline

• 2-64페이지의 --[no_]tailreorder

분기 인라인 최적화를 활성화하면 링커가 이미지의 각 함수 호출을 검색한 다음 적용 가능한 경우 인라인합니다. 링커는 인라인하기에 적합한 함수를 찾으면 함수 호출을 호출 수신자 함수의 명령어로 교체합니다.

링커는 사용하지 않는 섹션을 제거하기 전에 분기 인라인 최적화를 적용하여 인라인된 섹션도 더 이상 호출되지 않으면 제거되도록 합니다. 자세한 내용은 3-12페이지의 사용하지 않는 섹션 제거를 참조하십시오.

--info=inline 명령 행 옵션을 사용하면 모든 인라인된 함수를 나열할 수 있습니다. 자세한 내용은 링커 참조 설명서에서 2-28페이지의 --info=topic[,topic,...]를 참조하십시오.

3.7.1 인라인에 영향을 주는 요소

다음 요소는 함수가 인라인되는 방식에 영향을 줍니다.

• 링커는 가장 단순한 경우만 처리하고 PC에 대한 읽기 또는 쓰기는 함수의 위치에 따라 다르기 때문에 이를 지시하는 명령어는 인라인하지 않습니다.

• 이미지에 ARM 및 Thumb 코드가 모두 있는 경우 인터워킹을 위해 다른 상태에서 호출된 함수를 작성해야 합니다. 링커는 최대 두 개의 16비트 Thumb 명령어가 포함된 함수를 인라인할 수 있습니다. 그러나 ARM 호출자는 하나의 16비트 Thumb 명령어 또는 32비트 Thumb-2 명령어가 포함된 함수만 인라인할 수 있습니다.



• 링커가 수행하는 작업은 표 3-2에 나와 있는 것처럼 호출자와 호출 수신자의 상태 및 호출 수신자 함수의 크기에 따라 달라집니다.

• 인라인되기 위해서는 함수의 마지막 명령어가 다음 중 하나여야 합니다.

MOV pc, lr

또는BX lr

복귀 시퀀스로만 구성된 함수는 NOP로 인라인될 수 있습니다.

• 조건부 ARM 명령어는 다음과 같은 경우에만 인라인할 수 있습니다.

— BL의 조건이 인라인할 명령어의 조건과 일치하는 경우. 예를 들어 BLEQ는 ADDEQ처럼 조건이 일치하는 명령어만 인라인할 수 있습니다.

— BL 명령어 또는 인라인할 명령어가 무조건 명령어인 경우. 무조건 ARM BL은 조건부 명령이나 다른 기준을 모두 충족하는 모든 무조건 명령을 인라인할 수 있습니다. BL 명령어가 조건부 명령어이면 조건부로 실행할 수 없는 명령어는 인라인할 수 없습니다.

• IT 블록의 마지막 명령어인 BL은 16비트 Thumb 명령어나 32비트 MRS, MSR 또는 CPS 명령어를 인라인할 수 없습니다. IT 블록이 해당 범위 내에서 명령어의 동작을 변경하므로 명령어를 인라인하면 프로그램의 동작이 변경되기 때문입니다.

3.7.2 마무리 호출 섹션 처리

링커는 3-23페이지의 인라인에 영향을 주는 요소에 설명된 대로 다음 명령어로 처리되는 재배치를 구성하는 분기를 NOP로 대체합니다. 따라서 마무리 호출 섹션, 즉 분기 명령어로 끝나는 섹션의 경우 실행 영역에서 섹션의 타겟이 해당 섹션 바로 뒤에 나타나며 NOP로 변경된 분기가 포함되도록 최적화될 수 있습니다.

표 3-2 작은 함수 인라인

호출자 상태 호출 수신자 상태 호출 수신자 함수 크기

ARM ARM 4 ~ 8바이트

ARM Thumb 2 ~ 6바이트

Thumb Thumb 2 ~ 6바이트



타겟 바로 앞으로 마무리 호출 섹션을 이동하려면 명령 행 옵션 --tailreorder를 사용하여 이 동작을 이용할 수 있습니다. 자세한 내용은 링커 참조 설명서에서 2-64페이지의 --[no_]tailreorder를 참조하십시오.

--info=tailreorder 명령 행 옵션을 사용하여 마무리 호출 최적화에 대한 정보를 표시할 수 있습니다. 자세한 내용은 링커 참조 설명서에서 2-28페이지의 --info=topic[,topic,...]을 참조하십시오.



3.8 명령 행 옵션을 사용하여 단순 이미지 만들기

단순 이미지는 RO, RW, ZI 형식의 여러 입력 섹션으로 구성됩니다. 이러한 입력 섹션이 대조되어 RO, RW, ZI 출력 섹션을 형성합니다. 로드 및 실행 영역 내에서 출력 섹션이 정렬되는 방식에 따라 단순 이미지는 다음과 같은 세 가지 기본 유형으로 구분됩니다.

유형 1 로드 뷰에 하나의 영역이 있고 실행 뷰에 연속적인 세 개의 영역이 있습니다. --ro-base 옵션을 사용하면 이러한 유형의 이미지를 만들 수 있습니다.

자세한 내용은 3-27페이지의 유형 1, 로드 영역 하나와 연속되는 실행 영역을 참조하십시오.

유형 2 로드 뷰에 하나의 영역이 있고 실행 뷰에 연속적이지 않은 세 개의 영역이 있습니다. --ro-base 및 --rw-base 옵션을 사용하면 이러한 유형의 이미지를 만들 수 있습니다.

자세한 내용은 3-28페이지의 유형 2, 로드 영역 하나와 연속되지 않는 실행 영역을 참조하십시오.

유형 3 로드 뷰에 두 개의 영역이 있고 실행 뷰에 연속적이지 않은 세 개의 영역이 있습니다. --ro-base, --rw-base 및 --split 옵션을 사용하면 이러한 유형의 이미지를 만들 수 있습니다. 또한 --rosplit 옵션을 사용하여 기본 로드 영역을 두 개 RO 출력 섹션 (코드용 하나와 데이터용 하나)으로 분할할 수 있습니다.

자세한 내용은 3-30페이지의 유형 3, 로드 영역 두 개와 연속되지 않는 실행 영역을 참조하십시오.

세 가지 단순 이미지 유형 모두에는 다음과 같이 최대 세 개의 실행 영역이 있습니다.

• RO 출력 섹션이 포함된 첫 번째 실행 영역

• RW 출력 섹션이 있는 경우 이 섹션이 포함된 두 번째 실행 영역

• ZI 출력 섹션이 있는 경우 이 섹션이 포함된 세 번째 실행 영역

이러한 실행 영역은 RO, RW, ZI 실행 영역으로 참조됩니다.

단순 이미지는 스캐터 로딩 설명 파일로도 만들 수 있습니다. 자세한 방법은 5-32페이지의 단순 이미지에 대한 해당 스캐터 로딩 설명을 참조하십시오.



3.8.1 유형 1, 로드 영역 하나와 연속되는 실행 영역

이 유형의 이미지는 로드 뷰의 단순 로드 영역과 메모리 맵에 연속적으로 배치된 세 개의 실행 영역으로 구성됩니다. 이 방식은 OS 부트 로더 또는 데스크톱 시스템과 같이 프로그램을 RAM으로 로드하는 시스템에 적합합니다 (그림 3-3 참조).

그림 3-3 단순 유형 1 이미지

이 유형의 이미지에는 다음 명령을 사용하십시오.

armlink --ro-base 0x8000

로드 뷰

하나의 로드 영역은 연속적으로 배치된 RO 및 RW 출력 섹션으로 구성됩니다. RO 및 RW 실행 영역은 모두 부트 영역입니다. 로드 타임에 ZI 출력 섹션은 없습니다. ZI 출력 섹션은 이미지 파일의 출력 섹션 설명을 사용하여 실행 전에 만들어집니다.

실행 뷰

RO, RW 및 ZI 출력 섹션이 포함된 세 개의 실행 영역은 연속적으로 정렬됩니다. RO 및 RW 실행 영역의 실행 주소는 로드 주소와 같으므로 로드 주소에서 실행 주소로 이동할 것이 없습니다. 그러나 ZI 출력 섹션이 포함된 ZI 실행 영역은 런타임에 만들어집니다.

RO output section

RW output section

RO output section

RW executionregion

RO executionregion

Singleloadregion

ZI executionregionZI output section


0x8000

RAM

RW output section

0x0000

--ro-base value



armlink 옵션인 --ro-base address를 사용하여 RO 출력을 포함하는 영역의 로드 및 실행 주소를 지정할 수 있습니다. 기본 주소는 3-27페이지의 그림 3-3에 표시된 대로 0x8000입니다.

3.8.2 유형 2, 로드 영역 하나와 연속되지 않는 실행 영역

이 유형의 이미지는 하나의 로드 영역과 실행 뷰에 있는 세 개의 실행 영역으로 구성됩니다. RW 실행 영역은 RO 실행 영역과 연속되지 않습니다. 이 방식은 예를 들어, 시작할 때 RW 데이터가 ROM에서 RAM으로 복사되는 ROM 기반 임베디드 시스템 (그림 3-4 참조)에 사용됩니다.



armlink --ro-base 0x0 --rw-base 0xA000

로드 뷰

로드 뷰에서 단순 로드 영역은, 예를 들어 ROM에 연속적으로 배치된 RO 및 RW 출력 섹션으로 구성됩니다. 여기서 RO 영역은 루트 영역이며 RW 영역은 루트 영역이 아닙니다. 로드 타임에 ZI 출력 섹션은 없습니다. 이것은 런타임에 만들어집니다.

RO output section

RW output section

RW output section

RO output section

RW executionregion

RO executionregion

Singleloadregion

ZI executionregion

ZI output section


RAM

ROM

0x0000 --ro-base value

--rw-base value0xA000

Copy/decompress



실행 뷰

실행 뷰에서 첫 번째 실행 영역에는 RO 출력 섹션이 포함되고 두 번째 실행 영역에는 RW 및 ZI 출력 섹션이 포함됩니다.

RO 출력 섹션이 포함된 영역의 실행 주소는 로드 주소와 같으므로 RO 출력 섹션은 이동할 필요가 없습니다. 즉 RO 출력 섹션은 루트 영역입니다.

RW 출력 섹션이 포함된 영역의 실행 주소는 로드 주소와 다르므로 RW 출력 섹션은 로드 주소에서 (단일 로드 영역에서) 실행 주소로 (두 번째 실행 영역으로) 이동됩니다. ZI 실행 영역과 ZI 출력 섹션은 RW 실행 영역과 연속적으로 배치됩니다.

armlink 옵션인 --ro-base address를 사용하여 RO 출력 섹션의 로드 및 실행 주소를 지정할 수 있고, --rw-base exec_address를 사용하여 RW 출력 섹션의 실행 주소를 지정할 수 있습니다. --ro-base 옵션을 사용하여 주소를 지정하지 않으면 armlink는 기본값 0x8000을 사용합니다. 임베디드 시스템의 경우 --ro-base 값에 일반적으로 0x0이 사용됩니다. --rw-base 옵션을 사용하여 주소를 지정하지 않으면 3-27페이지의 유형 1, 로드 영역 하나와 연속되는 실행 영역에서와 마찬가지로 기본적으로 RO 바로 위에 RW가 배치됩니다.

참고

RW 및 ZI 출력 섹션의 실행 영역은 로드 영역을 오버로드할 수 없습니다.



3.8.3 유형 3, 로드 영역 두 개와 연속되지 않는 실행 영역

이러한 유형의 이미지는 단일 로드 영역이 두 개의 루트 로드 영역으로 분할된 점을 제외하면 유형 2의 이미지와 비슷합니다 (그림 3-5 참조).



armlink --split --ro-base 0x8000 --rw-base 0xE000

로드 뷰

로드 뷰에서 첫 번째 로드 영역은 RO 출력 섹션으로 구성되고 두 번째 로드 영역은 RW 출력 섹션으로 구성됩니다. 로드 타임에 ZI 출력 섹션은 없습니다. ZI 출력 섹션은 이미지 파일에 포함된 출력 섹션의 설명을 사용하여 실행 전에 만들어집니다.

실행 뷰

실행 뷰에서 첫 번째 실행 영역에는 RO 출력 섹션이 포함되고 두 번째 실행 영역에는 RW 및 ZI 출력 섹션이 포함됩니다.

RO 영역의 실행 주소는 로드 주소와 같으므로 RO 출력 섹션의 내용을 이동하거나 로드 주소에서 실행 주소로 복사할 필요가 없습니다. RO와 RW 실행 영역은 모두 루트 영역입니다.

RW output section

RO output sectionFirstloadregion

Load view

Secondloadregion

RAM

--ro-base value

--rw-base value

RW output section

RO output section

RW executionregion

RO executionregion

ZI executionregion

0x8000

ZI output section

Execution view

0x0000

0xE000



RW 영역의 실행 주소도 로드 주소와 같으므로 RW 출력 섹션의 내용이 로드 주소에서 실행 주소로 이동되지 않습니다. 그러나 ZI 출력 섹션은 런타임에 만들어져 RW 영역과 연속하도록 배치됩니다.

다음 링커 옵션을 사용하여 로드 및 실행 주소를 지정합니다.

--split 하나의 기본 로드 영역 (RO 및 RW 출력 섹션을 모두 포함)을 두 개의 루트 로드 영역 (각각 RO 출력 섹션과 RW 출력 섹션을 포함)으로 분할함으로써 --ro-base 및 --rw-base를 사용하여 두 가지 주소가 별도로 배치될 수 있도록 합니다.

--ro-base address

RO 섹션을 포함하는 영역의 로드 및 실행 주소를 4바이트로 정렬된 address (예: ROM에서 첫 번째 위치의 주소)에 설정하도록 armlink 에 지시합니다. --ro-base 옵션을 사용하여 주소를 지정하지 않으면 armlink는 기본값 0x8000 을 사용합니다.

--rw-base address

RW 출력 섹션을 포함하는 영역의 실행 주소를 4바이트로 정렬된 address에 설정하도록 armlink에 지시합니다. 이 옵션을 --split과 함께 사용하면 루트 영역과 같은 RW 영역의 로드 및 실행 주소가 모두 지정됩니다.



3.9 명령 행 옵션을 사용하여 C++ 예외 처리

기본적으로, 또는 --exceptions 옵션이 지정된 경우 이미지에 예외 테이블이 포함될 수 있습니다. 코드에서 예외를 throw하지 않으면 예외 테이블이 자동으로 무시됩니다. 그러나 --no_exceptions 옵션이 지정된 경우에는 사용하지 않는 섹션이 제거된 후에 예외 섹션이 발견되면 링커가 오류를 생성합니다.

코드가 예외의 영향을 받지 않도록 하려면 --no_exceptions 옵션을 사용할 수 있습니다. 링커가 오류 메시지를 생성하여 예외가 발견되었고 최종 이미지를 생성하지 못했다는 것을 강조 표시합니다.

그러나 --no_exceptions 옵션과 --diag_warning 옵션을 함께 사용하여 오류 메시지를 경고로 다운그레이드할 수 있습니다. 링커는 최종 이미지를 생성하지만 예외가 발견되었다고 경고하는 메시지도 생성합니다.

링커에서 디버그 프레임 정보를 포함하는 레거시 객체에 대한 예외 테이블을 만들 수 있습니다. 링커는 C 및 어셈블리 언어 객체에 대해 안전하게 이 작업을 수행할 수 있습니다. 기본적으로 링커는 예외 테이블을 만들지 않습니다. 이것은 링커 옵션 --exceptions_tables=nocreate를 사용하는 것과 같습니다.

링커 옵션--exceptions_tables=unwind를 사용하면 링커에서 .debug_frame 정보를 사용하여 아직 예외 테이블이 없는 이미지의 각 섹션에 대해 레지스터 복원 해제 테이블을 만들 수 있습니다. 이렇게 할 수 없는 경우에는 링커가 해제 없음 테이블을 만듭니다.

링커 옵션 --exceptions_tables=cantunwind를 사용하여 아직 예외 테이블이 없는 이미지의 각 섹션에 대해 해제 없음 테이블을 만들 수 있습니다.

참고

다음 사항에 유의하십시오.

• 기본 설정 즉, --exceptions --exception_tables=nocreate를 사용하는 경우 C 또는 어셈블리 코드를 통해 예외를 안전하게 throw할 수 있습니다 (--exceptions 옵션으로 C 코드를 컴파일하는 경우는 제외).

• 링커는 버전 1.2 이전의 RealView Compilation Tools로 컴파일된 코드 또는 --no_exceptions 옵션을 사용하여 컴파일된 코드와 같이 예외 지원 없이 컴파일된 C++ 코드의 자동 변수에 필요한 정리 코드를 생성할 수 없습니다.



3.10 이미지에 대한 정보 얻기

--info 옵션을 사용하여 링커가 이미지를 생성하는 방법에 대한 정보를 얻을 수 있습니다. 예를 들면, 다음과 같습니다.

armlink --info sizes ...

여기서 sizes는 이미지의 각 입력 객체와 라이브러리 구성원에 대한 코드 및 데이터 크기의 목록을 제공합니다. 이 옵션의 사용은 --info sizes,totals를 의미합니다.

자세한 내용은 링커 참조 설명서에서 2-28페이지의 --info=topic[,topic,...]을 참조하십시오.

예제 3-2에서는 출력을 표 형식으로 표시하고 합계는 읽기 쉽도록 별도로 표시합니다.

예제 3-2 이미지 정보

Code (inc. data) RO Data RW Data ZI Data Debug

3712 1580 19 44 10200 7436 Object Totals0 0 16 0 0 0 (incl. Generated)0 0 3 0 0 0 (incl. Padding)21376 648 805 4 300 10216 Library Totals 0 0 6 0 0 0 (incl. Padding)

===============================================================================

Code (inc. data) RO Data RW Data ZI Data Debug25088 2228 824 48 10500 17652 Grand Totals25088 2228 824 48 10500 17652 ELF Image Totals25088 2228 824 48 0 0 ROM Totals

===============================================================================

Total RO Size (Code + RO Data) 25912 ( 25.30kB)Total RW Size (RW Data + ZI Data) 10548 ( 10.30kB)Total ROM Size (Code + RO Data + RW Data) 25960 ( 25.35kB)

Code (inc. Data)

코드가 차지하는 바이트 수를 표시합니다. 이 이미지에는 3712바이트의 코드가 있습니다. 이 중에서 리터럴 풀과 짧은 문자열과 같은 인라인 데이터 (inc. data)는 1580바이트입니다.



RO Data 읽기 전용 데이터가 차지하는 바이트 수를 표시합니다. 이것은 Code (inc. data) 열에 있는 인라인 데이터에 추가됩니다.

RW Data 읽기/쓰기 데이터가 차지하는 바이트 수를 표시합니다.

ZI Data 0으로 초기화된 데이터가 차지하는 바이트 수를 표시합니다.

Debug 디버그 입력 섹션, 기호 및 문자열 테이블과 같은 디버그 데이터가 차지하는 바이트 수를 표시합니다.

Object Totals

이미지를 생성하기 위해 함께 링크된 객체가 차지하는 바이트 수를 표시합니다.

(incl. Generated)

armlink는 예를 들어, 인터워킹 베니어와 영역 테이블과 같은 입력 섹션 등의 이미지 내용을 생성할 수 있습니다. Object Totals 행에 이러한 유형의 데이터가 있으면 이 행에 표시됩니다. 3-33페이지의 예제 3-2에는 총 19바이트의 RO 데이터가 있고 이 중에 16바이트는 링커에서 생성한 RO 데이터입니다.

Library Totals

이미지에 개별 객체로 추출되고 추가된 라이브러리 구성원이 차지하는 바이트 수를 표시합니다.

(incl. Padding)

필요한 경우 armlink에서 패딩을 삽입하여 섹션 정렬을 강제로 수행합니다 (3-9페이지의 섹션 정렬 참조). Object Totals 행에 이러한 유형의 데이터가 있으면 연관된 (incl. Padding) 행에 표시됩니다. 마찬가지로 Library Totals 행에 이러한 유형의 데이터가 있으면 이와 연관된 행에 표시됩니다. 3-33페이지의 예제 3-2에는 객체 전체에 19바이트의 RO 데이터가 있으며 이 중 3바이트는 링커에서 생성한 패딩입니다. 라이브러리 전체에는 805바이트의 RO 데이터가 있으며 이 중 6바이트가 패딩입니다.

Grand Totals

이미지의 실제 크기를 표시합니다. 3-33페이지의 예제 3-2에서 Object Totals에는 10200바이트의 ZI 데이터가 있고 Library Total)에는 300바이트의 ZI 데이터가 있어 총 10500바이트를 표시합니다.



ELF Image Totals

RW 데이터 압축 (기본값)을 사용하여 ROM 크기를 최적화하는 경우 최종 이미지의 크기가 변경되고 이 변경 내용이 --info를 통한 출력에 반영됩니다. Grand Totals와 ELF Image Totals의 바이트 수를 비교하여 압축 결과를 확인합니다.

3-33페이지의 예제 3-2에서는 RW 데이터 압축을 사용하지 않습니다. 데이터를 압축하면 RW 값이 변경됩니다. 자세한 내용은 3-17페이지의 RW 데이터 압축을 참조하십시오.

ROM Totals

이미지를 포함하는 데 필요한 최소 ROM 크기를 표시합니다. 여기에 ROM에 저장되지 않는 ZI 데이터 및 디버그 정보는 포함되지 않습니다.

3.10.1 이미지 관련 정보 사용

--map 옵션을 사용하여 이미지 맵을 만들 수 있습니다. 이미지 맵에는 이미지에 있는 각 로드 영역, 실행 영역 및 입력 섹션의 주소와 크기가 포함되며 RW 데이터 압축이 적용되는 방법이 표시됩니다. 자세한 내용은 링커 참조 설명서의 2-41페이지의 --[no_]map을 참조하십시오.

--info inputs를 사용하여 일부 링크 오류의 소스를 식별할 수 있습니다. 예를 들어 출력을 검색하여 라이브러리 객체에서 정의되지 않은 참조를 찾거나 라이브러리 함수의 일부만 타겟 조정함으로써 여러 번 정의된 기호를 찾을 수 있습니다. 이 출력의 끝에서부터 역방향으로 검색하면 링크 오류를 찾아서 해결할 수 있습니다. 또한 --verbose 옵션을 사용하여 링커 작업에 대한 추가 정보가 포함된 유사한 텍스트를 출력할 수도 있습니다.



3.11 라이브러리 검색, 선택 및 스캔

링커에서 객체 파일을 이미지에 추가하는 방법과 라이브러리를 이미지에 추가하는 방법에는 다음과 같은 차이점이 있습니다.

• 입력 목록에 있는 각 객체 파일은 참조 여부에 상관없이 무조건적으로 출력 이미지에 추가됩니다. 최소한 하나의 객체가 지정되어야 합니다.

• 라이브러리 구성원은 객체 파일이나 이미 포함된 라이브러리 구성원이 해당 구성원을 비 weak하게 참조하거나 해당 구성원을 추가하도록 링커가 명시적인 지시를 받은 경우에만 출력에 포함됩니다.

참고

라이브러리 구성원이 입력 파일 목록에 명시적으로 요청된 경우에는 현재 아무런 참조를 확인하지 않더라도 로드됩니다. 이런 경우 명시적으로 요청된 구성원은 일반 객체와 마찬가지로 처리됩니다.

미사용 섹션은 --no_remove 또는 --keep을 사용하는 경우가 아닌 한 이후에 제거됩니다.

weak 기호에 대해 참조가 확인되지 않은 경우 라이브러리 구성원은 로드되지 않습니다.

참고

--no_scanlib 명령 행 옵션을 지정하면 링커에서는 기본 ARM 라이브러리를 검색하지 않고 입력 파일 목록에 지정된 라이브러리만 사용하여 참조를 확인합니다.

그러므로 링커에서는 다음과 같이 내부 라이브러리 목록을 만듭니다.

1. 입력 파일 목록에 명시적으로 지정된 라이브러리는 모두 목록에 추가됩니다.

2. 입력 객체에 임베드된 요청을 충족하기 위한 ARM 표준 라이브러리를 식별하기 위해 사용자가 지정한 검색 경로를 검사합니다.

검색한 디렉토리와 그 하위 디렉토리에서 가장 적합한 라이브러리 변형을 선택합니다. ARM에서 제공하는 라이브러리에는 구성원 특성에 따라 명명된 여러 가지 변형이 있습니다.



3.11.1 ARM 라이브러리 검색

다음과 같은 방법으로 ARM 표준 라이브러리를 찾는 데 사용할 검색 경로를 지정할 수 있습니다.

• RVCT40LIB 환경 변수를 사용합니다. 이것이 기본값입니다.

• 쉼표로 구분된 상위 디렉토리 목록과 함께 --libpath 옵션을 armlink 명령 행에 추가합니다.

이 목록은 ARM 라이브러리 디렉토리인 armlib와 cpplib의 상위 디렉토리로 종료되어야 합니다. RVCT40LIB 환경 변수에 이 경로가 포함됩니다.

참고

링커 명령 행 옵션인 --libpath는 RVCT40LIB 변수에서 지정한 경로를 재정의합니다.

링커에서는 --libpath 또는 RVCT40LIB 변수에서 지정된 각 상위 디렉토리를 입력 객체의 각 하위 디렉토리 요청과 결합하여 ARM 라이브러리 검색 위치를 확인합니다. 상위 디렉토리에 속해 있는 ARM 하위 디렉토리 이름은 Lib$$Request$$sub_dir_name 형식의 기호를 사용하여 각 컴파일된 객체에 배치됩니다.

검색의 순차적 특성으로 인해 두 개 이상의 라이브러리에서 동일한 기호를 정의한 경우 링커에서는 목록에 먼저 나타난 라이브러리를 선택합니다.

ARM 라이브러리 변형 선택

ARM 라이브러리에는 구성원 객체의 특성을 기반으로 하는 여러 가지 변형이 존재합니다. ARM 라이브러리 변형은 라이브러리 이름으로 코딩됩니다. 링커에서는 라이브러리 검색 중에 식별된 각 디렉토리에서 가장 적절한 변형을 선택해야 합니다.

링커에서는 각 입력 객체의 특성을 누적한 후 해당 특성에 가장 적합한 라이브러리 변형을 선택합니다. 선택한 라이브러리 중 둘 이상이 똑같이 적합한 경우 링커에서는 선택한 첫 번째 라이브러리를 보유하고 나머지는 모두 거부합니다.

최종 목록에는 링커에서 참조 확인을 위해 스캔하는 모든 라이브러리가 포함됩니다.

라이브러리 변형에 대한 자세한 내용은 라이브러리 설명서에서 2장 C 및 C++ 라이브러리를 참조하십시오.



3.11.2 사용자 라이브러리 검색

다음 방법으로 사용자 라이브러리를 지정할 수 있습니다.

• 사용자 라이브러리를 입력 파일 목록에 명시적으로 포함합니다.

• --userlibpath 옵션을 armlink 명령 행에 쉼표로 구분된 디렉토리의 목록과 함께 추가하고 라이브러리 이름을 입력 파일로 추가합니다.

명령 행에서 라이브러리의 전체 경로 이름을 지정하지 않으면 링커에서는 --userlibpath 옵션으로 지정한 디렉토리에서 라이브러리를 찾으려고 합니다. 예를 들어 /mylib 디렉토리에 my_lib.a 및 other_lib.a가 포함되어 있으면 /mylib/my_lib.a를 입력 파일 목록에 추가하여 다음 명령을 실행합니다.

armlink --userlibpath /mylib my_lib.a *.o

라이브러리에서 특정 구성원을 추가하는 경우 링커에서 사용하는 검색 가능한 라이브러리 목록에 해당 라이브러리가 추가되지는 않습니다. 특정 구성원을 로드할 뿐만 아니라 검색 가능한 라이브러리 목록에 해당 라이브러리도 추가하려면 라이브러리 filename 자체를 추가해야 할 뿐만 아니라 library (member)도 지정해야 합니다. 예를 들어 strcmp.o를 로드하고 mystring.lib를 검색 가능한 라이브러리 목록에 배치하려면 다음을 입력 파일 목록에 추가합니다.

mystring.lib (strcmp.o) mystring.lib

참고

RVCT40LIB 환경 변수나 링커 명령 행 옵션인 --libpath를 통해 지정한 ARM 표준 라이브러리의 검색 경로에서는 사용자 라이브러리가 검색되지 않습니다 (3-37페이지의 ARM 라이브러리 검색 참조).

3.11.3 라이브러리 스캔

링커에서는 일단 라이브러리 목록을 생성하면 목록에 있는 각 라이브러리를 반복적으로 스캔하여 참조를 확인합니다.

모든 디렉토리를 검색하여 가장 호환성이 높은 라이브러리 변형을 선택하고 이를 라이브러리 목록에 추가하면, 필요한 구성원을 로드하기 위해 각 라이브러리를 스캔합니다.

1. 현재 확인되지 않은 상태의 비 weak 참조가 있으면 링커에서는 일치하는 정의를 찾기 위해 라이브러리 목록을 순차적으로 검색합니다. 처음 찾은 정의는 2단계용으로 표시됩니다.



검색의 순차적 특성으로 인해 링커는 두 개 이상의 라이브러리에서 동일한 기호를 정의한 경우 목록에 먼저 나타난 라이브러리를 선택합니다. 그러면 라이브러리를 입력 파일 목록에 추가하여 ARM C 라이브러리 등의 다른 라이브러리의 함수 정의를 재정의할 수 있습니다. 그러나 라이브러리 구성원의 모든 기호를 일관성 있게 재정의해야 합니다. 이렇게 하지 않으면 동작을 예상할 수 없습니다.

2. 1단계에서 표시한 라이브러리 구성원이 로드됩니다. 각 구성원은 로드될 때 weak 참조를 포함한 일부 미확인 참조를 확인할 수 있습니다. 라이브러리 구성원을 로드하면 미확인 weak 및 비 weak 참조도 새로 생성될 수 있습니다.

3. 1단계와 2단계의 프로세스는 모든 비 weak 참조가 확인되거나 아니면 어떤 라이브러리로도 확인되지 않을 때까지 계속됩니다.

스캔 작업이 완료될 때 확인되지 않은 비 weak 참조가 하나라도 있으면 링커에서 오류 메시지를 생성합니다.




4장 이미지 기호 액세스

이 장에서는 ARM � 링커 (armlink)를 사용하여 기호를 참조하는 방법을 설명합니다. 여기에는 다음 단원이 포함되어 있습니다.

• 4-2페이지의 ARM/Thumb 동의어

• 4-3페이지의 링커 정의 기호 액세스

• 4-9페이지의 다른 이미지의 기호 액세스

• 4-12페이지의 전역 기호 숨기기 및 이름 바꾸기

• 4-14페이지의 $Super$$ 및 $Sub$$를 사용하여 기호 정의 재정의

• 4-15페이지의 기호 버전 관리


이미지 기호 액세스

4.1 ARM/Thumb 동의어

링커에서는 이미지에 한 기호에 대한 여러 정의가 함께 있는 것을 허용합니다. 단, 각 정의가 서로 다른 프로세서 상태와 연관되어 있어야 합니다. armlink에서는 ARM/Thumb 동의어가 있는 기호를 참조할 때 다음 규칙이 적용됩니다.

• ARM 상태의 기호에 대한 B, BL 또는 BLX 명령어는 ARM 정의로 확인됩니다.

• Thumb 상태의 기호에 대한 B, BL 또는 BLX 명령어는 Thumb 정의로 확인됩니다.

기호에 대한 다른 참조는 링커에서 발견하는 첫 번째 정의로 확인됩니다. 이 경우 armlink에서 선택한 기호를 명시하는 경고를 표시합니다.



4.2 링커 정의 기호 액세스

ARM 링커에서는 문자 시퀀스 $$를 포함하는 일부 기호를 정의합니다. 문자 시퀀스 $$가 포함된 이러한 기호 및 다른 모든 외부 이름은 모두 ARM에서 예약한 이름입니다.

이러한 기호 주소는 어셈블리 언어 프로그램을 통해 가져와 재배치 가능한 주소로 사용하거나, C 또는 C++ 소스 코드에서 extern 기호로 참조할 수 있습니다. 자세한 내용은 4-8페이지의 링커 정의 기호 가져오기를 참조하십시오.

참고

링커 정의 기호는 코드에서 이를 참조할 때만 생성됩니다.

4.2.1 영역 관련 기호

영역 관련 기호는 링커에서 이미지를 만들 때 생성됩니다.

Image$$ 실행 영역 기호

표 4-1에서는 링커가 이미지에 있는 모든 실행 영역에 대해 생성하는 기호를 보여 줍니다. 표 4-1의 모든 기호는 C 라이브러리를 초기화한 후에 실행 주소를 참조합니다.

표 4-1 Image$$ 실행 영역 기호

기호 설명

Image$$region_name$$Base 영역의 실행 주소

Image$$region_name$$Length ZI 길이를 제외한 바이트 단위의 실행 영역 길이

Image$$region_name$$Limit 실행 영역에 있는 ZI 부분이 아닌 부분의 끝을 초과하는 바이트의 주소

Image$$region_name$$RO$$Base 이 영역에 있는 RO 출력 섹션의 실행 주소

Image$$region_name$$RO$$Length 바이트 단위의 RO 출력 섹션 길이

Image$$region_name$$RO$$Limit 실행 영역에 있는 RO 출력 섹션의 끝을 초과하는 바이트의 주소

Image$$region_name$$RW$$Base 이 영역에 있는 RW 출력 섹션의 실행 주소

Image$$region_name$$RW$$Length 바이트 단위의 RW 출력 섹션 길이



Load$$ 실행 영역 기호

링커는 RW 압축 후에 로드 주소를 참조하는 재배치에 대해 추가 주소 할당 및 재배치 전달을 수행합니다. 이와 같이 지연된 재배치를 사용하면 로드 주소에 대해 더 많은 주소를 링커 정의 기호에 사용할 수 있습니다.

4-5페이지의 표 4-2에서는 링커가 이미지에 있는 모든 Load$$ 실행 영역에 대해 생성하는 기호를 보여 줍니다. 이 표의 모든 기호는 C 라이브러리를 초기화하기 전에 로드 주소를 참조합니다. 다음 사항에 유의하십시오.

• 섹션 상대 기호에는 실행 주소만 있을 수 있으므로 기호는 모두 절대 기호입니다.

• 기호는 RW 압축을 고려합니다.

• C 라이브러리를 초기화하기 전에는 ZI 출력 섹션이 없으므로 기호에는 이 섹션이 포함되지 않습니다.

• 링커는 압축된 데이터에 대해 지연된 재배치를 확인할 수 없으므로, RW 압축된 실행 영역으로부터의 모든 재배치는 압축 전에 수행해야 합니다.

• 링커는 RW 압축된 영역에서 RW 압축에 종속되는 링커 정의 기호로의 재배치를 감지하면 해당 영역에 대해 압축을 비활성화합니다.

Image$$region_name$$RW$$Limit 실행 영역에 있는 RW 출력 섹션의 끝을 초과하는 바이트의 주소

Image$$region_name$$ZI$$Base 이 영역에 있는 ZI 출력 섹션의 실행 주소

Image$$region_name$$ZI$$Length 바이트 단위의 ZI 출력 섹션 길이

Image$$region_name$$ZI$$Limit 실행 영역에 있는 ZI 출력 섹션의 끝을 초과하는 바이트의 주소

표 4-1 Image$$ 실행 영역 기호 (계속)

기호 설명



• 파일에 쓴 모든 0바이트는 표시됩니다. 따라서 한계 및 길이 값은 파일에 쓴 0바이트를 고려해야 합니다.

Load$$LR$$ 로드 영역 기호

표 4-3에서는 링커가 이미지에 있는 모든 Load$$LR$$ 로드 영역에 대해 생성하는 기호를 보여 줍니다. 단일 Load$$LR$$ 로드 영역에 많은 실행 영역이 포함될 수 있으므로, 별도의 $$RO 및 $$RW 구성요소는 없습니다.

표 4-2 Load$$ 실행 영역 기호

기호 설명

Load$$region_name$$Base 영역의 로드 주소

Load$$region_name$$Length 바이트 단위의 로드 영역 길이

Load$$region_name$$Limit 실행 영역 끝을 초과하는 바이트의 주소

Load$$region_name$$RO$$Base 이 실행 영역에 있는 RO 출력 섹션의 주소

Load$$region_name$$RO$$Length 바이트 단위의 RO 출력 섹션 길이

Load$$region_name$$RO$$Limit 실행 영역에 있는 RO 출력 섹션의 끝을 초과하는 바이트의 주소

Load$$region_name$$RW$$Base 이 실행 영역에 있는 RW 출력 섹션의 주소

Load$$region_name$$RW$$Length 바이트 단위의 RW 출력 섹션 길이

Load$$region_name$$RW$$Limit 실행 영역에 있는 RW 출력 섹션의 끝을 초과하는 바이트의 주소

표 4-3 Load$$LR$$ 로드 영역 기호

기호 설명

Load$$LR$$load_region_name$$Base 로드 영역 주소

Load$$LR$$load_region_name$$Length 로드 영역 길이

Load$$LR$$load_region_name$$Limit 로드 영역 끝을 초과하는 바이트의 주소



스캐터 로딩을 사용하지 않는 경우의 영역 이름 값

스캐터 로딩을 사용하지 않는 경우 링커에서 다음의 region_name 값을 사용합니다.

• 읽기 전용 실행 영역의 경우 ER_RO

• 읽기/쓰기 실행 영역의 경우 ER_RW

• 0으로 초기화된 실행 영역의 경우 ER_ZI

참고

• 이미지의 ZI 출력 섹션은 정적으로 생성되지 않고 런타임에 동적으로 자동 생성됩니다. 그러므로 ZI 출력 섹션에 대한 로드 주소 기호는 없습니다.

• 섹션 관련 기호보다 영역 관련 기호를 우선적으로 사용하는 것이 좋습니다.


스캐터 로딩을 사용하는 경우 설명 파일에서 이미지에 있는 모든 실행 영역의 이름을 지정하고 해당 로드 및 실행 주소를 제공합니다.

설명 파일에서 스택과 힙을 둘 다 정의하면 링커에서 특수 스택 및 힙 기호도 생성합니다.

자세한 내용은 5장 스캐터 로딩 설명 파일 사용을 참조하십시오.

ZI 영역 위에 스택 및 힙 배치

영역 관련 기호를 사용하는 한 가지 흔한 예는 힙을 ZI 영역 바로 위에 배치하는 것입니다. 예제 4-1에는 타겟이 조정된 __user_initial_stackheap () 버전을 어셈블리 언어로 만드는 방법이 나와 있습니다. 이 예제에서는 사용자가 ARM C 라이브러리에서 기본 단일 영역 메모리 모델을 사용한다고 가정합니다.

라이브러리 설명서의 2-80페이지의 __user_initial_stackheap()을 참조하십시오.

예제 4-1 ZI 영역 위에 스택 및 힙 배치

EXPORT __user_initial_stackheap IMPORT ||Image$$region_name$$ZI$$Limit||__user_initial_stackheap LDR r0, =||Image$$region_name$$ZI$$Limit|| MOV pc, lr



4.2.2 섹션 관련 기호

명령 행 옵션을 사용하여 단순 이미지를 만드는 경우 표 4-4에 표시된 출력 섹션 기호가 생성됩니다. 단순 이미지에는 세 실행 영역을 생성하는 세 가지 출력 섹션 (RO, RW 및 ZI)이 있습니다. 이미지에 있는 모든 입력 섹션에 대해 링커에서는 4-8페이지의 표 4-5에 표시된 입력 기호를 생성합니다.

링커에서는 실행 영역 내에서 먼저 RO, RW 또는 ZI 특성에 따라 섹션을 정렬하고 그 다음에는 이름별로 섹션을 정렬합니다. 따라서 모든 .text 섹션은 하나의 연속되는 블록에 배치됩니다. 특성과 이름이 같은 섹션들의 연속적 블록을 통합 섹션이라고 합니다.

이미지 기호

스캐터 로딩 설명 파일을 사용하면 표 4-4의 출력 섹션 기호가 정의되지 않습니다. 코드가 이러한 기호에 액세스하면 weak 참조로 처리해야 합니다.

__user_initial_stackheap ()의 표준 구현은 Image$$ZI$$Limit의 값을 사용합니다. 따라서 스캐터 로딩 설명 파일을 사용하는 경우 스택 및 힙을 수동으로 배치해야 합니다. 이 작업은 스캐터 설명 파일에서 수행하거나 __user_initial_stackheap ()을 다시 구현하여 힙 및 스택 경계를 설정해 수행할 수 있습니다. 자세한 내용은 5장 스캐터 로딩 설명 파일 사용을 참조하십시오.

표 4-4 이미지 관련 기호

기호 섹션 유형 설명

Image$$RO$$Base 출력 RO 출력 섹션 시작의 주소

Image$$RO$$Limit 출력 RO 출력 섹션의 끝을 초과하는 첫 번째 바이트의 주소

Image$$RW$$Base 출력 RW 출력 섹션 시작의 주소

Image$$RW$$Limit 출력 ZI 출력 섹션의 끝을 초과하는 바이트의 주소 (RW 영역의 끝보다는 ZI 영역의 끝을 선택하면 레거시 코드와의 호환성이 유지됨)

Image$$ZI$$Base 출력 ZI 출력 섹션 시작의 주소

Image$$ZI$$Limit 출력 ZI 출력 섹션의 끝을 초과하는 바이트의 주소



입력 섹션 기호

코드에서 입력 섹션 기호를 참조하는 경우, 이미지에 있는 이름이 같은 모든 입력 섹션이 이미지 메모리 맵에 연속적으로 배치되도록 의도한 것으로 가정됩니다. 스캐터 로딩 설명에서 이러한 입력 섹션을 비연속적으로 배치한 경우, 비연속적 메모리에서 기본 및 한계 기호를 사용하면 일반적으로 예상할 수 없고 적절하지 않은 결과가 발생하기 때문 링커에서 오류를 진단합니다.

4.2.3 링커 정의 기호 가져오기

링커 정의 기호를 C 또는 C++ 소스 코드로 가져오는 두 가지 방법이 있습니다.. 다음 중 하나를 사용하십시오.

extern unsigned int symbol_name;

또는

extern char symbol_name[];

기호를 int로 선언하는 경우 예제 4-2에 나와 있는 대로 연산자의 주소를 사용하여 올바른 값을 얻어야 합니다.

예제 4-2 링커 정의 기호 가져오기

extern unsigned int Image$$ZI$$Length;extern char Image$$ZI$$Base[];memset (Image$$ZI$$Base,0, (unsigned int)&Image$$Length);

표 4-5 섹션 관련 기호

기호 섹션 유형 설명

SectionName$$Base 입력 SectionName 이라는 통합 섹션 시작의 주소

SectionName$$Length 입력 SectionName 이라는 통합 섹션의 길이 (바이트)

SectionName$$Limit 입력 SectionName 이라는 통합 섹션의 끝을 초과하는 바이트의 주소



4.3 다른 이미지의 기호 액세스

한 이미지에서 다른 이미지의 전역 기호 값을 알도록 하려면 기호 정의 (symdefs) 파일을 사용할 수 있습니다.

예를 들어, 항상 ROM에 있는 이미지 하나와 RAM으로 로드된 여러 이미지가 있는 경우 기호 정의 파일을 사용할 수 있습니다. RAM에 로드된 이미지에서 ROM에 있는 이미지의 전역 함수와 데이터에 액세스할 수 있습니다.

4.3.1 symdefs 파일 만들기

symdefs 파일을 생성하려면 armlink 옵션 --symdefs=filename을 사용합니다.

링커에서는 성공한 마지막 링크 단계 중에 symdefs 파일을 생성합니다. 부분 링크나 성공하지 못한 마지막 링크의 경우에는 파일이 생성되지 않습니다.

참고

filename이 없으면 모든 전역 기호를 포함한 해당 파일이 만들어집니다. filename이 있으면 filename의 기존 내용이 링커에서 파일을 다시 작성할 때 출력되는 기호를 선택하는 데 사용됩니다. 즉, 파일 이름의 기존 기호만 업데이트되고 새 기호 (있는 경우)는 추가되지 않습니다. 이 동작을 원하지 않으면 링크 단계 전에 기존 symdefs 파일을 모두 삭제해야 합니다.

전역 기호의 하위 세트 출력

기본적으로 모든 전역 기호는 symdefs 파일에 작성됩니다.

filename이 있는 경우, 링커에서는 해당 내용을 사용하여 전역 기호의 하위 세트로 출력을 제한합니다. 출력 기호를 제한하려면 다음을 수행하십시오.

1. image1에 대해 마지막에 가까운 링크 작업을 할 때 --symdefs=filename을 지정합니다. 링커에서 symdefs 파일 filename을 만듭니다.

2. 텍스트 편집기에서 filename을 열어 최종 목록에 포함하지 않을 기호 항목을 제거한 다음 파일을 저장합니다.

3. image1에 대해 마지막 링크 작업을 할 때 --symdefs=filename을 지정합니다.

언제든지 filename을 편집하여 주석을 추가하고 image1을 다시 링크할 수 있습니다. 예를 들어, image1을 만드는 데 사용한 객체가 하나 이상 변경된 후 기호 정의를 업데이트하기 위해 이렇게 할 수 있습니다.



4.3.2 symdefs 파일 읽기

symdefs 파일은 기호 정보는 있지만 코드나 데이터는 없는 개체 파일로 간주할 수 있습니다. symdefs 파일을 읽으려면 개체 파일을 추가할 때처럼 symdefs 파일을 파일 목록에 추가합니다. 링커에서 파일을 읽고 기호와 그 값을 출력 기호 테이블에 추가합니다. 추가된 기호에는 ABSOLUTE 및 GLOBAL 특성이 있습니다.

부분 링크를 수행하고 있는 경우 기호가 출력 개체 기호 테이블에 추가됩니다. 전체 링크를 수행하고 있는 경우 기호가 이미지 기호 테이블에 추가됩니다.

링커에서 파일의 잘못된 행에 대해 오류 메시지를 생성합니다. 행이 잘못된 경우는 다음과 같습니다.

• 열이 누락된 경우

• 열에 잘못된 값이 있는 경우

symdefs 파일에서 추출한 기호는 개체 기호 테이블에서 추출한 기호와 똑같은 방식으로 처리됩니다. 여러 기호 정의 및 ARM/Thumb 동의어에 대해 같은 제한이 적용됩니다.

4.3.3 symdefs 파일 형식

symdefs 파일은 기호와 그 값을 포함합니다.

symdefs 파일은 예제 4-3에 나와 있는 대로 식별 행, 주석 (선택 사항) 및 기호 정보로 이루어져 있습니다.

예제 4-3 symdefs 파일 형식

#<SYMDEFS># ARM Linker, RVCTver [Build num]: Last Updated: Date;value type name, this is an added comment0x00008000 A __main0x00008004 A __scatterload0x000080E0 T main0x0000814D T _main_arg0x0000814D T __argv_alloc0x00008199 T __rt_get_argv... # This is also a comment, blank lines are ignored...0x0000A4FC D __stdin0x0000A540 D __stdout0x0000A584 D __stderr0xFFFFFFFD N __SIG_IGN



식별 문자열

텍스트 파일의 처음 11자가 #<SYMDEFS>#이면 그 파일은 링커에서 symdefs 파일로 인식합니다.

식별 문자열 뒤에는 링커 버전 정보와 symdefs 파일의 최근 업데이트 날짜 및 시간이 옵니다. 버전 및 업데이트 정보는 식별 문자열의 일부가 아닙니다.

주석

텍스트 편집기를 사용하여 주석을 수동으로 삽입할 수 있습니다. 주석에는 다음 속성이 있습니다.

• 첫 행은 특수 식별 주석인 #<SYMDEFS>#로 시작해야 합니다. 이 주석은 파일 생성 시 링커에서 삽입되며, 수동으로 삭제하면 안됩니다.

• 공백이 아닌 첫 번째 문자가 세미콜론 (;)이나 샵 (#) 문자인 행은 주석입니다.

• 공백이 아닌 첫 번째 문자 다음에 오는 세미콜론 (;)이나 샵 (#) 문자는 주석을 이끌지 않습니다.

• 공백인 행은 무시되며 가독성을 높이기 위해 삽입될 수 있습니다.

기호 정보

기호 정보는 한 행에 기호의 주소, 유형 및 이름으로 제공됩니다.

기호 값 링커에서는 기호의 절대 주소를 고정 16진수 형식 (예: 0x00008000)으로 씁니다. 파일을 편집하는 경우 주소 값으로 16진수 또는 10진수 형식을 사용할 수 있습니다.

유형 플래그 기호 유형을 나타내는 단일 문자

A ARM 코드

T Thumb 코드

D 데이터

N 숫자

기호 이름 기호 이름



4.4 전역 기호 숨기기 및 이름 바꾸기

이 단원에서는 조정 파일을 사용하여 출력 파일의 기호 이름을 관리하는 방법에 대해 설명합니다. 예를 들어, 조정 파일을 사용하여 지적 재산을 보호하거나 네임스페이스 충돌을 방지할 수 있습니다. 조정 파일은 출력 개체의 기호 테이블을 편집하기 위한 명령 집합이 들어 있는 텍스트 파일입니다.

armlink 명령 행 옵션 --edit file-list를 사용하여 조정 파일을 지정합니다. 둘 이상의 조정 파일을 지정하는 경우 다음 중 한 구문을 사용할 수 있습니다.

armlink --edit file1 --edit file2 --edit file3

armlink --edit file1,file2,file3

쉼표와 파일 이름 사이에 공백을 포함하면 안 됩니다. 자세한 내용은 2-19페이지의 --edit=file_list를 참조하십시오.

4.4.1 조정 파일 형식

조정 파일은 다음과 같은 형식의 일반 텍스트 파일입니다.

• 공백이 아닌 첫 번째 문자가 세미콜론 (;) 또는 샵 (#) 문자인 행은 주석으로 해석됩니다. 주석은 빈 행으로 처리됩니다.

• 빈 행은 무시됩니다.

• 비어 있지도 않고 주석도 아닌 행은 하나의 명령이거나, 비어 있지 않은 연속 행에 분할되어 있는 명령의 일부입니다.

• 공백이 아닌 마지막 문자가 쉼표 (,)로 끝난 명령 행은 비어 있지 않은 다음 행으로 이어집니다.

각 명령 행은 명령과 그 뒤에 따라오는 하나 이상의 피연산자 그룹 (쉼표로 구분)으로 이루어집니다. 각 피연산자 그룹은 명령에 따라 한두 개의 피연산자로 구성됩니다. 명령은 해당 명령 내의 각 피연산자 그룹에 적용됩니다. 다음 규칙이 적용됩니다.

• 명령은 대소문자를 구분하지만 일반적으로 대문자로 표시됩니다.

• 피연산자는 대소문자가 구분된 기호 이름에 대해 일치해야 하므로 대소문자를 구분합니다. 피연산자에 와일드카드 문자를 사용할 수 있습니다.

명령은 전역 기호에만 적용되고, 지역 기호와 같은 기타 기호에는 적용되지 않습니다.



조정 파일 명령에 대한 자세한 내용은 링커 참조 설명서에서 다음 단원을 참조하십시오.

• 2-73페이지의 IMPORT

• 2-71페이지의 EXPORT

• 2-74페이지의 RENAME

• 2-76페이지의 RESOLVE

• 2-75페이지의 REQUIRE

• 2-72페이지의 HIDE

• 2-78페이지의 SHOW



4.5 $Super$$ 및 $Sub$$를 사용하여 기호 정의 재정의

기존 기호를 수정할 수 없는 경우가 있습니다. 예를 들어, 기존 기호가 외부 라이브러리나 ROM 코드에 있는 경우에는 수정할 수 없습니다.

이런 경우 $Super$$ 및 $Sub$$ 패턴을 사용하여 기존 기호를 패치할 수 있습니다.

예를 들어, foo () 함수의 정의를 패치하려면 다음 $Super$$foo () 및 $Sub$$foo ()를 사용합니다.

$Super$$foo 패치하지 않은 원래의 foo () 함수를 식별합니다. 원래 함수를 직접 호출하려면 이것을 사용합니다.

$Sub$$foo 원래의 foo () 함수 대신 호출되는 새 함수를 식별합니다. 원래 함수 앞 또는 뒤에 처리를 추가하려면 이것을 사용합니다.

참고

$Sub 및 $Super 메커니즘은 정적 링크 타임에만 작동하며, $Super$$ 참조는 동적 기호 테이블로 가져오거나 내보낼 수 없습니다.

예제 4-4에는 ExtraFunc ()와 foo ()를 각각 호출하도록 수정된 레거시 함수 foo ()가 나와 있습니다. 자세한 내용은 ARM 아키텍처용 ELF를 참조하십시오.

예제 4-4 $Super$$ 및 $Sub$$ 사용

extern void ExtraFunc (void);extern void $Super$$foo (void):

/* this function is called instead of the original foo () */void $Sub$$foo (void){ ExtraFunc (); /* does some extra setup work */ $Super$$foo (); /* calls the original foo () function */}



4.6 기호 버전 관리

기호 버전 관리를 사용하면 동적 공유 객체에서 가져온 기호 및 동적 공유 객체가 내보낸 기호에 대한 추가 정보가 기록됩니다. 동적 로더는 이 추가 정보를 사용하여 이미지에 필요한 모든 기호를 로드 타임에 사용할 수 있도록 합니다.

기호 버전 관리를 사용하면 공유 개체 작성자가 이전 버전의 공유 개체에 대해 링크된 클라이언트와의 호환성을 유지하면서도 모든 새 클라이언트에서 사용할 수 있는 새 버전의 기호를 생성할 수 있습니다.

4.6.1 버전

기호 버전 관리는 버전의 개념을 동적 기호 테이블에 추가합니다. 버전은 기호와 연관된 이름입니다. 동적 로더가 버전 이름과 연관된 기호 참조를 확인할 때 버전 이름이 같은 기호 정의에 대해서만 일치시킬 수 있습니다.

참고

버전은 공유 개체의 수정 기록을 표시하기 위해 이전 버전의 이름과 연관될 수 있습니다.

4.6.2 기본 버전

공유 개체에는 동일한 기호의 여러 버전이 있을 수 있는 반면, 공유 개체의 클라이언트는 최신 버전에 대해서만 바인드할 수 있습니다.

이것을 기호의 기본 버전이라고 합니다.

4.6.3 버전 관리된 기호 만들기

기본적으로 링커에서는 비 BPABI 공유 객체에 대해 버전 관리된 기호를 만들지 않습니다.

임베디드 기호

특별하게 명명한 기호를 입력 객체에 추가할 수 있습니다. 그러면 링커에서 기호 버전을 만듭니다. 이러한 기호의 형식은 다음과 같습니다.

• 기본이 아닌 버전의 기호인 경우 name@version

• 기본 버전의 기호인 경우 name@@version



이러한 기호는 내보낼 형식으로 함수나 데이터의 주소에 정의해야 합니다. 기호 이름은 기호의 이름인 name과 버전 정의인 version으로 나뉩니다. name은 동적 기호 테이블에 추가되며 공유 객체 인터페이스의 일부분이 됩니다. 버전은 ver이라는 버전이 없는 경우 만들고 name을 ver이라는 버전에 연결합니다.

버전 기호를 만드는 방법에 대한 자세한 내용은 다음을 참조하십시오.

• 컴파일러 사용 설명서의 2-31페이지의 기호 버전 추가

• 어셈블러 설명서의 2장 ARM 어셈블리 언어 작성

예제 4-5에서는 foo@ver1, foo@@ver2 및 bar@@ver1 기호를 객체 기호 테이블에 배치합니다.

예제 4-5 버전 관리된 기호, 임베디드 기호 만들기

int old_function (void) __asm__ ("foo@ver1");int new_function (void) __asm__ ("foo@@ver2");int other_function (void) __asm__ ("bar@@ver1");

링커에서는 이 기호를 읽고 버전 정의 ver1 및 ver2를 만듭니다. 기호 foo는 ver1의 기본이 아닌 버전 및 ver2의 기본 버전과 연관됩니다. 기호 bar는 ver1의 기본 버전과 연관됩니다.

이 방법으로 버전 간의 연관을 만들 수는 없습니다.

조정 파일

명령 행 옵션 --symver_script=file에서 지정하는 스크립트 파일에 기호 버전을 생성하도록 하는 명령을 포함할 수 있습니다. 이 옵션을 사용하면 자동으로 기호 버전 관리가 실행됩니다.

스크립트 파일은 GNU ld 링커와 동일한 구문을 지원합니다.

스크립트 파일을 사용하면 버전을 이전 버전과 연관시킬 수 있습니다.

조정 파일은 임베디드 기호 방법과 함께 제공될 수 있습니다. 자세한 내용은 4-12페이지의 조정 파일 형식을 참조하십시오. 이 방식을 선택한 경우, 스크립트 파일이 임베디드 기호와 일치해야 하며 BNF (Backus-Naur Form) 표시를 사용해야 합니다.

version_definition ::=

version_name "{" symbol_association* "}" [depend_version] ";"



version_name은 버전 이름을 포함하는 문자열입니다. depend_version은 이 version_name이 종속되는 버전 이름이 포함된 문자열입니다. 이 버전은 스크립트 파일에 이미 정의되어 있어야 합니다. 버전 이름은 중요하지는 않지만 읽을 수 있는 이름을 선택하도록 돕는 역할을 합니다. 예를 들면 다음과 같습니다.

symbol_association ::=

"local:" | "global:" | symbol_name ";"

인수 설명:

• "local:"은 이 버전 정의에 있는 모든 후속 symbol_name이 공유 개체에 대한 지역 기호이며 버전 관리되지 않았음을 나타냅니다.

• "global:"은 모든 후속 symbol_name이 이 버전 정의에 속한다는 것을 나타냅니다.

각 버전 정의의 시작 부분에 암시적 "global:"이 있습니다.

• symbol_name은 정적 기호 테이블에 있는 전역 기호의 이름입니다.

예제 4-6에는 ver2가 ver1에 종속되도록 종속 정보가 추가된 임베디드 기호의 예 (4-16페이지의 예제 4-5)에 상응하는 조정 파일이 나와 있습니다.

예제 4-6 버전 관리된 기호, 조정 파일 만들기

ver1{

global:foo; bar;

local:*;

};

ver2{

global:foo;

} ver1;

오류 및 경고

스크립트 파일을 사용하는 경우 버전 정의는 그와 연관된 기호와 일치해야 합니다. 링커에서는 불일치를 감지하면 경고합니다.



파일 이름

명령 행 옵션 --symver_soname을 사용하여 암시적 기호 버전 관리를 설정할 수 있습니다. 정적 바인딩을 강제로 수행하기 위해 기호의 버전을 관리해야 하지만 주어진 버전 번호에 대해서는 상관하지 않는 경우 이 옵션을 사용합니다.

기호에 버전이 정의되지 않은 경우 링커에서는 링크되는 파일의 SONAME을 사용합니다.

이 옵션은 임베디드 기호나 스크립트 파일과 함께 사용할 수 없습니다.


5장 스캐터 로딩 설명 파일 사용

이 장에서는 ARM � 링커 (armlink)를 스캐터 로딩 설명 파일과 함께 사용하여 복잡한 이미지를 만드는 방법에 대해 설명합니다. 여기에는 다음 단원이 포함되어 있습니다.

• 5-2페이지의 스캐터 로딩 개요

• 5-9페이지의 영역 및 섹션 주소 지정의 예제

• 5-32페이지의 단순 이미지에 대한 해당 스캐터 로딩 설명



5.1 스캐터 로딩 개요

이미지는 영역과 출력 섹션으로 구성됩니다. 이미지에 있는 각 영역의 로드 및 실행 주소는 서로 다를 수 있습니다. 자세한 내용은 3-2페이지의 이미지 구조체 지정을 참조하십시오.

이미지의 메모리 맵을 구성하려면 링커에 다음과 같은 정보가 있어야 합니다.

• 입력 섹션을 출력 섹션 및 영역으로 그룹화하는 방법을 설명하는 그룹화 정보

• 메모리 맵에서 영역이 위치하는 주소를 설명하는 배치 정보

스캐터 로딩 메커니즘을 통해 텍스트 파일의 설명을 사용하여 이미지의 메모리 맵을 링커에 지정할 수 있습니다. 스캐터 로딩을 사용하면 이미지 구성요소의 그룹화 및 배치를 완전하게 제어할 수 있습니다. 스캐터 로딩은 단순한 이미지에도 사용할 수는 있지만, 대개는 로드 및 실행 시 다중 영역이 메모리 맵에 분산되는 복잡한 메모리 맵을 가진 이미지에 사용됩니다.

5.1.1 스캐터 로딩에 대해 정의된 기호

링커에서는 스캐터 로딩 설명 파일을 사용하여 이미지를 만들 때 영역 관련 기호를 만들 수 있습니다. 이 기호에 대해서는 4-3페이지의 영역 관련 기호에서 설명합니다. 코드에서 해당 기호를 참조하는 경우에만 링커에서 이러한 특별한 기호를 만듭니다.

정의되지 않은 기호

다음 기호는 스캐터 로딩 설명 파일이 사용될 때는 정의되지 않습니다.

• Image$$RW$$Base

• Image$$RW$$Limit

• Image$$RO$$Base

• Image$$RO$$Limit

• Image$$ZI$$Base

• Image$$ZI$$Limit

자세한 내용은 4-3페이지의 링커 정의 기호 액세스를 참조하십시오.

스캐터 로딩 설명 파일을 사용하지만 특별한 영역 이름을 지정하지 않고 __user_initial_stackheap ()을 다시 구현하지 않는 경우, 라이브러리에서 다음과 같은 오류 메시지를 생성합니다.




• 라이브러리 및 부동 소수점 지원 설명서의 2-77페이지의 런타임 메모리 모델 조정

• 개발자 설명서의 3-13페이지의 스택 및 힙 배치

5.1.2 스캐터 로딩 설명 파일을 통한 스택 및 힙 지정

ARM C 라이브러리는 __user_initial_stackheap () 함수의 여러 가지 구현을 제공하며 스캐터 로딩 설명 파일에 주어진 정보를 통해 해당 상황에 적합한 구현을 자동으로 선택합니다.

2-영역 메모리 모델을 선택하려면 스캐터 로딩 설명 파일에 ARM_LIB_HEAP과 ARM_LIB_STACK이라는 두 개의 특별한 실행 영역을 정의합니다. 두 영역 모두에 EMPTY 속성이 있습니다. 따라서 다음 기호 값을 사용하며 __user_initial_stackheap ()의 기본 구현이 아닌 구현을 라이브러리에서 선택하게 됩니다.

• Image$$ARM_LIB_STACK$$Base

• Image$$ARM_LIB_STACK$$ZI$$Limit

• Image$$ARM_LIB_HEAP$$Base

• Image$$ARM_LIB_HEAP$$ZI$$Limit

하나의 ARM_LIB_STACK 또는 ARM_LIB_HEAP 영역만 지정할 수 있으며 다음 예와 같이 크기를 할당해야 합니다.

ARM_LIB_HEAP 0x20100000 EMPTY 0x100000-0x8000 ; Heap starts at 1MB; and grows upwards

ARM_LIB_STACK 0x20200000 EMPTY -0x8000 ; Stack space starts at the end; of the 2MB of RAM; And grows downwards for 32KB

참고

위의 스택 함수를 사용하는 경우에는 어셈블리 소스에 IMPORT __use_two_region_memory를 포함하거나 C/C++ 소스에 #pragma import (__use_two_region_memory)를 포함해야 합니다. 2-영역 모델은 자동으로 선택되지 않기 때문입니다.

EMPTY 속성을 갖는 ARM_LIB_STACKHEAP이라는 단일 실행 영역을 정의하여 __user_initial_stackheap () 함수가 결합된 스택/힙 영역을 사용하도록 할 수 있습니다. 이에 따라 __user_initial_stackheap ()에서 Image$$ARM_LIB_STACKHEAP$$Base 및 Image$$ARM_LIB_STACKHEAP$$ZI$$Limit 기호의 값을 사용합니다.



참고

__user_initial_stackheap ()을 다시 구현할 경우 모든 라이브러리 구현이 무시됩니다.

5.1.3 스캐터 로딩을 사용하는 경우

링커에 대한 명령 행 옵션은 데이터 및 코드 배치를 제어할 수 있도록 하지만 완전한 배치 제어를 위해서는 명령 행에서 입력할 수 있는 보다 자세한 명령어가 필요합니다. 스캐터 로딩 설명이 필요하거나 매우 유용한 상황은 다음과 같습니다.

복잡한 메모리 맵

코드와 데이터를 메모리의 여러 별개 영역에 배치해야 하는 경우 어느 섹션이 어느 메모리 공간에 들어가야 하는지에 대한 자세한 명령어가 필요합니다.

다양한 메모리 유형

많은 시스템에는 플래시, ROM, SDRAM 및 고속 SRAM과 같은 다양한 물리적 메모리 장치가 있습니다. 스캐터 로딩 설명은 코드와 데이터를 가장 적절한 메모리 유형과 일치시킬 수 있습니다. 예를 들어, 인터럽트 코드는 인터럽트 응답 시간을 향상시키기 위해 고속 SRAM에 배치하며 드물게 사용되는 구성 정보는 보다 느린 플래시 메모리에 배치할 수 있습니다.

메모리 매핑된 주변 기기

스캐터 로딩 설명은 메모리 매핑된 주변 기기에 액세스할 수 있도록 메모리 맵의 정확한 주소에 데이터 섹션을 배치할 수 있습니다.

일정한 위치의 함수

함수는 주변의 응용 프로그램이 수정되고 다시 컴파일된 경우에도 메모리의 동일한 위치에 배치될 수 있습니다. 이는 분기 테이블 구현에 유용합니다.

기호를 사용한 힙 및 스택의 확인

기호는 응용 프로그램이 링크될 때 힙 및 스택 위치에 대해 정의될 수 있습니다.

임베디드 시스템은 ROM, RAM 및 메모리 매핑된 주변 기기를 사용하기 때문에 임베디드 시스템을 구현하기 위해서는 스캐터 로딩이 거의 항상 필요합니다.



참고

Cortex™-M3 프로세서에 대해 컴파일하는 경우에는 고정 메모리 맵이 있으므로 스캐터 로딩 설명 파일을 사용하여 스택과 힙을 모두 정의할 수 있습니다. 이에 대한 예제는 예제 디렉토리 install_directory\RVDS\Examples\..\Cortex-M3\Example3로 제공됩니다.

5.1.4 스캐터 로딩 명령 행 옵션

스캐터 로딩을 사용하기 위한 armlink 명령 행 옵션은 다음과 같습니다.

--scatter=description_file

이 옵션은 description_file에 설명된 대로 이미지 메모리 맵을 생성하도록 링커에 지시합니다. 설명 파일 형식은 링커 참조 설명서의 3장 스캐터 로딩 설명 파일의 형식적 구문에 나와 있습니다.

스캐터 로딩 설명 파일에 대한 추가 정보는 다음을 참조하십시오.

• 5-9페이지의 영역 및 섹션 주소 지정의 예제

• 5-32페이지의 단순 이미지에 대한 해당 스캐터 로딩 설명

5.1.5 단순 메모리 맵을 가진 이미지

5-6페이지의 그림 5-1의 스캐터 로딩 설명은 객체 파일에서 5-6페이지의 그림 5-2에 표시된 맵에 해당하는 메모리로 세그먼트를 로드합니다. 영역의 최대 크기 지정은 선택 사항이지만 크기 지정이 포함되면 링커에서 영역이 영역 경계를 오버플로하지 않는지 확인할 수 있습니다.

이 예제에서는 --ro-base 0x0 및 --rw-base 0x10000을 링커에 대한 명령 행 옵션으로 지정하여 동일한 결과를 얻을 수 있습니다.



그림 5-1 스캐터 로딩 설명 파일의 단순 메모리 맵

그림 5-2 스캐터 로딩된 단순 메모리 맵

LOAD_ROM 0x0000 0x8000{

EXEC_ROM 0x0000 0x8000 { * (+RO) }

RAM 0x10000 0x6000 { * (+RW,+ZI) }}

Name ofload region

Name of firstexec region

Start address forload region

Start address forexec region

Place all code andRO data into thisexec region

Maximum size of thisexec region

Start of secondexec region

Place all RW and ZI datainto this exec region

Maximum size ofload region

Maximum size ofthis exec region

Name of secondexec region

0x0000

0x8000

RO section

RW section

RO section

Execution viewLoad view 0x16000

SRAM

ROM

RW section

ZI sectionZero fill0x10000

Copy / decompress



5.1.6 복잡한 메모리 맵을 가진 이미지

그림 5-3의 스캐터 로딩 설명은 program1.o 및 program2.o 파일에서 5-8페이지의 그림 5-4에 표시된 맵에 해당하는 메모리로 세그먼트를 로드합니다.

5-6페이지의 그림 5-2에 표시된 단순 메모리 맵과 달리 이 응용 프로그램은 기본 명령 행 옵션만 사용하여 링커에 지정될 수 없습니다.

주의

그림 5-3의 스캐터 로딩 설명은 program1.o 및 program2.o에 대해서만 코드 및 데이터의 위치를 지정합니다. program3.o와 같은 추가 모듈을 링크하고 이 설명 파일을 사용하는 경우 program3.o의 코드 및 데이터 위치는 지정되지 않습니다.

코드와 데이터의 배치에 매우 엄격하려고 하지 않는 한 * 또는 .ANY 지정자를 사용하여 나머지 코드와 데이터를 배치하는 것이 좋습니다. 자세한 내용은 5-11페이지의 고정 주소에 영역 배치를 참조하십시오.

그림 5-3 스캐터 로딩 설명 파일의 복잡한 메모리 맵

LOAD_ROM_1 0x0000{ EXEC_ROM_1 0x0000 { program1.o (+RO) }

DRAM 0x18000 0x8000 { program1.o (+RW,+ZI) }}

LOAD_ROM_2 0x4000{ EXEC_ROM_2 0x4000 { program2.o (+RO) }

SRAM 0x8000 0x8000 { program2.o (+RW,+ZI) }}

Start address for first load region

Start address for first exec region

Place all code and RO data fromprogram1.o into this exec region

Maximum size of this exec region

Place all RW and ZI data fromprogram1.o into this exec region

Start address for second load region

Place all code and RO data fromprogram2.o into this exec region

Place all RW and ZI data fromprogram2.o into this exec region

Start address for this exec region



그림 5-4 복잡한 스캐터 로딩된 메모리 맵

0x00000

0x08000

RO section#2

RO section#1

ZI section#1

RW section#2

RW section#1

RO section#2

RW section#2

0x18000

ZI section#2

RW section#1

RO section#1

Execution viewLoad view 0x20000

DRAM

SRAM

ROM2

Zero fill

0x0000

0x4000

0x10000

ROM1



5.2 영역 및 섹션 주소 지정의 예제

이 단원에서는 입력 및 실행 섹션, 영역 및 사전 처리 지시어에 대해 설명합니다. 고정 주소에서 데이터와 함수에 액세스하는 예제는 개발자 설명서의 3장 임베디드 소프트웨어 개발을 참조하십시오.

5.2.1 스캐터 로딩 설명의 베니어 입력 섹션 선택

베니어는 ARM과 Thumb 코드 사이를 전환하거나 단일 명령어에서 지정할 수 있는 것보다 긴 프로그램 점프를 수행하는 데 사용합니다. 자세한 내용은 3-20페이지의 베니어를 참조하십시오. 링커 생성 베니어 입력 섹션을 배치하려면 스캐터 로딩 설명 파일을 사용합니다. 스캐터 로딩 설명 파일에서 최대 한 개의 실행 영역에만 * (Veneer$$Code) 섹션 선택기가 있을 수 있습니다.

링커에서는 안전한 경우에만 * (Veneer$$Code) 섹션 선택기로 식별된 영역으로 베니어 입력 섹션을 배치합니다. 주소 범위와 관련된 문제나 실행 영역의 크기 제한으로 인해 베니어 입력 섹션이 지정한 영역에 할당되지 않을 수도 있습니다. 베니어를 지정한 영역에 추가할 수 없는 경우 베니어는 해당 베니어를 생성한 재배치된 입력 섹션을 포함하는 실행 영역에 추가됩니다.

참고

ARM 도구의 이전 버전에서 스캐터 로딩 설명 파일의 * (IWV$$Code) 인스턴스는 * (Veneer$$Code)로 자동으로 변환됩니다. 새 설명에서는 * (Veneer$$Code)를 사용합니다.

* (Veneer$$Code)는 실행 영역의 코드 크기가 Thumb 코드의 경우 4MB, Thumb-2 코드의 경우 16MB 및 ARM 코드의 경우 32MB를 초과하면 무시됩니다.

5.2.2 루트 실행 영역 만들기

사용자가 이미지의 초기 진입점을 지정하거나 ENTRY 지시어가 하나밖에 없어서 링커에서 초기 진입점을 만드는 경우 진입점은 루트 영역에 있어야 합니다. 루트 영역은 로드 및 실행 주소가 동일한 영역입니다. 초기 진입점이 루트 영역에 없으면 링크가 실패하고 링커에서 다음과 같은 오류 메시지를 생성합니다.



영역이 스캐터 로딩 설명 파일의 루트 영역임을 지정하려면 다음 중 하나를 수행합니다.

• ABSOLUTE를 명시적으로 또는 기본값이 될 수 있도록 실행 영역의 속성으로 지정하고 첫 번째 실행 영역과 바깥쪽 로드 영역에 대해 동일한 주소를 사용합니다. 실행 영역 주소를 로드 영역 주소와 동일하게 만들려면 다음 중 하나를 수행하십시오.

— 실행 영역의 기본 주소와 로드 영역의 기본 주소에 대해 동일한 숫자 값을 지정합니다.

— 로드 영역의 첫 번째 실행 영역에 대해 +0 오프셋을 지정합니다.

0의 오프셋 (+0)이 로드 영역의 모든 후속 실행 영역에 대해 지정되면 이 영역들은 모두 루트 영역이 됩니다.

자세한 내용은 예제 5-1을 참조하십시오.

• FIXED 실행 영역 속성을 사용하여 특정 영역의 로드 주소 및 실행 주소가 동일하게 되도록 합니다. 예제 5-2 및 5-11페이지의 그림 5-5를 참조하십시오.

FIXED 속성을 사용하여 ROM의 특정 주소에 실행 영역을 배치할 수 있습니다. 자세한 내용은 5-11페이지의 고정 주소에 영역 배치를 참조하십시오.

예제 5-1 동일한 로드 및 실행 주소 지정

LR_1 0x040000 ; load region starts at 0x40000 { ; start of execution region descriptions ER_RO 0x040000 ; load address = execution address { * (+RO) ; all RO sections (must include section with ; initial entry point) } ... ; rest of scatter description}

예제 5-2 FIXED 속성 사용

LR_1 0x040000 ; load region starts at 0x40000 { ; start of execution region descriptions ER_RO 0x040000 ; load address = execution address { * (+RO) ; RO sections other than those in init.o



} ER_INIT 0x080000 FIXED ; load address and execution address of this ; execution region are fixed at 0x80000 { init.o (+RO) ; all RO sections from init.o } ... ; rest of scatter description}

그림 5-5 고정 실행 영역의 메모리 맵

고정 주소에 영역 배치

실행 영역 스캐터 로딩 설명 파일에서 FIXED 속성을 사용하여 고정 주소에서 로드 및 실행되는 루트 영역을 만들 수 있습니다.

FIXED는 단일 로드 영역 (따라서 일반적으로 단일 ROM 장치) 안에 여러 루트 영역을 만드는 데 사용됩니다. 예를 들어, 포인터를 통해 쉽게 액세스할 수 있도록 ROM의 고정 주소에서 함수 또는 상수 테이블이나 체크섬과 같은 데이터 블록을 배치하는 데 사용할 수 있습니다.

예를 들어, 일부 초기화 코드가 ROM 시작 부분에 배치되고 체크섬은 ROM의 끝 부분에 배치되도록 지정하면 메모리 내용 중 일부는 사용하지 못할 수 있습니다. 초기화 블록의 끝과 데이터 블록의 시작 사이 영역을 가득 채우려면 * 또는 .ANY 모듈 선택기를 사용하십시오.

참고

코드 유지 관리와 디버그를 용이하게 하려면 스캐터 로딩 설명 파일에서 최소량의 배치 지정을 사용하고 자세한 함수 및 데이터의 배치는 링커에 남겨둡니다.

*(RO)


init.o

0x4000

0x80000

init.o

*(RO)

EmptySingleloadregion

Filled with zeroes or the value defined using the --pad option

(FIXED)

(movable)



부분적으로 링크된 구성요소 객체는 지정할 수 없습니다. 예를 들어, obj1.o, obj2.o 및 obj3.o를 함께 부분적으로 링크하여 obj_all.o를 생성하면 결과적인 구성요소 객체 이름은 결과 객체에서 폐기됩니다. 그러므로 obj1.o와 같은 이름으로 객체 중 하나를 참조할 수 없습니다. 결합된 객체 obj_all.o만 참조할 수 있습니다.

특정 주소에 함수 및 데이터 배치

일반적으로, 컴파일러에서는 단일 소스 파일에서 RO, RW 및 ZI 섹션을 생성합니다. 이러한 영역에는 소스 파일의 모든 코드와 데이터가 포함됩니다. 고정 주소에 단일 함수 또는 데이터 항목을 배치하려면 링커에서 나머지 입력 파일과 별도로 함수 또는 데이터를 처리할 수 있도록 해야 합니다.

링커에는 특정 주소에 섹션을 배치할 수 있도록 하는 두 가지 방법이 있습니다.

• 한 섹션만 선택하는 섹션 설명을 사용하여 예외 영역을 원하는 주소에 만들 수 있습니다.

• 특별하게 명명된 섹션의 경우 링커에서는 섹션 이름에서 배치 주소를 가져올 수 있습니다. 특별하게 명명된 이러한 섹션을 __at 섹션이라고 합니다. 자세한 내용은 5-17페이지의 __at 섹션을 사용하여 특정 주소에 섹션 배치를 참조하십시오.

특정 주소에 함수나 변수를 배치하려면 자체 섹션에 배치해야 합니다. 이렇게 하는 데는 몇 가지 방법이 있습니다.

• 자체 소스 파일에 함수 또는 데이터 항목을 배치합니다.

• --split_sections 컴파일러 옵션을 사용하면 소스 파일에 있는 각 함수에 대해 ELF 섹션을 하나씩 생성할 수 있습니다. 컴파일러 참조 설명서의 2-112페이지의 --split_sections를 참조하십시오.

이 옵션을 사용하면 함수 간에 주소, 데이터 및 문자열 리터럴을 공유할 가능성이 줄어들기 때문에 코드 크기가 약간 더 커질 수 있습니다. 그러나 이렇게 하면 armlink --remove를 지정할 때 링커에서 사용하지 않는 함수를 제거할 수 있게 되어 최종 이미지의 전체 크기를 줄이는 데 도움이 됩니다.

• 여러 명명된 섹션을 만들려면 __attribute__ ( (section (”name”))) 을 사용합니다. 컴파일러 참조 설명서의 4-47페이지의 __attribute__ ( (section))를 참조하십시오.



• 어셈블리 언어의 AREA 지시어를 사용합니다. 어셈블리 코드에서 가장 작은 배치 가능 단위는 AREA입니다. 자세한 내용은 어셈블러 설명서를 참조하십시오.



스캐터 로딩을 명시적으로 사용하여 명명된 섹션 배치

예제 5-3의 스캐터 로딩 설명 파일은 다음을 배치합니다.

• 0x0 주소에 초기화 코드 배치 (그 뒤에는 나머지 RO 코드와 data.o 객체의 RO 데이터를 제외한 모든 RO 데이터가 옴)

• 0x400000에 RAM의 모든 전역 RW 변수 배치

• 0x1FF00 주소에 고정된 data.o의 RO-DATA 테이블 배치

예제 5-3 섹션 배치

LR1 0x0 0x10000{ ER1 0x0 0x2000 ; Root Region, containing init code { ; place init code at exactly 0x0 init.o (Init, +FIRST) * (+RO) ; rest of code and read-only data } RAM 0x400000 ; RW & ZI data to be placed at 0x400000 { * (+RW +ZI) } DATABLOCK 0x1FF00 FIXED 0xFF ; execution region fixed at 0x1FF00 { ; maximum space available for table is 0xFF data.o (+RO-DATA) ; place RO data between 0x1FF00 and 0x1FFFF }}

참고

FIXED와 단일 로드 영역의 사용이 적절하지 않은 경우도 있습니다. 고정 위치 지정을 위한 다른 기술은 다음과 같습니다.

• 로더에서 여러 로드 영역을 처리할 수 있는 경우 RO 코드 또는 데이터를 자체 로드 영역에 배치합니다.

• 함수 또는 데이터가 ROM의 고정 주소에 있어야 할 필요가 없으면 FIXED 대신 ABSOLUTE를 사용합니다. 이렇게 하면 로더에서 로드 영역으로부터 RAM의 지정된 주소로 데이터를 복사합니다. ABSOLUTE가 기본 속성입니다.



• 메모리 매핑된 I/O 위치에 데이터 구조를 배치하려면 두 로드 영역을 사용하고 UNINIT를 지정합니다. UNINIT는 메모리 위치가 0으로 초기화되지 않도록 합니다. 자세한 내용은 개발자 설명서에서 3장 임베디드 소프트웨어 개발을 참조하십시오.



__attribute__ ( (section ("name"))) 사용

자체 소스 파일에 코드 또는 데이터 객체를 배치한 다음 객체 파일 섹션을 배치할 경우 표준 코딩 기술을 사용합니다. 그러나 __attribute__ ( (section ("name")))과 스캐터 로딩 설명 파일을 사용하여 명명된 섹션을 배치할 수도 있습니다. adder.c와 같은 모듈을 만들고 예제 5-4에 표시된 대로 명시적으로 섹션을 명명합니다.

예제 5-4 섹션 명명

int variable __attribute__ ( (section ("foo"))) = 10;

명명된 섹션이 배치되는 곳을 지정하려면 스캐터 로딩 설명 파일을 사용합니다. 자세한 내용은 예제 5-5를 참조하십시오. 코드와 데이터 섹션 모두 이름이 동일하면 코드 섹션이 먼저 배치됩니다.

예제 5-5 섹션 배치

FLASH 0x24000000 0x4000000{

... ; rest of code

ADDER 0x08000000 { adder.o (foo) ; select section foo from adder.o }}



__at 섹션을 사용하여 특정 주소에 섹션 배치

섹션이 배치되어야 하는 주소를 인코딩하는 특별한 이름을 섹션에 제공할 수 있습니다. 이름은 다음과 같이 지정할 수 있습니다.

.ARM.__at_address

인수 설명:

address 섹션의 필수 주소로, 16진수나 10진수로 지정할 수 있습니다. .ARM.__at_address 형식의 섹션은 약어 __at으로 참조됩니다.

컴파일러에서 변수를 __at 섹션으로 할당할 수 있습니다. 이렇게 하려면 __attribute__ ( (section (”name”))) 을 사용하여 섹션을 명시적으로 명명하거나, __at 속성을 사용하여 섹션 이름이 자동으로 설정되도록 할 수 있습니다. 자세한 내용은 예제 5-6을 참조하십시오.

참고

__attribute__ ( (at (<address>)))를 사용할 때 address를 나타내는 __AT 섹션 이름 부분은 8자리의 16진수로 표준화됩니다. 섹션 이름은 스캐터 로딩 설명 파일에서 이름을 기준으로 섹션을 일치시키려는 경우에만 중요합니다.

예제 5-6 변수를 __at 섹션에 할당

; place variable1 in a section called .ARM.__at_0x00008000int variable1 __attribute__ ( (at (0x8000))) = 10;

; place variable2 in a section called .ARM.__at_0x8000int variable2 __attribute__ ( (section (".ARM.__at_0x8000"))) = 10;

자세한 내용은 컴파일러 참조 설명서에서 4-44페이지의 __attribute__ ( (at (address))) 및 4-47페이지의 __attribute__ ( (section))을 참조하십시오.



제한

• 겹치는 섹션이 서로 다른 오버레이 영역에 배치되지 않는 한 __at 섹션 주소 범위는 겹치지 않아야 합니다.

• __at 섹션은 위치 독립적 실행 영역에서 허용되지 않습니다.

• __at 섹션의 링커 정의 기호인 $$Base, $$Limit 및 $$Length를 참조하면 안 됩니다.

• __at 섹션은 System V 및 BPABI 실행 가능 파일과 BPABI DLL에서 사용하면 안 됩니다.

• __at 섹션에는 정렬의 배수인 주소가 있어야 합니다.

• __at 섹션은 모든 +FIRST 또는 +LAST 순서 지정 제한을 무시합니다.



자동 배치

이 모드는 링커 명령 행 옵션 --autoat을 사용하여 활성화됩니다. 자세한 내용은 링커 참조 설명서에서 2-4페이지의 --[no_]autoat을 참조하십시오.

--autoat 옵션을 사용하여 링크할 때 __at 섹션은 스캐터 로딩 선택기를 통해 배치되지 않습니다. 대신 링커에서 __at 섹션을 호환되는 영역에 배치합니다. 호환되는 영역을 찾을 수 없으면 링커에서 __at 섹션의 로드 및 실행 영역을 만듭니다.

링커 --autoat를 통해 만들어지는 모든 실행 영역에는 UNINIT 스캐터 로딩 속성이 있습니다. ZI __at 섹션을 0으로 초기화하려면 호환되는 영역에 배치해야 합니다. 링커 --autoat을 통해 만들어지는 실행 영역에는 최소 4바이트로 정렬되는 기본 주소가 있습니다. 영역을 잘못 정렬하면 오류 메시지가 생성됩니다.

호환되는 영역에는 다음과 같은 특징이 있습니다.

• __at 주소는 실행 영역 기본 및 한계 안에 있습니다. 여기서 한계는 기본 주소 + 실행 영역의 최대 크기입니다. 최대 크기를 설정하지 않으면 한계는 무한대로 간주됩니다.

• 실행 영역은 다음 조건 중 하나 이상을 충족합니다.

— 표준 스캐터 로딩 규칙에 따라 __at 섹션과 일치하는 선택기가 있습니다.

— 유형 (RO, RW 또는 ZI)이 동일한 하나 이상의 섹션을 __at 섹션으로 사용합니다.

— EMPTY 속성이 없습니다.

참고

링커에서는 RW 유형의 __at 섹션을 RO와 호환된다고 간주합니다.

예제 5-7에서는 .ARM.__at_0x0 유형 RO, .ARM.__at_0x2000 유형 RW, .ARM.__at_0x4000 유형 ZI 및 .ARM.__at_0x8000 유형 ZI 섹션을 보여 줍니다.

예제 5-7 __at 섹션의 자동 배치

LR1 0x0{

ER_RO 0x0 0x2000{

* (+RO) ; .ARM.__at_0x0 lies within the bounds of ER_RO}ER_RW 0x2000 0x2000



{* (+RW) ; .ARM.__at_0x2000 lies within the bounds of ER_RW

}ER_ZI 0x4000 0x2000{

* (+ZI) ; .ARM.__at_0x4000 lies within the bounds of ER_ZI}

}

; the linker creates a load and execution region for the __at section; .ARM.__at_0x8000 because it lies outside all candidate regions.

수동 배치

표준 스캐터 로딩 규칙은 __at 섹션 배치에 사용되는 실행 영역을 결정하는 데 사용됩니다.

예제 5-8에서는 읽기 전용 섹션 .ARM.__at_0x2000과 읽기/쓰기 섹션 .ARM.__at_0x4000의 배치를 보여 줍니다. 로드 및 실행 영역은 수동 모드에서 자동으로 만들어지지 않습니다. __at 섹션을 실행 영역에 배치할 수 없으면 오류가 생성됩니다.

예제 5-8 __at 섹션의 수동 배치

LR1 0x0{

ER_RO 0x0 0x2000{

* (+RO) ; .ARM.__at_0x0 is selected by +RO}ER_RO2 0x2000{

* (.ARM.__at_0x2000) ; .ARM.__at_0x2000 is selected by .ARM.__at_0x2000}ER2 0x4000{

* (+RW +ZI) ; .ARM.__at_0x4000 is selected by +RW}

}



플래시 메모리에 키 배치

일부 플래시 장치의 경우 특정 기능을 활성화하려면 주소에 키가 기록되어야 합니다. __at 섹션에서는 특정 주소에 간단하게 값을 기록할 수 있습니다.

장치에 0x8000에서 0x10000까지의 플래시 메모리가 있고 키가 주소 0x8000에 필요한 경우, __at 섹션을 사용하여 이 작업을 수행하려면 컴파일러가 .ARM.__at_0x8000이라는섹션을 생성할 수 있도록 변수를 선언해야 합니다. 자세한 내용은 5-17페이지의 예제 5-6을 참조하십시오.

예제 5-9에서는 플래시 실행 영역을 수동으로 배치하는 스캐터 로딩 설명 파일을 보여 줍니다.

예제 5-9 플래시 실행 영역의 수동 배치

ER_FLASH 0x8000 0x2000{

* (+RO) ; other code, read-only data, and padding if reqd

* (.ARM.__at_0x8000) ; key}

예제 5-10에서는 플래시 실행 영역을 자동으로 배치하는 스캐터 로딩 설명 파일을 보여 줍니다. 자동 배치를 활성화하려면 링커 명령 행 옵션 --autoat을 사용합니다.

예제 5-10 플래시 실행 영역의 자동 배치

ER_FLASH 0x8000 0x2000{

* (+RO) ; other code and read-only data, the; __at section is automatically selected

}



주변 기기 레지스터 위에 구조체 매핑

주변 기기 레지스터 위에 초기화되지 않은 변수를 배치하려면 ZI __at 섹션을 사용하면 됩니다. 0x10000000에서 레지스터를 사용할 수 있다고 가정하고 .ARM.__at_0x10000000이라는 ZI __at 섹션을 정의합니다. 예를 들면 다음과 같습니다.

int foo __attribute__ ( (section (“.ARM.__at_0x10000000” ), zero_init));

예제 5-11에서는 ZI __at 섹션을 수동으로 배치하는 스캐터 로딩 설명 파일을 보여 줍니다.

예제 5-11 ZI __at 섹션의 수동 배치

ER_PERIPHERAL 0x10000000 UNINIT{

* (.ARM.__at_0x10000000)}

자동 배치를 사용하는 경우 0x10000000 근처에 다른 실행 영역이 없다고 가정하면, 링커에서 0x10000000에 UNINIT 속성을 사용하여 영역을 자동으로 만듭니다.



5.2.3 오버레이를 사용한 섹션 배치

스캐터 로딩 설명 파일에서 OVERLAY 속성을 사용하여 동일한 주소에 여러 실행 영역을 배치할 수 있습니다. 한 번에 하나의 실행 영역만 인스턴스화하려면 오버레이 관리자가 필요합니다. ARM RealView Compilation Tools에서는 오버레이 관리자를 제공하지 않습니다.

예제 5-12에서는 RAM의 정적 섹션과 일련의 오버레이를 정의합니다. 여기서는 이러한 섹션이 한 번에 하나씩만 인스턴스화됩니다.

예제 5-12 루트 영역 지정

EMB_APP 0x8000 {

.

. STATIC_RAM 0x0 ; contains most of the RW and ZI code/data { * (+RW,+ZI) } OVERLAY_A_RAM 0x1000 OVERLAY ; start address of overlay... { module1.o (+RW,+ZI) } OVERLAY_B_RAM 0x1000 OVERLAY { module2.o (+RW,+ZI) }

... ; rest of scatter description...}

OVERLAY로 표시된 영역은 시작 시 C 라이브러리를 통해 초기화되지 않습니다. 오버레이 영역에서 사용하는 메모리 내용은 오버레이 관리자가 관리합니다. 따라서 오버레이 관리자는 코드와 데이터를 복사해야 하며 영역을 인스턴스화할 때 ZI를 초기화해야 합니다. 영역에 초기화된 데이터가 포함되어 있으면 NOCOMPRESS를 사용하여 RW 데이터 압축도 보호해야 합니다.

코드 및 데이터를 복사하는 데 필요한 주소를 가져오는 데 링커 정의 기호를 사용할 수 있습니다. 자세한 내용은 4-3페이지의 링커 정의 기호 액세스를 참조하십시오.



다른 영역과 주소가 다른 단일 영역에 OVERLAY 속성을 사용할 수 있습니다. 따라서 오버레이 영역은 C 라이브러리 시작 코드를 통한 특정 영역 초기화를 방지하는 방법으로 사용할 수 있습니다. 오버레이 영역과 마찬가지로, 이들 영역 역시 코드에서 수동으로 초기화해야 합니다.

오버레이 영역에는 상대적인 베이스가 있을 수 있습니다. +offset 기본 주소가 지정된 오버레이 영역의 동작은 상위 영역과 +offset의 값에 따라 달라집니다. 여기서 +0에는 특수한 의미가 있습니다.

표 5-1에서는 OVERLAY 속성과 함께 사용할 때 발생하는 +offset의 효과를 보여 줍니다. REGION1은 스캐터 로딩 설명 파일에서 REGION2 바로 앞에 표시됩니다.

예제 5-13에서는 오버레이에 상대 오프셋을 사용하는 방법과 실행 영역 주소에 대한 영향을 보여 줍니다.

오버레이가 아닌 영역의 길이를 알 수 없으면 0 기준 오프셋을 사용하여 오버레이의 시작 주소를 지정하는 방법으로 오버레이가 정적 섹션의 끝 부분 바로 뒤에 배치되도록 합니다.

예제 5-13 오버레이의 상대 오프셋 예제

EMB_APP 0x8000{

CODE 0x8000{

* (+RO)}

# REGION1 Base = CODE limitREGION1 +0 OVERLAY{

module1.o (*)

표 5-1 오버레이에 상대 오프셋 사용

REGION1이 OVERLAY로 설정되

는지 여부

+OFFSET REGION2 기본 주소

아니요 <offset> REGION1 Limit + <offset>

예 +0 REGION1 Base Address

예 <non-0 offset> REGION1 Limit + <non-0 offset>



}

# REGION2 Base = REGION1 BaseREGION2 +0 OVERLAY{

module2.o (*)}

# REGION3 Base = REGION2 Base = REGION1 BaseREGION3 +0 OVERLAY{

module3.o (*)}

# REGION4 Base = REGION3 Limit + 4Region4 +4 OVERLAY{

module4.o (*)}

}



5.2.4 루트 영역에 섹션 할당

__main.o, __scatter*.o, __dc*.o 및 *Region$$Table과 같은 여러 ARM 라이브러리 섹션은 루트 영역에 배치해야 합니다. 이러한 섹션의 목록은 릴리스 간에 변경될 수 있습니다. 링커에서는 InRoot$$Sections를 사용하여 이러한 섹션을 모두 향후에도 사용할 수 있도록 자동으로 배치할 수 있습니다.

스캐터 로딩 설명 파일을 사용하여 명명된 섹션과 동일한 방식으로 루트 섹션을 지정할 수 있습니다. 예제 5-14에서는 섹션 선택기 InRoot$$Sections를 사용하여 루트 영역이어야 하는 모든 섹션을 배치합니다.

예제 5-14 루트 영역 지정

ROM_LOAD 0x0000 0x4000{ ROM_EXEC 0x0000 0x4000 ; root region at 0x0 { vectors.o (Vect, +FIRST) ; Vector table * (InRoot$$Sections) ; All library sections that must be in a ; root region, for example, __main.o, ; __scatter*.o, __dc*.o, and * Region$$Table } RAM 0x10000 0x8000 { * (+RO, +RW, +ZI) ; all other sections }}

5.2.5 빈 영역 예약

실행 영역 스캐터 로딩 설명에서 EMPTY 속성을 사용하여 스택의 빈 메모리 블록을 예약할 수 있습니다.

메모리 블록은 로드 영역의 일부를 이루지는 않지만 실행 시간에 사용을 위해 할당됩니다. 메모리 블록은 더미 ZI 영역으로 생성되기 때문에 링커에서 다음 기호를 사용하여 액세스합니다.

• Image$$region_name$$ZI$$Base

• Image$$region_name$$ZI$$Limit

• Image$$region_name$$ZI$$Length



길이가 음수 값으로 제공되면 주소는 영역의 마지막 주소로 지정됩니다. 이것은 절대 주소여야 하며 상대 주소이면 안 됩니다. 예를 들어, 예제 5-15에 표시된 실행 영역 정의 STACK 0x800000 EMPTY –0x10000은 0x7F0000 주소에서 시작하고 0x800000 주소에서 끝나는 STACK이라는 영역을 정의합니다.

참고

EMPTY 실행 영역에 대해 만들어진 더미 ZI 영역은 런타임에 0으로 초기화되지 않습니다.

주소가 상대적 (+n) 형식이고 길이가 음수이면 링커에서 오류를 생성합니다.

예제 5-15 스택에 대한 영역 예약

LR_1 0x80000 ; load region starts at 0x80000 { STACK 0x800000 EMPTY –0x10000 ; region ends at 0x800000 because of the ; negative length. The start of the region ; is calculated using the length. { ; Empty region used to place stack } HEAP +0 EMPTY 0x10000 ; region starts at the end of previous ; region. End of region calculated using ; positive length { ; Empty region used to place heap }

... ; rest of scatter description...}

5-28페이지의 그림 5-6은 이 예제의 다이어그램 표현입니다.



그림 5-6 스택에 대한 영역 예약

이 예제에서 링커는 다음 기호를 생성합니다.

Image$$STACK$$ZI$$Base = 0x7f0000Image$$STACK$$ZI$$Limit = 0x800000Image$$STACK$$ZI$$Length = 0x10000Image$$HEAP$$ZI$$Base = 0x800000Image$$HEAP$$ZI$$Limit = 0x810000Image$$HEAP$$ZI$$Length = 0x10000

참고

EMPTY 속성은 실행 영역에만 적용됩니다. 로드 영역 정의에 EMPTY가 사용된 경우 링커에서 경고를 생성하고 해당 속성을 무시합니다.

링커에서는 EMPTY 영역에 대해 사용된 주소 공간이 다른 실행 영역과 일치하지 않는지 검사합니다.

Heap

Stack

Limit

Base Limit

Base

0x810000

0x800000

0x7F0000



5.2.6 ARM 라이브러리 배치

스캐터 로딩 설명 파일에 ARM 표준 C 및 C++ 라이브러리의 코드를 배치할 수 있습니다. 링커에서 스캐터 로딩 파일의 라이브러리 명명을 확인할 수 있도록 *armlib 또는 *armlib*를 사용합니다. 예를 들면 다음과 같습니다.

ER 0x2000{

*armlib/c_* (+RO) ; all ARM-supplied C libraries... ; rest of scatter description...

}

예제 5-16에서는 라이브러리 코드 배치 방법을 보여 줍니다.

참고

예제 5-16에서는 경로 이름에 정방향 슬래시를 사용하여 Windows 및 Unix 플랫폼에서 경로 이름이 인식되도록 합니다.

예제 5-16 ARM 라이브러리 코드 배치

ROM1 0{

* (InRoot$$Sections)* (+RO)ROM2 0x1000{

*armlib/c_* (+RO) ; all ARM-supplied C library functions}

}ROM3 0x2000{

*armlib/h_* (+RO) ; just the ARM-supplied __ARM_*; redistributable library functions

}RAM1 0x3000{

*armlib* (+RO) ; all other ARM-supplied library code; e.g. floating-point libraries

}RAM2 0x4000{

* (+RW, +ZI)}



5.2.7 페이지 경계에 영역 만들기

ALIGN 지시어는 각 실행 영역이 페이지 경계에서 시작되는 타겟으로 직접 로드될 수 있는 ELF 파일을 생성합니다.

예제 5-17에서는 페이지 크기를 65536이라고 가정하고 각 영역이 새 페이지에서 시작되는 ELF 파일을 생성합니다.

예제 5-17 페이지 경계에 영역 만들기

LR1 +4 ALIGN 65536 ; load region at 65536{

ER1 +0 ALIGN 65536 ; first region at first page boundary{

* (+RO) ; all RO sections are placed consecutively here}ER2 +0 ALIGN 65536 ; second region at next available page boundary{

* (+RW) ; all RW sections are placed consecutively here}ER3 +0 ALIGN 65536 ; third region at next available page boundary{

* (+ZI) ; all ZI sections are placed consecutively here}... ; rest of scatter description...

}

5.2.8 사전 처리 지시어 사용

스캐터 로딩 설명 파일의 첫 행을 사용하여 링커에서 파일을 처리하기 위해 호출하는 사전 처리기를 지정합니다. 이 명령은 다음과 같은 형식입니다.

#! <preprocessor> [pre_processor_flags]

가장 일반적인 명령은 #! armcc -E입니다.

링커에서는 제한된 연산자 집합, 즉 +, -, *, /, AND, OR 및 괄호를 사용하여 단순 식 평가를 수행할 수 있습니다. OR 및 AND의 구현은 C 연산자 우선 순위 규칙을 따릅니다.

스캐터 로딩 설명 파일의 맨 위에 사전 처리 지시어를 추가할 수 있습니다. 예를 들면 다음과 같습니다.



#define ADDRESS 0x20000000#include "include_file_1.h"

링커에서는 이러한 지시어가 명령으로 처리되고 무시되는 사전 처리된 스캐터 로딩 설명 파일을 구문 분석합니다

다음과 같은 간단한 예제를 생각해 볼 수 있습니다.

#define AN_ADDRESS (BASE_ADDRESS+ (ALIAS_NUMBER*ALIAS_SIZE))

다음 지시어를 사용합니다.

#define BASE_ADDRESS 0x8000#define ALIAS_NUMBER 0x2#define ALIAS_SIZE 0x400

스캐터 로딩 설명 파일에 다음이 포함될 경우

LOAD_FLASH AN_ADDRESS ; start address

사전 처리 후 이것은 다음으로 평가됩니다.

LOAD_FLASH ( 0x8000 + ( 0x2 * 0x400 )) ; start address

평가 후에는 링커에서 스캐터 로딩 파일을 구문 분석하여 로드 영역을 생성합니다.

LOAD_FLASH 0x8808 ; start address

자세한 내용은 링커 참조 설명서에서 2-47페이지의 --predefine=”string”을 참조하십시오.



5.3 단순 이미지에 대한 해당 스캐터 로딩 설명

명령 행 옵션 --reloc, --ro-base, --rw-base, --ropi, --rwpi 및 --split는 3-26페이지의 명령 행 옵션을 사용하여 단순 이미지 만들기에서 설명하는 단순 이미지 유형을 만듭니다. --scatter 명령 행 옵션과 해당하는 스캐터 로딩 설명 중 하나를 포함하는 파일을 사용하여 동일한 이미지 유형을 만들 수 있습니다.

5.3.1 유형 1, 로드 영역 하나와 연속되는 실행 영역

이 유형의 이미지는 로드 뷰에 있는 단일 로드 영역과 실행 뷰에 있는 세 실행 영역으로 이루어져 있습니다. 실행 영역은 메모리 맵에 연속적으로 배치됩니다.

--ro-base address는 RO 출력 섹션이 포함된 영역의 로드 및 실행 주소를 지정합니다. 예제 5-18에서는 --ro-base 0x040000의 사용에 해당하는 스캐터 로딩 설명을 보여 줍니다.

예제 5-18 로드 영역 하나와 연속되는 실행 영역

LR_1 0x040000 ; Define the load region name as LR_1, the region starts at 0x040000.{ ER_RO +0 ; First execution region is called ER_RO, region starts at end of previous region. ; However, since there is no previous region, the address is 0x040000. { * (+RO) ; All RO sections go into this region, they are placed consecutively. } ER_RW +0 ; Second execution region is called ER_RW, the region starts at the end of the ; previous region. The address is 0x040000 + size of ER_RO region. { * (+RW) ; All RW sections go into this region, they are placed consecutively. } ER_ZI +0 ; Last execution region is called ER_ZI, the region starts at the end of the ; previous region at 0x040000 + the size of the ER_RO regions + the size of ; the ER_RW regions. { * (+ZI) ; All ZI sections are placed consecutively here. }}

예제 5-18에 표시된 설명은 로드 주소가 0x040000인 LR_1이라는 로드 영역이 하나 포함된 이미지를 만듭니다.



이미지에는 각각 RO, RW 및 ZI 출력 섹션을 포함하는 ER_RO, ER_RW 및 ER_ZI라는 세 실행 영역이 있습니다. RO와 RW는 루트 영역입니다. ZI는 런타임에 동적으로 만들어집니다. ER_RO의 실행 주소는 0x040000입니다. 세 실행 영역은 모두 실행 영역 설명에 대한 기준 지정자의 +offset 형식을 사용하여 메모리 맵에 연속적으로 배치됩니다. 따라서 실행 영역이 선행 실행 영역의 끝 부분 바로 뒤에 배치될 수 있습니다.

--reloc 옵션은 재배치 가능한 이미지를 만드는 데 사용됩니다. 자체적으로 사용될 경우 --reloc는 이미지를 단순 유형 1과 유사하게 만들지만 단일 로드 영역에는 RELOC 속성이 있습니다.

ropi 예제 변형

이 변형에서 실행 영역은 메모리 맵에 연속적으로 배치됩니다. 그러나 --ropi는 RO 출력 섹션을 포함하는 로드 및 실행 영역을 위치 독립적으로 표시합니다.

예제 5-19에서는 --ro-base 0x010000 --ropi의 사용에 해당하는 스캐터 로딩 설명을 보여 줍니다.

예제 5-19 위치 독립적 코드

LR_1 0x010000 PI ; The first load region is at 0x010000. { ER_RO +0 ; The PI attribute is inherited from parent. ; The default execution address is 0x010000, but the code can be moved. { * (+RO) ; All the RO sections go here. } ER_RW +0 ABSOLUTE ; PI attribute is overridden by ABSOLUTE. { * (+RW) ; The RW sections are placed next. They cannot be moved. } ER_ZI +0 ; ER_ZI region placed after ER_RW region. { * (+ZI) ; All the ZI sections are placed consecutively here. }}



5-33페이지의 예제 5-19에 나와 있는 RO 실행 영역 ER_RO는 로드 영역 LR_1에서 PI 속성을 상속합니다. 다음 실행 영역인 ER_RW는 ABSOLUTE로 표시되고 기준 지정자의 +offset 형식을 사용합니다. 이렇게 하면 ER_RW가 ER_RO에서 PI 속성을 상속하지 못합니다. 또한 ER_ZI 영역에는 +0의 오프셋이 있기 때문에 ER_RW 영역에서 ABSOLUTE 속성을 상속합니다.

5.3.2 유형 2, 로드 영역 하나와 연속되지 않는 실행 영역

이 유형의 이미지는 로드 뷰에 있는 단일 로드 영역과 실행 뷰에 있는 세 실행 영역으로 이루어져 있습니다. 이것은 RW 실행 영역이 RO 실행 영역과 연속되지 않는다는 점을 제외하고는 유형 1의 이미지와 유사합니다.

--ro-base=address1은 RO 출력 섹션이 포함된 영역의 로드 및 실행 주소를 지정합니다. --rw-base=address2는 RW 실행 영역에 대한 실행 주소를 지정합니다.

예제 5-20에서는 --ro-base=0x010000 --rw-base=0x040000의 사용에 해당하는 스캐터 로딩 설명을 보여 줍니다.

예제 5-20 로드 영역 하나와 여러 실행 영역

LR_1 0x010000 ; Defines the load region name as LR_1{ ER_RO +0 ; The first execution region is called ER_RO and starts at end of previous region. ; Since there is no previous region, the address is 0x010000. { * (+RO) ; All RO sections are placed consecutively into this region. } ER_RW 0x040000 ; Second execution region is called ER_RW and starts at 0x040000. { * (+RW) ; All RW sections are placed consecutively into this region. } ER_ZI +0 ; The last execution region is called ER_ZI. ; The address is 0x040000 + size of ER_RW region. { * (+ZI) ; All ZI sections are placed consecutively here. }}

이 설명은 로드 주소가 0x010000인 LR_1이라는 로드 영역이 하나 있는 이미지를 만듭니다.



이미지에는 각각 RO, RW 및 ZI 출력 섹션을 포함하는 ER_RO, ER_RW 및 ER_ZI라는 세 실행 영역이 있습니다. RO 영역은 루트 영역입니다. ER_RO의 실행 주소는 0x010000입니다.

ER_RW 실행 영역은 ER_RO와 연속되지 않으며 실행 주소는 0x040000입니다.

ER_ZI 실행 영역은 선행 실행 영역 ER_RW의 끝 부분 바로 뒤에 배치됩니다.

rwpi 예제 변형

이것은 RO 실행 영역과 별도로 RW 실행 영역이 있는 --rw-base를 사용하는 유형 2 이미지와 유사합니다. 그러나 --rwpi는 RW 출력 섹션을 포함하는 실행 영역을 위치 독립적으로 표시합니다.

예제 5-21에서는 --ro-base=0x010000 --rw-base=0x018000 --rwpi의 사용에 해당하는 스캐터 로딩 설명을 보여 줍니다.

예제 5-21 위치 독립적 데이터

LR_1 0x010000 ; The first load region is at 0x010000.{ ER_RO +0 ; Default ABSOLUTE attribute is inherited from parent. The execution address ; is 0x010000. The code and ro data cannot be moved. { * (+RO) ; All the RO sections go here. } ER_RW 0x018000 PI ; PI attribute overrides ABSOLUTE { * (+RW) ; The RW sections are placed at 0x018000 and they can be moved. } ER_ZI +0 ; ER_ZI region placed after ER_RW region. { * (+ZI) ; All the ZI sections are placed consecutively here. }}

RO 실행 영역 ER_RO는 로드 영역 LR_1에서 ABSOLUTE 속성을 상속합니다. 다음 실행 영역 ER_RW는 PI로 표시됩니다. 또한 ER_ZI 영역에는 +0의 오프셋이 있기 때문에 ER_RW 영역에서 PI 속성을 상속합니다.

유형 2 및 유형 3 이미지를 가진 --ropi 및 --rwpi의 다른 조합의 사용에 해당하도록 유사한 스캐터 로딩 설명을 작성할 수도 있습니다.



5.3.3 유형 3, 로드 영역 두 개와 연속되지 않는 실행 영역

유형 3 이미지는 로드 뷰에 있는 두 로드 영역과 실행 뷰에 있는 세 실행 영역으로 이루어져 있습니다. 이 이미지는 유형 2의 단일 로드 영역이 이제는 두 로드 영역으로 분할된다는 점을 제외하고 유형 2 이미지와 유사합니다.

다음 링커 옵션을 사용하여 로드 영역을 재배치하고 분할합니다.

--reloc --reloc --split 조합은 이미지를 단순 유형 3과 유사하게 만들지만 두 로드 영역이 이제는 RELOC 속성을 갖습니다.

--ro-base=address1

RO 출력 섹션을 포함하는 영역의 로드 및 실행 주소를 지정합니다.

--rw-base=address2

RW 출력 섹션을 포함하는 영역의 로드 및 실행 주소를 지정합니다.

--split RO 및 RW 출력 섹션을 포함하는 기본 단일 로드 영역을 두 로드 영역으로 분할합니다. 한 로드 영역은 RO 출력 섹션을 포함하고 다른 하나는 RW 출력 섹션을 포함합니다.

예제 5-22에서는 --ro-base=0x010000 --rw-base=0x040000 --split의 사용에 해당하는 스캐터 로딩 설명을 보여 줍니다.

이 예제에서는 다음과 같습니다.

• 이 설명은 로드 주소가 0x010000과 0x040000인 LR_1과 LR_2라는 두 로드 영역이 포함된 이미지를 만듭니다.

• 이미지에는 각각 RO, RW 및 ZI 출력 섹션을 포함하는 ER_RO, ER_RW 및 ER_ZI라는 세 실행 영역이 있습니다. ER_RO의 실행 주소는 0x010000입니다.

• ER_RW 실행 영역은 ER_RO와 연속되지 않으며 실행 주소는 0x040000입니다.

• ER_ZI 실행 영역은 선행 실행 영역 ER_RW의 끝 부분 바로 뒤에 배치됩니다.

예제 5-22 다중 로드 영역

LR_1 0x010000 ; The first load region is at 0x010000.{ ER_RO +0 ; The address is 0x010000. {



* (+RO) }}LR_2 0x040000 ; The second load region is at 0x040000.{ ER_RW +0 ; The address is 0x040000. { * (+RW) ; All RW sections are placed consecutively into this region. } ER_ZI +0 ; The address is 0x040000 + size of ER_RW region. { * (+ZI) ; All ZI sections are placed consecutively into this region. }}



재배치 가능 로드 영역 예제 변형

또한 이 유형 3 이미지는 로드 뷰에 있는 두 로드 영역과 실행 뷰에 있는 세 실행 영역으로 이루어져 있습니다. 그러나 --reloc는 두 로드 영역이 이제 RELOC 속성을 가지도록 지정하는 데 사용됩니다.

예제 5-23에서는 --ro-base 0x010000 --rw-base 0x040000 --reloc --split의 사용에 해당하는 스캐터 로딩 설명을 보여 줍니다.

예제 5-23 재배치 가능 로드 영역

LR_1 0x010000 RELOC{ ER_RO + 0 { * (+RO) }}

LR2 0x040000 RELOC{ ER_RW + 0 { * (+RW) }

ER_ZI +0 { * (+ZI) }}


Documents

RealView Compilation Tools - ARM architectureinfocenter.arm.com/help/topic/com.arm.doc.dui0206ik/DUI... · † RealView Compilation Tools 컴파일러 참조 설명서 (ARM DUI 0348)