Cross Compiler를 Prebuilt toolchains에서 배포하는 곳은 많으며, 대체적으로 BSP에서 제공해주는 것에 맞추어서 설치하면된다.
오래전 같으면 Cross Compiler를 직접빌드해서 사용했지만, 지금은 설치만 하면되니까,
그래도 직접 빌드는 안하지만 개념은 까먹지 않아야 할꺼 같아 정리한다.
GCC (GNU Compiler)
https://www.gnu.org/software/gcc/
일단 GCC의 동작 및 기본구성원리를 들을 알아보자.
1.1 GCC의 구성 및 동작
GCC의 C Compiler만을 의미하는 것이 아니며, C, C++, Objective-C, Fortran, Ada, and Go 다양한 언어를 제공해주는 GNU의 Compiler이다
- GCC의 구성도
- Front End (각 언어에 (C/C++/Fortran) 맞게 Parsing 및 구조화 )
- Middle End ( Front End에서 생긴 것을 최적화)
- Back End ( 각 Architecture에 맞게 PowerPC/ARM/X86 Machine Code 생성)
각 프로그래밍 언어는 Frontend에서 담당을 하므로, GCC에 추가한다면 Front End이다.
그래서 GCC C/C++만을 위한 것이 아니며, 다양한 언어를 지원한다.
http://www.aosabook.org/en/llvm.html
https://www.gnu.org/software/gcc/frontends.html
- LLVM
http://releases.llvm.org/
- GCC Manual
GCC-4.8.5 전체 Manual
https://gcc.gnu.org/onlinedocs/gcc-4.8.5/gcc/
- Preprocessor 사용되는 Command 및 Manual 보는법
많이 사용되는 곳이 Kernel 과 초기화 코드 및 관련부분이며, 일반 Application에서는 사실 거의 사용하지 않을 것이다.
아래와 같이 상위 Manual을 보면될 것이며, 자료가 방대하다보니 목록을 반드시 확인하고 보자.
#pragma
https://gcc.gnu.org/onlinedocs/gcc-4.8.5/gcc/Pragmas.html#Pragmas
https://gcc.gnu.org/onlinedocs/gcc-4.8.5/gcc/Function-Specific-Option-Pragmas.html#Function-Specific-Option-Pragmas
__attribute__ (함수/변수 시)
https://gcc.gnu.org/onlinedocs/gcc-4.8.5/gcc/Function-Attributes.html#Function-Attributes
https://gcc.gnu.org/onlinedocs/gcc-4.8.5/gcc/Variable-Attributes.html#Variable-Attributes
1.2 How To Build Cross Compiler
아래의 사이트에서 크로스 컴파일러가 어떻게 만들어지는 간단하게 알아보자.
https://rtime.felk.cvut.cz/hw/index.php/How_to_build_GNU_cross-compilers
https://preshing.com/20141119/how-to-build-a-gcc-cross-compiler/
https://wiki.osdev.org/GCC_Cross-Compiler
- C만 지원하는 일반적 GCC 필요구성
- binutils (linker 및 assember 포함)
- gcc
- glibc/uclibc/musl/newlib (C library 의 종류)
- linux header ( kernel 정보)
1.3 일반적인 GCC의 필요사항
일반적인 GCC라면, C만 지원이 되는 glibc를 말할 것이며, 구성요소는 다음과 같다.
- Linux Kernel header
- GNU Binutils
https://www.gnu.org/software/binutils/
- GNU GCC
- GNU C Library (다른 Library 생략)
https://en.wikipedia.org/wiki/Newlib
1.4. ABI 관련사항
ABI(Application Binary Interface)는 CPU Architecture에서 어떻게 Register를 사용 및 할당할 것이지,
그리고CPU 입장에서 함수에 어떻게 변수를 전달할 것인지, 모든 규칙을 정의해놓은 Interface 규격이다.
예를들면, ARM의 PCS(Procedure Call Standard)를 보면, 함수를 호출시 Register로 어떻게 변수를 전달 할 것인지를 설명해준다.
이는 ARM만이 아니라 PowerPC/MIPS 다 존재하며 CPU의 Register 구조가 다르기 때문에 개별 ABI 가 필요하다. (이전 PowerPC는 GP Register 32개)
좀더 들어가면, Data Type , File Format, Stack 의 구조사용법 및 ELF의 동적링크 부분도 다 이 문서에 포함이 되어있다.
- ABI의 관련사항
- ARM ABI 관련문서
- MIPS ABI 관련문서
1.4.1 EABI와 OABI
EABI(embedded-application binary interface) 는 embedded system에서 최적화하기 위해서 만들어졌다고 한다.
더 자세히 말하면 ARM의 EABI는 ARM의 ABI의 일부사양일 뿐이라고 한다.
그리고, 기존의 ABI는 OABI(Old-ABI)로 불린다고 한다.
그러므로, 만약 설정할 일이 있다면, 설정추가를 하는것이지 설정을 변경할일은 아니다.
- ARM EABI의 탄생배경
그리고 이를 FPU관련 부분을 효율적으로 사용하기위해서 EABI가 나왔다고 한다.
Debian에서는 ToolChain도 ABI에 따라 3가지 Version으로 구분되어 나온다고 한다.
| Architecture | ABI | FPU | Releases |
|---|---|---|---|
| ARM | OABI | Not required, but very slow without | All debian releases upto and including Lenny were OABI. It has since been deprecated. |
| ARMEL | EABI | Does not make use of FPU | Lenny and beyond |
| ARMHF | EABI | FPU required. Specifically benefits from NEON architecture and VFP. | Wheezy and beyond |
참고로, 상위 Lenny, Wheezy는 Version의 이름이다.
https://wiki.embeddedarm.com/wiki/EABI_vs_OABI
- ARM EABI 관련내용
- EABI 관련장점 정리사항
- Floating point performance, with or without an FPU is fast and mixing soft and hardfloat code is possible
- Structure packing is not as painful as it used to be
- More compatibility with various tools (in future - currently linux-elf is well supported)
- A more efficient syscall convention
- EABI의 관련장점 설명
- 1번은 상위에서 설명했듯이 EABI의 탄생배경이며 근본적인 문제해결인 것 같다.
- 2번의 경우 구조체의 packed의 문제가 뭔지 모르겠다. e.g. __attribute__((packed, aligned(4)))
- 3번의 경우 binutil과 gcc에서 호환성을 의미하는 것 같다.
- 4번의 syscall convention 변화 (syscall 의 규칙)
- ARM EABI와 OABI 비교사항
- Android ABI(EABI) 관련내용
- CONFIG_AEABI
- CONFIG_OABI_COMPAT
https://wiki.kldp.org/wiki.php/AndroidPortingOnRealTarget/ko
2. 많이 이용되어지는 Prebuilt Toolchain for Linux
- CodeSourcery (SoC의 BSP/SDK와 함께 배포)
- Free Electrons (최근 bootlin 변경됨)
- Linaro (ARM)
SoC와 함께 많이 제공해주던 곳이 CodeSourcery 이며, 이전에 OdroidX2를 가지고 놀때, Linaro도 같이 이용을 했지만 Linaro Version을 좀더 자세히 알고자 한다.
참고자료 및 경험
https://elinux.org/Toolchains
https://gcc.gnu.org/install/binaries.html
2.1 Free Electrons (Bootlin)
리눅스 관련된 최신문서가 잘 정리된 사이트이며, Tool chain도 Architecture 및 Library에 별로 다양하게 제공을 할 뿐더러
본인이 원하는 GCC의 내부구성 정보도 잘 보여준다.
uclibc의 경우는 오래전에 uclinux (ARM7, PowerPC) 할때 빼고는 거의 사용한 기억이없는것 같다.
uclibc를 가지고 opensource를 porting할 때마다 제한적이어서 고생한 기억만 나서 그런지,
참고로 uclinux의 경우 오랜전에 MMU가 없이도 가능 부팅이 가능(ARM7)하며, Power PC인 경우는 linux를 최적화하기위해서 사용했었다.
https://toolchains.free-electrons.comhttps://elinux.org/Toolchains
https://gcc.gnu.org/install/binaries.html
2.1 Free Electrons (Bootlin)
리눅스 관련된 최신문서가 잘 정리된 사이트이며, Tool chain도 Architecture 및 Library에 별로 다양하게 제공을 할 뿐더러
본인이 원하는 GCC의 내부구성 정보도 잘 보여준다.
uclibc의 경우는 오래전에 uclinux (ARM7, PowerPC) 할때 빼고는 거의 사용한 기억이없는것 같다.
uclibc를 가지고 opensource를 porting할 때마다 제한적이어서 고생한 기억만 나서 그런지,
참고로 uclinux의 경우 오랜전에 MMU가 없이도 가능 부팅이 가능(ARM7)하며, Power PC인 경우는 linux를 최적화하기위해서 사용했었다.
- GNU Toolchain Download
https://toolchains.bootlin.com/
2.2 Mentor (CodeSourcery)
SoC와 같이 대부분 오래전부터 배포진행했으며, mentor사가 인수하여 지속적으로 배포를 하고 있다.
이전에는 montavista에서도 제공을 했던거 사용했는데 요즘은 어떻게 되었는지 잘모르겠다.
이전에 사용한 version
https://ahyuo79.blogspot.com/2015/11/arm-tool-chain.html
각 기본정보를 확인
https://www.mentor.com/embedded-software/sourcery-tools/sourcery-codebench/editions/
- GNU Toolchain Download (정보 확인가능)
https://sourcery.mentor.com/GNUToolchain/release2635
https://sourcery.mentor.com/GNUToolchain/release2032
Mentor(CodeSourcery) 역시 보면 아래의 Linaro Version 처럼 EABI로 인해 나누어져 배포한다.
2.3 Linaro
Linaro도 SoC와 함께 배포되어 Download하기가 쉽고 Ubuntu에서 설치가 쉬워서 요즘 많이 이용되어지는 것 같다.
- Linaro 회사정보
- GNU ToolChain Download
https://releases.linaro.org/components/toolchain/
https://releases.linaro.org/components/toolchain/binaries/latest-5/
https://releases.linaro.org/components/toolchain/binaries/5.2-2015.11-2/
- linaro 전체 release site 및 Git
https://web.archive.org/web/20121031094507/http://git.linaro.org/gitweb
- 컴파일러 Prefix의 의미 ( A-B-C)
A 는 target architecture 의미한다고 한다.
(e.g. arm for AArch32 little-endian, aarch64 for AArch64 little-endian)
B 는 vendor 의미이며, 사용여부는 옵션 (배포한 Vendor) (none or unknown for generic)
일반적으로는 거의 사용하지 않는다고 하며, 아래에도 사용하지 않음 (e.g not present in arm-linux-gnueabihf)
C 는 사용중인 ABI 의미를 말하며 관련 system(OS)도 기술한다.
(e.g linux-gnu* for Linux, linux-android* for Android, elf or eabi for ELF based bare-metal).
Bare Metal ABI는 New Lib를 사용하고 NonOS용으로 사용한다고 한다
- 컴파일러 기능요약
- hw fpu 지원/미지원
- little / big endian
- glibc / newlib 사용 ( bare-metal : newlib 사용 (NonOS용) or glibc 이용)
e.g arm-linux-gnueabihf -mcpu=cortex-a7 -mfloat-abi=hard -mfpu=vfpv4 -mcpu=cortex-a7 -mfpu=vfpv4 -mfloat-abi=softfp|hard -mcpu=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=softfp|hard
- ARMv7
Toolchains for little-endian, hard-float, 32-bit ARMv7 (and earlier) for GNU/Linux systems
arm-linux-gnueabi
Toolchains for little-endian, soft-float, 32-bit ARMv7 (and earlier) for GNU/Linux systems
arm-none-eabi
Toolchains for little-endian, soft-float, 32-bit ARMv7 (and earlier) for bare-metal systems
armv8l-linux-gnueabihf
Toolchains for little-endian, 32-bit ARMv8 for GNU/Linux systems
- ARMv8
Toolchains for little-endian, 64-bit ARMv8 for GNU/Linux systems
aarch64-none-elf
Toolchains for little-endian, 64-bit ARMv8 for bare-metal systems
aarch64_be-linux-gnu
Toolchains for big-endian, 64-bit ARMv8 for GNU/Linux systems
aarch64_be-none-elf
Toolchains for big-endian, 64-bit ARMv8 for bare-metal systems
2.3.1. Linaro의 Ubuntu Package 지원
상위에서 linaro version에 대해 알았으니, Ubuntu에서 쉽게 설치하는 법을 알아보자
- Ubuntu APT Package 사용법
- Ubuntu Toolchain 지원확인
$ sudo apt-cache search gcc-arm* //현재 지원되는 Package를 찾아보자 gcc-arm-linux-gnueabihf - The GNU C compiler for armhf architecture gcc-arm-linux-androideabi - cross toolchain and binutils for Android/Bionic on ARM gcc-arm-none-eabi - GCC cross compiler for ARM Cortex-A/R/M processors gcc-arm-linux-gnueabi - The GNU C compiler for armel architecture
- Ubuntu Toolchain 설치
$ sudo apt-get install gcc-arm-linux-gnueabihf $ sudo find / -name arm-linux-gnueabihf* /usr/bin/xxxx //binutils , gprof gcov, gcc 설치 /usr/share/man/man1/xxx /usr/lib/gcc-cross/arm-linux-gnueabihf /usr/arm-linux-gnueabihf /usr/x86_64-linux-gnu/arm-linux-gnueabihf ...
기존의 TI의 am335x/am437x bsp에도 이미 동일한 이름으로 이미 설치가 되어있네요(arago project)
다음부터 가급적 Download해서 사용하고 PATH를 정하고 사용해야겠네요.
https://blog.thinkbee.kr/linux/crosscompile-arm/
https://blog.thinkbee.kr/linux/linux-update-alternatives/
3. Prebuilt Toolchain for Window
오래전에, Cygwin용을 자주 사용했는데, 개발환경의 제약으로 인해 점점 사용하지 않게되었다.
다시 사용할 일이 있다면 다음아래의 사이트에서 Download하자
Cygwin용
http://cygwin.com/
Mingw 용
https://mingw-w64.org/doku.php
4. Eclipse GCC 사용
아직 적용을 해보지 못했으며, 궁극적으로 모든것을 Eclipse 기반으로 하고 싶은 생각을 가지고 있다.
매번 Terminal에서 make와 shell script를 이용하여 하고 싶지 않으며, 이용하더라도 Eclipse에서 편하게 사용하는 방법을 찾고자 한다.
Eclipse와 함께사용
https://www.codeguru.com/cpp/cpp/getting-started-with-c-for-eclipse.html