최근에 프로세서는 ARM 이 대세죠. 

그중 Cortex 시리즈가 주력 입니다. 

예전에는 프로세서 공부는 주로 8 비트 프로세서

아니면 

i386 계열을 공부 했지만

커널을 위해서라면 i386 이어야 하죠..

어쩌면 이 부분도 소프트웨어 하는 분들이 

말하는 신의 영역이었을지 모릅니다 .

지금은 모바일이 대세고 임베디드가 또한 대세죠..

이러다 보니 프로세서의 트렌드도 바뀌었습니다. 

예

ARM 입니다. 


요즘 ARM 모르고 임베디드 한다면 

갸우뚱 하는 세대 입니다. 

그렇다고 ARM 만 있는 건 아니지만 

그냥 최근에 좀 아는 척 하려면  ARM 에 대해서 이야기 해야 합니다. 

그런데 

PC 용 개발을 하다가 임베디드 시스템을 하다보면 

정말 으악 하고 놀라는 것이 개발 환경입니다. 

그 열악한 통합환경.

경험하신분들은 통감 하실겁니다. 

의외로 요즘 임베디드 진입하시던 분들은 이 부분에서 의외로 많이 좌절합니다. 

특히 디버거 부분 

커맨드 창 명령 입력...

그런데 이거 익숙해지면 

사람이라는 것이 간사한게 이렇게 개발하는 것이 더 편합니다. 

뭐 자유도는 무궁무진하거든요 ㅋㅋ

어찌되었든 이 개발 환경에서 빠지지 않고 등장하는 것이 크로스 컴파일 환경입니다. 

자 

모르는 분들을 위해서 잠시 설명

크로스 컴파일 이라는 것이 뭐냐 하면요..

여러분이 PC 에서 개발할 경우에

컴파일러도 PC에서 돌고 그 컴팡리 결과 실행문도 PC에서 돕니다. 

이런 컴파일러를 네이티브 컴파일러라고 합니다. 

그런데 

ARM 프로세서에서 동작하는 프로그램을 작성하는 경우 

컴파일러는 보통 리눅스가 되었던 윈도우가 되었던

PC 에서 하게 됩니다. 

그런데 그 결과물인 실행 파일은 ARM 보드에서 실행해야 하죠...

이렇게 컴파일을 수행하는 시스템과 

컴파일 결과물인 실행파일이이 수행하는 시스템이 다를때

사용되는 컴파일러를 크로스 컴파일러라고 합니다.

자 그런데 

여러분은 크로스 컴파일러를 어떻게 얻으셨나요?

예

평가 보드 파는 곳에서 받거나

아니면 인터넷에서 

받았겠지요...

이렇게 받을때 보통 크로스 컴파일러 툴체인이라고 합니다. 
(Cross Compiler Tool Chain)

왜 이렇게 툴 체인이라고 할까요?

크로스 컴파일러 툴체인은 

GNU 계열인 gcc 컴파일러 이외에는 논하지 말기로 하죠..

이게 공짜이기도 하지만 기능도 막강하고 

현존하는 프로세서를 가장 많이 지원하는 

정말 강력한 놈입니다. 

한가지 흠이라면 책임지는 회사가 없다는 것이죠..

보통  gcc  컴파일러라고 하면 C, C++ 컴파일러만 있는 줄 아시는 데

정말 정말 별거 다 있습니다 .

하지만 우리는 C 에 집중헤 보죠...

gcc 는 C 소스를 실행 파일로 바꾸어 줍니다. 

그런데 이게 실제로는 여러 부분으로 나누어져 있습니다. 

혹시 다음과 같은 것 들어 보았습니까?

binutil
gcc
glibc,newlib
gdb

요것이 바로 크로스 컴파일러 4종 셋트가 되겠습니다. 

binutil 은 바이너리 유틸리티의 약자 입니다 .

