GCC에서 IAR로 개발환경을 마이그레이션하는 방법

[IAR시스템즈=오재준 매니저] C/C++ 언어가 표준으로 정해져 있다 하더라도 개발환경을 변경하기 위해서는 절차와 그에 따른 문제점을 정확히 파악하는 것이 필요하다. 개발환경의 마이그레이션 절차는 컴파일러(컴퓨터 프로그래밍 소스를 기계어로 바꾸는 프로그램)의 오류에 대한 대책을 실시하는 정적 환경 전환과 프로그램 동작을 보장하는 동적 환경 전환으로 나눌 수 있다. 본 기고에서는 정적 환경 전환을 효율적으로 실시하는 단계와 동적 환경 전환에 따른 문제를 줄이는 방법에 대해 설명한다.

개발환경 마이그레이션(migration)을 시작하기 전에

개발환경을 마이그레이션하기 위해서는 두 가지 과제를 극복해야 한다. 하나는 정적 환경 전환으로 C/C++ 및 어셈블러(컴퓨터 언어 번역) 소스 코드, 링커 설정이 적절하게 수행되고 빌드가 성공적으로 이뤄지는 것을 말한다. 다른 하나는 ▲동적 환경 전환으로 컴파일러마다 다른 최적화 기법 ▲기계어(컴퓨터가 알아듣는 말) 전환 과정에 따른 성능차이로 프로그램의 수행 시간이 변화하는 것을 말한다. 더 정확히는 함수를 처리하는 시간이 변화하기 때문에 수행 타이밍에 차이가 나고, 전체적인 동작이 달라질 수 있다.

개발 환경의 마이그레이션은 보통 다음과 같은 절차를 따른다. 각 단계의 구체적인 실시 내용을 결정하고 충분한 테스트를 수행하길 권고한다.

개발 환경 마이그레이션의 시작

1. 프로젝트 생성

우선 ‘프로젝트 크리에이트 뉴 프로젝트(Project Create New Project)’ 메뉴에서 ‘엠티 프로젝트(Empty Project)’를 생성한다. 이클립스(Eclipse∙오픈소스 기반의 자바 개발 플랫폼) 기반의 개발 환경은 프로젝트 폴더 아래 빌드에 필요한 여러 파일이 자동 등록된다. IAR 임베디드 워크벤치 포어 ARM(EWARM∙Embedded Workbench for ARM)에서는 아래 그림과 같이 그룹 기능을 이용해 같은 구조의 프로젝트를 만들 수 있다. GCC 프로젝트와 동일한 구조가 형성되면, Add → Add Files를 통해 각 소스파일(.c)과 헤더파일(.h)을 폴더의 구조에 맞게 삽입한다.

소스와 헤더파일이 구조에 맞게 삽입됐으면, 몇 가지 빌드(build) 설정을 맞춰줘야 할 필요가 있다. 우선 프리프로세서(preprocessor)의 심볼을 정의해 준다. 아래 그림과 같이 정의된 심볼을 그대로 복사해 EWARM 심볼창에 붙여 넣는다.

다음으로 헤더 파일의 경로를 설정한다.

2. startup 파일 처리 및 어셈블러 변환

컴파일(F7)을 수행하면 다음과 같은 에러가 발생한다.

이 때 다음과 같이 가장 많은 에러가 발생하는 ‘startup_stm32f401retx.s’ 파일을 컴파일 목록에서 제거한다. GNU 어셈블러 지시어로 작성된 startup 파일은 IAR 어셈블러에서 호환되지 않으며, IAR용으로 작성된 startup 파일을 각 SiP 업체(각 디바이스 제조사)를 통해 제공받아 사용하는 것을 권고한다. 필요에 의해 GCC에서 startup 파일을 수정했고 이것을 IAR에 적용해야 할 필요가 있다면, IAR용 startup 파일을 기반으로 수정하면 된다.

또한 main() 함수를 호출할 때까지 아래 그림과 같이 처리 방식이 상이하기 때문에 주의를 바란다.

3. 컴파일 오류 수정

그러면 이제 위에서 발생한 11개의 오류를 제거해야 한다. 먼저 아래 그림과 같이 [sys/stat.h] 파일에서 오류가 발생(cannot open source file “sys/stat.h”)하는 것을 알 수 있다. 이 헤더는 syscalls.c 파일에서 참조하는데, 이 파일은 C언어의 표준 함수를 사용하지 않았고, IAR에서는 지원하지 않으므로 syscalls.c 파일을 컴파일 목록에서 제거한다.

