3.Software 데꾸바쮸(Decoupage)

Little Endian, Big Endian

0x12345678

Little-End : 계란의 뾰족한 끝을 먼저 꺨 것인가 

0x1003 : 0x12

0x1002 : 0x34

0x1001 : 0x56

0x1000 : 0x78

 

Big-End : 계란의 뭉툭한 끝을 먼저 깰 것인가

0x1003 : 0x78

0x1002 : 0x56

0x1001 : 0x34

0x1000 : 0x12

 

ARM 환경의 Embedded system에서는 Little Endian으로 Memory 내용을 인식이 Default

---

컴파일에 대한 단상

Compile : v.책을 편집하다, v.안내서를 만들다 (Computer에게 안내서를 만드는 행위)

프로세서가 해석할 수 있는 "기계어"를 만드는 행위

 

옛날에는 사람이 Assembly로 직접 Code표를 찾아 기계어를 작성함.

이러한 귀찮은 행동을 하기 싫어서 만든것이 Assembler -> Compiler의 최초 태동

그런데 Processor마다 호환성에서 한계를 드러내기 시작했는데, 다른 Processor마다 맞는 Assembly를 만들어내는 Compiler가 있었다는 귀찮음이 새로운 entity를 만들어냄 -> C, C++과 같은 High Level Language Compiler

 

"C가 이식성이 좋다" 함의 의미 -> 많은 Processor들에 C Compiler가 제공된다.

 

C로 coding하고 compile 한다는 의미 ->

C compiler를 이용하여,

ARM이 해석 할 수 있는 Assembly를 만들고,

ARM Assembler를 이용하여, 

ARM core가 해석할 수 있는 일련의 Bit pattern을 만들어 냄

-> 이렇게 만들어 낸 Bit pattern : Excutable binary image

-> 이렇게 메모리 안에 있는 숫자들을 CPU가 실행하면 명령, 수정하거나 고치면 데이터

---

컴파일 공장 이야기

컴파일 공장의 목적 : Binary Image를 만들어내는 것

 

컴파일

C compiler(armcc, tcc) : Souce file들을 Assembly로 만들고(.s),

Assembler(armasm) : Assembly를 실행 가능하고, Symbol 정보를 가진 특정한 type(.o, elf)으로 만들고,

Native Code(기계어)인 binary 파일을 뽑아냄

 

컴파일 중 발생한 문제?!?!

간단한 소프트웨어는 위 과정처럼 binary 파일을 만들 수 있지만, 복잡한 소프트웨어는 못 만들어냄..

 

위 문제를 해결하는 방법??

Link!!

-> 여러 개의 .c file을 Assembly로 만들고

Assembler를 이용하여 Object라는 새로운 기계형태를 만들어 내어 object들을 link(연결)하는 것을 의미.

 

Object들은 각각의 기계어지만, 혼자서 완성된 형태는 아니며, 각기 다른 .c를 컴파일 한 object와 연결할 수도 있는 정보와, 디버깅이 가능한 symbol 정보를 담고 있음. -> elf 형태  -> elf 형태를 따른 object들은 linker를 이용하여 서로 link 할 수 있음!!  +  Library는 미리 컴파일을 해 놓은 Object file의 모음

 

전처리기(Preprocessor)

armcc, tcc가 *.c -> *.s로 바꾸기 전에,

C processor와 lint Processor라는 걸 이용해서 Syntax적인 것들을 정리함.(macro + define 모두 바꿔치기 , syntax error 점검, armcc와 tcc가 제대로 컴파일 할 수 있는 단계까지 만들어 놓음) -> .i 파일을 만듦 (armcc, tcc에서 다 처리함)

 

 

---

Memory Map과 Symbol 이야기

Symbol 이란?

 

Linker가 알아볼 수 있는 기본 단위, Link를 한 후에는 자신만의 주소를 갖게 되는 특별한 단위.

 

ELF object file내에 Symbol table : Source code에 의하여 참조되는 Symbol들의 이름과 위치 정보가 들어 있음.

 

다른 file에서 정의된 Symbol은 한 개의 object file 내에서 모두 처리되지 못하는데, 이러한 불완전한 Symbol들은 Linker에 의해서 처리하여 다른 파일에 있는 Symbol을 연결하여 사용할 수 있도록 만듦.

 

이런 Symbol들은 메모리에 실재로 적재되지는 않고 Linker만이 Symbol을 참조하여, Symbol들을 주소로 모두 변환해서 Binary로 만들어줌.

 

Symbol에 해당하는 것들 (Global) : 함수, 전역변수, static 변수

RW ( .data ) : read-write 초기값이 있는 전역변수 -> ROM (언제라도 modify 되어야 하므로) + RAM(값 변경되어야 하므로)

ZI  ( .bss ) : Zero-initalized 초기값이 0인 전역변수 + stack + heap -> RAM(모두가 0이므로 굳이 ROM에 저장안해도 됨)

RO : Read Only 수정이 불가능한 const 전역변수 ( .constdata ) + text인 code ( .text ) -> ROM(항상 유지)

 

Symbol에 해당하지 않는 것들 (Local) : 나머지들(Temporary로 사용하며, 절대 주소를 가질 필요 없음)

Local 변수 : stack에 자리 잡음

Dynamic Memory Allocation : Heap에 자리 잡음

 

---

ELF format Object File

ELF : Excutable and Linking Format

 

Code 영역 : .text

Data 영역 : .rodata, .data, .bss

 

---

Scatter Loading - Linker Description Script

XIP - Execution In Place : 직접 Software를 실행할 수 있다는 의미 - Word 단위의 Access가 가능하여, Software를 Execution 할 수 있는 것

 

Execution이 가능하다는 것 - Code 영역이 들어갈 수 있는 Memory의 type은 XIP가 가능해야 한다.

 

*.scl - Scatter Loading File :

최종 실행 이미지를 만들 때 XIP가 가능한 Memory에는 Code를,

Read Write가 가능한 영역에 Data를 mapping 시켜서 배치할 수 있게 하는 것

 

Loading View - ROM에 적재되었을 때의 모양새,

Execution View - 실제 Image가 실행 될 때의 모양세를 의미.

 

---

Map file 분석

Map file의 4가지 Format

1. Image Symbol Table

• Linker가 만들어낸 Symbol과 주소 그리고 Region
• User가 만들어낸 Symbol과 주소 Size 그리고 속해 있는 object

2. Memory Map of the image

• Scatter Loading에 맞춘 Region에 따라 구획을 나누어서
• 주소와 Size, type, 그리고 section과 Object, 요놈이 Linker Ouput Section

3. Image Component sizes

• 각 object 또는 library에 대한 RO, RW, ZI가 차지하는 Size. 요놈이 Linker Input Section

4. 전체 Layout

• 전체적인 Memory에 RO, RW, ZI가 얼마나 차지 하는지에 대한 정보