이놈은 바이너리를 다루죠 즉 어셈블러 영역도 다루고 링크와 관련된 부분도 다룹니다. 

결국 여러분은 gcc 를 다루지만 최종적으로는  binutil 패케지들의 프로그램이 관여합니다. 

그다음  gcc 

이놈은 C 언어를 어셈블러 소스로 만들뿐입니다 

물론 사용의 편리를 위해서  gcc 는 binutil  에 있는 프로그램을 호출하죠..

여러분이  ld 가 있는데 이것은  gcc  가 호출할수도 있고 직접 실행할수도 있습니다 .

예..

굳이 자세하게 알 필요는 없습니다  gcc 가 다 알아서 해 줍니다. 

여러분은 gcc 명령과 관련 옵션만 아시면됩니다. 

그다음에

glibc . newlib. bionic

이것은 C 언어를 사요할 때 사용되는 표준 라이브러리 패케지 입니다. 

gcc 는 소스를 컴파일만 하죠..

여러분이 흔히 사용하는 printf() 함수는 gcc 에 있는 것이 아니고 

glibc ,newlib, bionic  과 같은 라이브러리가 제공하는 겁니다. 

이중 glibc  는 일반 리눅스용이고요
newlib  는 아주 작은 임베디드 용이고요
bionic은 안드로이드 용입니다 .

각 용도에 맞게 사용되죠..

그중 가장 많은 함수군을 지원하고 기능이 좋은 것은 glibc  입니다. 

그런데 안드로이드는 이걸 안쓰고 bionic 을 만들었을까요?

그 이유는 라이센스 문제와 glibc 의 효율성 때문입니다 .

사실 glibc  는 좀 큽니다. 

아주 작게 만든것이  newlib  죠

하지만 이놈은 기능이 많이 없어요...

메모리가 부족한 곳에 흔히 쓰입니다. 

마지막으로 gdb 가 있습니다. 

이 것은 디버거용입니다. 

저 같은 경우는 개인적으로 gdb 를 거의 쓰지 않습니다. 

게을러서 그렇죠..

그냥 printf() 로 때립니다. 

여러분은 그러지 마셨으면 합니다 .

한번쯤  gdb 와 친해져 보세요..

흠..

그런데 임베디드 시스템에서  gdb 는 여러가지로 사용하기 부담 스럽죠. ㅋㅋ

자 이렇게 4종 세트와 시스템 콜과 무슨 관계가 있을까요?

일단 이것을 이야기 하기적에

크로스 컴파일 툴 체인도 최적화가 필요하다는 것 아십니까?

여러분이 인터넷에서 구하는 것은 범용입니다 .

예..

어떻게 써도 무난하다는 것이지요

하지만 컴파일 결과는 차이가 날 수 있고 

가끔은 시스템에서 동작하는데 트러블을 일으킬수 있습니다. 

왜 그럴까요?

그건은 크로스 컴파일러를 빌드 하면 알게 됩니다. 

자 여러분은 크로스 컴파일러를 만나다 보면 

arm-elf-gcc  같은 실행 파일명을 보게 됩니다. 

이놈은 거의 100% 펌웨어 용입니다. 

부트로더 나 커널을 컴파일 하는 놈이죠..

엥?

커널을 위에 것으로 컴파일 할 수 있다고요?

예 커널은 펌웨어에 속합니다. 

왜 커널이 펌웨어에 속하는지 나중에 알아보고요..

위 명려이 왜 저런식으로 구성되었는지 봅시다. 


가장 처음 오는 것은 arm 용이라고 표기하는 것이죠

arm-

이렇게 표기 합니다. 

이단어가 붙었다는 것 자체가 크로스 컴파일러임을 알려주죠..

네이티브 컴파일러는 진짜 심플하게 컴파일러 이름이 붙습니다. 

gcc

이걸로 끝이죠

아 배고파서요...

나머지 내용은 다음에 

오늘은 여기까지..

이 게시물을...