[그림 9] sys/stat.h로 인한 오류 발생 및 컴파일 목록에서 제거.

다음 오류는 sysmem.c 파일에서 발생하고 있으며, 오류가 발생하는 함수인 _sbrk는 사이즈가 정해져있는 힙(heap) 메모리를 동적으로 확장하고자 할 때 사용된다. 이 부분은 동적으로 확장하기보다 힙 메모리 사이즈를 설계할 때 충분한 사이즈로 정의해서 사용하는 것을 권고한다. sysmem.c 파일 또한 컴파일 목록에서 제거한다.

[그림 10] sysmem.c로 인한 오류 발생 및 컴파일 목록에서 제거.

4. 링커 커멘드 파일 수정

여기까지 진행하면 오류없이 컴파일이 완료된 것을 볼 수 있다. 다음은 링커 커멘드 파일(Linker Command File) 설정에 대해서 알아보겠다. 아래 그림에서 보이듯이 GNU 링커 스크립트(Linker Script)와 IAR 링커 커멘드 파일은 그 구조 및 문법이 확연히 다르다. IAR로 개발환경을 마이그레이션 할 때는 IAR 링커 커멘드 파일을 기반으로 GNU에서 작성된 내용을 이식해 오는 것을 권고한다. IAR 링커 커멘드 파일 활용법에 대해서 자세히 다루기에는 이 문서 하나로는 부족하기 때문에 IAR EWARM → Help → C/C++ Development Guide를 참조하거나 회사에 문의하면 설명하겠다.

다음 그림의 옵션을 사용하면 벡터(Vector)테이블, 메모리 구역, 스택/힙(Stack/Heap) 크기는 간단히 변경이 가능하니 참조 바란다. 다음 옵션에서 위치나 크기를 변경하면 자동적으로 .icf 파일에 변경사항이 반영된다.

[그림 12] GUI를 통한 Vector Table, Memory Regions, Stack/Heap Sizes 변경법.

마이그레이션 후 주의사항

1. 최적화 세팅

최초 마이그레이션 단계에서는 컴파일 최적화 세팅을 “None”으로 설정하는 것을 권고한다. 이유는 최적화 성능은 컴파일러마다 다르기 때문에 프로그래밍 구동 중 어떠한 문제가 발생했을 때, 최적화로 인한 요소를 제거하기 위해서이다. 정적/동적 환경 변환이 완료된 후 프로그래밍이 안정화된 후 최적화 설정을 변경하는 것이 필요하다.

2. 포인터

포인터 검증이 엄격하므로 명시적 형 변환이 필요하다.

3. const
const 형태의 포인터를 사용할 때 주의해야 한다.

4. 배열
배열의 요소의 정의가 없는 경우 ‘NULL’이 필요하다.

5. GCC 속성(attributes) 지원
IAR EWARM에서는 Project → Options → C/C++ Compiler → Language 1 → Language Conformance 설정에서 “Standard with IAR extensions”를 선택하면 GCC 스타일의 일부 속성을 지원한다. 이것은 __attribute__ ((attribute-list))의 문법을 사용함으로써 가능하다. attribute-list는 volatile, weak, noinline, packed, aligned와 같이 빈번하게 사용되는 것을 포함해 총 19개의 속성을 지원한다. 기존 GCC 개발환경에서 이러한 키워드를 사용하고 있다면, IAR로 마이그레이션하는데 보다 쉽게 적용될 수 있게 해준다. 이 키워드들에 대한 자세한 내용은 GCC 문서를 참조 바란다.

맺음말

지금까지 개발환경을 마이그레이션하기 위해 고려해야 할 사전작업 및 정적 환경 전환 방법에 대해서 알아봤다. 이 하나의 문서로 마이그레이션 도중 발생할 수 있는 모든 문제점을 기술할 수는 없지만, 거시적인 관점에서, 때로는 세부적으로 마이그레이션 방법에 대해 설명했다. 마이그레이션 절차에는 지금까지 살펴본 정적 환경 전환뿐만 아니라, 컴파일러의 성능 및 최적화 기법에 따라 달라질 수 있는 함수 수행 시간 및 기능 동작성에 대해서 충분히 이해를 하고 수행하기를 권고한다.

회원가입 후 이용바랍니다.