Make File 간단한 개념및 사용상의 기본설명

Make의 간단한 설명

 

 - make - maintain, update, and regenerate related programs and files

  make유틸리티의 목적은 프로그램 그룹 중에서 어느 부분이 새롭게 컴파일 되어야 하는지를 자동적으로 판단해서 필요한 커맨드(gcc따위)를 이용해서 그들을 재 컴파일 시키는 것이다.

 - 소스 파일이 많아지고 각 파일에 대해 서로 다른 컴파일러와 어셈블러를 사용하고 각기 다른 옵션으로 컴파일 해야 된다면 컴파일 하는데 시간도 많이 걸리고 일일이 타이핑해야 하기 때문에 개발자는 힘이 든다. 또한 커널과 같은 규모가 큰 프로젝트를 컴파일 할 때는 컴파일 시간도 많이 걸린다. 개발하는 시간도 모자란데 컴파일해서 결과를 확인하는 일에 많은 시간 낭비를 막기 위해 나온 것이 make다.

  make에 대한 정의를 내린다면 make는 파일 관련 유틸리티이다. make는 각 파일 간의 종속 관계를 파악하여 기술 파일(makefile)에 기술된 대로 컴파일 명령이라든지 혹은 셸(shell) 명령을 순차적으로 내린다. 다시 말해 make는 각 파일에 대한 반복적 명령을 자동화시켜서 개발자의 수고를 덜고 시간을 절약할수 있다.

  프로젝트에 make를 도입한다면 컴파일 시간을 절약할 수 있고 프로그램의 종속 구조를 빠르게 파악할 수 있으며 관리가 용이해진다. 또한 단순 반복 작업과 재작성을 최소화 시킬수 있다.

  make는 소스를 컴파일하는 것 뿐만 아니라 닥북(DocBook) 문서를 컴파일하고 기타 순차적이고 반복적인 어떠한 작업에도 이용될 수 있다.


  make의 기본 동작

소스파일의 내용

diary.h :

#include<stdio.h>

int memo();

int calendar();



main.c :

#include diary.h

int main() {

   memo();

   calendar();

   return 0;

}

memo.c :

#include diary.h

int memo() {

    printf(function memo.\n);

    return 0;

}


calendar.c :

#include diary.h

int calendar() {

    printf(function calendar.\n”);

    return 0;

}

 소스 파일의 구조도


diary.h

memo.c

main.c

calendar.c







memo.o

calendar.o

main.o


diary





 

                                        실행파일      


Makefile의 내용

all  :  diary                                                                (1)

                                                           

diary : memo.o calendar.o main.o                                            (2)

     gcc W Wall o diary memo.o calendar.o main.o                        (3)


memo.o : memo.c                                                           (4)

     gcc W Wall c o memo.o memo.c                                    (5)

calendar.o : calendar.c                                                      (6)

     gcc W Wall c o calendar.o calendar.c                               (7)


main.o : main.c                                                             (8)

     gcc W Wall c o main.o main.c                                       (9) 


(1)    make 명령을 내리면 make는 먼저 현재 디렉토리 내에서 기술 파일을 찾는다. 기술파일은 Makefile, makefile 또는 GNU make인 경우에는 GNUmakefile 일 수 있다. 지금 상황에서는 Makefile이 기술 파일에 해당한다. 


(2)    Makefile 내에서 제일 처음 오는 타겟을 찾는다. 현재로서는 all 타겟이 해당된다.


  (3) all 타겟을 만들기 위한 종속 항목 diary를 보고 diary가 현재 디렉토리 내에 없앤다는 것을 확인한다.


  (4) diary를 생성하기 위한 룰을 찾기 위해 (2)번 항목을 접하게 되고 diary를 생성하기 위한 첫 번째 종속 항목 memo.o 가 아직 만들어져 있지 않다는 것을 확인한다.


  (5) memo.o를 생성하기 위한 룰을 찾기 위해 (4)번 항목을 읽게 되고 memo.o의 종속 항목 memo.c 가 현재 디렉토리에 존재하는 것을 확인하면 make는 memo.o를 만들기 위한 명령인 (5)번 명령어로 memo.o를 컴파일 하여 만들어 낸다.  


-         만약 memo.o 가 미리 만들어져 있다면 make는 다시 만들 필요가 있는지 검토한다. 만들어져 있는 memo.o 보다 memo.c의 수정 시간이 최근이라면 momo.o가 만들어 지고 나서 memo.c 가 수정되었기 때문에 다시 만들 필요가 있다. 다시 만들 필요가 있다면 make는 (5)번 명령을 수행하고 아니라면 (5)번 명령을 건너뛰고 다음 과정으로 넘어간다. 다른 파일에 있어서도 마찬가지로 만들어져 있다면 만들게 된다.


  (6) 다시 (2)번으로 가서 diary의 종속 항목 memo.o는 생성되었지만 calendar.o 는 아직 생성되지 않았다는 것을 확인한다.


  (7) calendar.o를 생성하기 위한 룰인 (6)번으로 가서 calendar.o는 calendar.c에 종속되어 있고 calendar.c는 현재 디렉토리에 존재하고 있다는 것을 확인하고 calendar.o를 생성하기 위한 명령인 (7)번 명령을 수행하여 calendar.o를 생성한다.


  (8) 다시 (2)번으로 가서 diary를 생성하기 위한 종속 항목인 main.o가 아직 만들어지지 않았다는 것을 확인하고 main.o를 생성하기 위한 룰인 (8)번으로 가서 main.c의 존재 유무를 확인하고 (9)번 명령을 통해 main.o를 생성한다.


  (9) 다시 (2)번으로 가서 이제는 diary를 생성하기 위한 종속 항목인 memo.o, calendar.o, main.o 가 다 만들어진 것을 확인하고 diary를 생성하기 위한 명령어인 (3)번 명령을 통해 diary를 생성해 낸다.


  (10) (1)번으로 가서 all 타겟을 생성하기 위한 dirary가 만들어진 것을 확인한 후 현재 all 타겟을 생성하기 위한 특별한 명령어가 없기 때문에 make는 all 타겟이 생성되었다는 것으로 간주하고 정상적으로 종료한다.  

 

Makefile의 내부구조   

 

  - Makefile은 기본적으로 아래와 같이 목표(target), 의존 관계(dependency), 명령(command)의 세 개로 이루어진 기분적인 규칙(rule)들이 계속적으로 나열되어 있다.

 

target ... : dependency ...

                command

                ...

                ...

 

목표(target) 부분

명령(command)이 수행되어서 나온 결과 파일을 지정한다. 당연히 목적 파일(object file)이나 실행 파일이 될 것이다.

 

명령(command)부분

여기에 정의된 명령들은 의존 관계(depenency)부분에 정의된 파일의 내용이 바뀌었거나, 목표 부분에 해당하는 파일이 없을 때 이곳에 정의된 것들이 차례대로 실행이 된다. 일반적으로 쉘에서 쓸 수 있는 모든 명령어들을 사용할 수가 있으며 bash에 기반한 쉘 스크립트도 지원한다.

 

- 참고로 목표 부분에는 결과 파일만 올 수 있는 것이 아니고, 보통 make clean 에서와 같이 간단한 레이블(label) 기능을 제공하기도 한다.

 

- 명령 부분은 꼭 TAB 글자로 시작해야 한다. 그냥 빈칸 등을 사용하면 make 실행 중에 에러가 난다. make는 명령어인지 아닌지를 TAB 가지고 구별함.


◆ 매크로란?

 

  - 기술파일 내에 매크로는 C와 마찬가지로 사용자 정의 변수에 특정한 문자열을 정의하고 표현하는 것을 의미한다. 이후 매크로는 기술 파일 내에 정의된 문자열로 치환되어 사용될 수 있다. 매크로를 사용하는 일은 보다 일관되고 보다 이식성이 높고 융통성 있는 기술 파일을 만들기 위해 필요하다.


   CC    =  gcc

 가령 위와 같은 CC 매크로를 정의했다면 CC는 기술 파일 내부에서 $(CC)로 표기함으로써 gcc로 치환 될 수 있다. 만약 같은 소스를 ARM 아키텍처에 맞게 크로스 컴파일러로 컴파일해서 ARM CPU에서 동작하는 실행 파일을 만들어내고자 한다면 다음과 같이 CC 매크로의 정의 부분만 간단하게 고치면 된다.

   CC     =  arm-linux-gcc

매크로를 사용하지 않았다면 위와 같이 간단하게 끝나지는 않았을 것이다. 기술 파일 내에 gcc가 사용된 모든 부분을 일일이 찾아내서 arm-linux-gcc로 바꾸어야 했을 것이다. 매크로를 정의해서 사용하는 일은 융통성 있는 기술 파일을 만들기 위해 필요한 일이며 독자는 적재적소에  매크로를 사용해서 융통성 있는 기술 파일을 만들 수 있다. 어디에든 반드시라는 단어는 존재하지 않으며 독자가 판단하기에 매크로를 사용하기에 적절한 곳이라면 매크로를 사용하면 된다. 매크로를 사용하는데 있어서 매우 간단한 규칙이 있다.


매크로 작성 기본 규칙


(1) 매크로의 정의는 =를 포함하는 하나의 문장이다.

  NAME   = string

=의 좌측에는 매크로 이름이 오고 우측에는 정의 문자열이 온다. 관습적으로 매크로 이름은 대문자를 사용한다.


(2) #은 주석문의 시작이다.

  NAME  = string  #주석


(3) 여러 행을 사용할 때는 \’ 를 사용한다.

NAME  = -D_KERNEL__ -DMODULE W Wall \

          -DNO_DEBUG

위 문장은 아래 문장과 동일하다.

  NAME  = -D__KERNEL__ -DMODULE W Wall DNO_DEBUG


(4) 매크로를 참조할 때는 소괄호나 중괄호로 둘러싸고 앞에 $를 붙인다.

MAME  = string

${NAME}          #string

$(NAME)          # string

${NAME}.c        # string.c

macro_${NAME}   # macro_string

중괄호나 소괄호 둘 사이에는 미묘한 차이가 있으나 둘다 사용해도 무방하다. 단지 중괄호는 셸에서 환경변수 치환에도 사용되기 때문에 셸 환경 변수와의 구분을 위해 소괄호의 사용을 권장하는 편이다.




(5) 정의되지 않은 매크로를 참조할 때는 null 문자열로 치환된다.

NAME  = string

my $(NAME)         # my string으로 치환한다.

my $(NO_DEFINE)   # my로 치환된다. (NO_DEFINE은 정의되지 않음)


(6) 중복된 정의는 최후에 정의된 값을 사용한다.

NAME   = stringA

NAME   = stringB

$(NAME)  # stringB로 치환된다.


(7) 매크로 정의 시 이전에 정의된 매크로를 참조해서 정의할 수 있다.

NAME   = string

NAME   = my $(NAME)   # NAME2는 my string으로 정의됨


(8) 여러 대입 기업을 사용할 수 있다.

NAME1   = string  

NAME2  := string  

NAME2 += string  

NAME3 ?= string   


◆ 매크로 사용시 주의 사항


(1) 구문을 위해 문자열에 따옴표를 넣으면 따옴표 또한 문자열의 일부로 인식한다.

NAME   = string

$(NAME)      # string 이 아니라 string으로 치환된다.


(2) 매크로의 이름에는 :, =, #이 들어가서는 안 되고 탭으로 시작해서도 안된다.

              NAME   = string          X

NAME:2   = string                    X

NAME#2  = string                     X


(3) 매크로는 반드시 치환될 위치보다 먼저 정의 되어야 한다.

$(NAME)         # 위에 정의되어 있지 않음으로 null 문자로 치환된다

NAME   = string


(4) <, >과 같은 셸 메타 문자의 사용을 자제해야 한다.


◆ 내부 매크로

 

- make에서는 내부 매크로라는 것이 있다. 이것은 우리가 맘대로 정할 수 있는 매크로는 절대 아니다. 대신 매크로를 연산, 처리하는데 쓰이는 매크로라고 하는 것이 더 적당할 것이다.


내부적으로 정의된 매크로 리스트

 AR

 아카이브 관리 프로그램

 ar

 AS

 어셈블러

 as

 CC

 C 컴파일러

 cc

 CXX

 C++ 컴파일러

 g++

 CO

 RCS checkout 프로그램

 co

 CPP

 C 전처리기

 cc E

 FC

 포트란 컴파이러

f77

 GET

 SCCS 관련 프로그램

 get

 LD

 링크

 ld

 LEX

 스캐너 코드 생성기

 lex

 PC

 파스칼 컴파일러

 pc

 YACC

 파서 코드 생성기

 yacc

 MAKEINFO

 Texinf 파일을 Info 파일로 변환

 makeinfo

 TEX

 TeX 문서로부터 TeX DVI 생성

 tex

 TEXI2DVI

 Tecinfo 파일을 div 파일로 변환 프로그램

 texi2dvi

 WEAVE

 Web을 TeX로 변환

 weane

 CWEAVE

 C Web을 TeX로 변환

 tangle

 TANGLE

 Web을 파스칼로 변환

 ctangle

 CTANGLE

 C Web을 C로 변환

 rm f

 RM

 파일을 지우는 명령어

 rv

 ARFLAGS

 ar 플래그


 ASFLAGS

 어셈블러 플래그


 CFLAGS

 C 컴파일러 플래그


 CXXFLAGS

 C++ 컴파일러 플래그


 COFLAGS

 RCS co 플래그


 CPPFLAGS

 C 전처리기 플래그


 FFLAGS

 포트란 컴파일러 플래그


 GFLAGS

 SCCS get 플래그


 LDFLAGS

 링크 플래그


 LFLAGS

 Lex 플래그


 PFLAGS

 파스칼 컴파일러 플래그


 YFLAGS

 Yacc 플래그



자동 매크로 리스트

  $?

 현재의 타겟보다 최근에 변경된 종속 항목 리스트

 (확장자 규칙에서 사용 불가)

  $^

 현재 타겟의 종속 항목 리스트

 (확장자 규칙에서 사용 불가)

  $@

 현재 타겟의 이름

  $<

 현재 타겟보다 최근에 변경된 종속 항목 리스트

 (확장자 규칙에서 사용 가능)

  $*

 현재 타겟보다 최근에 변경된 현재 종속 항목의 이름 (확장자 제외)

 (확장자 규칙에서 사용 가능)

  $%

 현재의 타깃이 라이브러리 모듈일 때 .o 파일에 대응되는 이름


◆ 확장자 규칙

 

- 확장자 규칙이란 간단히 말해서 파일의 확장자를 보고, 그에 따라 적정한 연산을 수행시키는 규칙이라고 말할 수 있다. 가령 .c 파일은 일반적으로 C 소스코드를 가르키며, .o파일은 목적화일을 말하고 있다. 그리고 당연히 .c 파일은 컴파일 되어서 .o 파일이 되어야 하는 것이다. 여기서 한가지 매크로가 등장하게 된다. .SIFFIXES 라고 하는 매크로인데 우리가 make 파일에게 주의 깊게 처리할 파일들의 확장자를 등록해 준다고 이해하면 될것이다.

.SUFFIXES = .c .o

위의 표현은 .c 와 .o 확장자를 가진 파일들을 확장자 규칙에 의거해서 처리될수 있도록 해준다.


◆ 더미 타겟 이란?


 clean  :

          rm rf  *.o  diary

여기서 clean과 같은 타겟을 더미 타겟(Dummy target) 또는 Phony target이라고 한다. 일반적으로는 타겟으로 지정되는 것들은 생성될 파일인데 비해 더미 타겟은 생성되지 않은 개념적인 타겟을 의미한다. 더미 타겟은 생성되지 않기 때문에 make clean 명령이 매번 수행된다. 더미 타겟은 재귀적으로 make를 사용할 때 상용 되기도 하고 또 매번 수행해야 될 룰을 정의할 때 사용되기도 한다.


◆ 명령어 사용 규칙


   echo  :

             @echo  echo test!


 위와 같은 룰이 있을 때 make echo하게 되면 make는 내부적으로 새로운 셸을 띄우고 다음과 같이 명령을 내린다.


   /bin/sh c echo echo test!


여기서 새로운 셸을 띄우는 것이 중요한데 다음과 같은 룰이 있을 때 make del 명령을 내리게 되면 현재 디렉토리의 모든 파일을 지우게 된다


   del :

            cd ./backup

            rm rf*


원래 의대대로 실행을 시키려면 세미콜론 (;)을 이용한다.


   del :

            cd ./backup; rm rf*


만약 backup 디렉토리가 현재 디렉토리에 존재하지 않는다면 &&을 사용한다.


   del :

           cd ./backup &&rm-rf*


   .SILENT :

.SILENT 타겟은 특수 내장 타겟으로써 .SILENT 타겟에 등록된 종속 항목에 수행되는 명령어들은 에코 기능을 끄기 때문에 명령어 수행이 화면에 출력되지 않는다.


make는 명령어 한 행을 수행 후 매번 리턴 값을 체크하여 0이 아닌 값이 리턴된 경우 수행을 종료 한다.

만약 명령어가 비정상적으로 수행되어 0이 아닌 값이 리턴되더라도 make 수행을 계속하고자 한다면 명령어 앞에 - 을 붙인다.


   cat :

             -cat file.txt


   .IGNORE :


.IGNORE 역시 특수 내장 타겟으로 .IGNORE의 종속 항목에 등록된 파일들에 수행하는 명령들에 대해서는 오류가 발생해도 무시한다.


셸 변수를 사용하는 방법은 기술 파일 내부에 셸 스크립트를 사용하는 데도 유의해야 한다. 아래와 같이 셸 스크립트를 사용하는데도 $$ 기호를 두 개 붙여야 한다.


echo_name :

          for NAME in woos test; do echo $${NAME}; done


  #만약 $를 하나만 붙인다면 매크로로 인식하기 때문에 NAME이 매크로로 정의 되어

#있지 않으면 null문자로 처리된다.


◆ 재귀적 make의 사용

  - 여러 디렉토리로 나누어진 소스를 make로 관리하는 기법에는 기술 파일 내부에서 일일이 경로를 지정하는 방법과 VPATH를 사용하는 방법, 마지막으로 재귀적인 make 사용법이 있습니다.


◆ 조건부 수행

  - C에서 if ~ elst 문에 비슷하게 make에는 ifeq ~ else ~ endif 문이 있다.


◆ 함수의 상용

  - make는 기술 파일에서 사용할 수 있는 많은 함수들을 제공한다. make 함수에는 문자열을 처리하기 위한 함수부터 파일관련 함수, 반복을 위한 함수 등이 있고 매우 유용하기 때문에 자주 사용되곤 한다. 몇 가지만 소개 하겠습니다.


make에서 함수형식

   $(함수명 함수 인자들)


셸 명령 함수

   $(shell 셸 명령어)

shell 함수는 자주 사용되는 함수로 shell 뒤에 오는 명령을 수행하고 기다린다.


문자열 처리함수

  $(subst 찾을 문자, 변경할 문자, 목표 문자)

subst 함수는 목표문자에서 찾을 문자를 발견하면 변경할 문자로 치환한다.


공백 문자 제거

   $(strip 문자열)


파일 이름 관련 함수

   $(dir 문자열)

dir 함수는 문자열에서 디렉토리 부분만 추출해 낸다.


- 함수 사용에 있어 주의할 사항

첫째, 함수는 함수를 지원하는 make에서 사용해야 된다.

둘째, 함수의 인자로 콤마(,)와 공백()을 사용할 때 주의 해야 한다.


◆ 특수 타겟


타겟 종류

설명

.DEFAULT

make가 요청된 타겟을 빌드할 룰을 기술 파일 또는 확장자

규칙에서 찾지 못하면 .DEFAULT 타겟에 기술된 명령어를 수행한다.

.IGNORE

명령어 수행 시 반환되는 오류 코드를 무시한다.

.PRECIOUS

.PRECIOUS 타겟에 기술된 파일들은 빌드 중단 신호 또는 명령 행에서 오류가 반환되더라도 지우지 않는다

.SILENT

명령은 실행하지만 실행되는 명령을 화면에 출력하지는 않는다.

.SUFFIXES

.SUFFIXES 타겟에 정의된 확장자들은 중요 확장자들로써 확장자 규칙과 연관될 수 있다.

.EXPORT_ALL_VARIABLES

재귀적 make사용법에 있어서 export 키워드를 단독으로 기술 파일에서 사용한 것과 마찬가지로 기술 파일내의 모든 매크로들을 하위 기술 파일에 전달한다.



'SM. UNIV.DCEG > Embedded' 카테고리의 다른 글

Make File 간단한 개념및 사용상의 기본설명  (0) 2008.10.14
ELF Header 개념 정리  (0) 2008.09.26

TRON이란...

TRON이란

The Real-Time Operating system Nucleus 의 약자

1984년 6월 일본 동경대학의 사카무라 켄 교수에 의해 제안된 컴터 운영체제

보다 이상적인 컴퓨터 아키텍처 구축을 목적으로 개발

"어디에서라도 컴퓨터" 라는 개념으로 출발


TRON의 종류

–ITRON (Industrial TRON)
ITRON은 TRON 의 가장기본이 되는 사양으로서 일반 가전기기부터 산업용 기기에 이르기까지 현재일본내에서 가장 많이 사용되고있다.

–BTRON (Business TRON)
BTRON ITRON의 코어에 파일시스템과 메모리 매니지먼트 등의 기능을 추가하여 만든 OS사양이다.
–CTRON (Communication and Central TRON)
CTRON 정보통신 네트워크용으로 개발된 아키텍처로서 일본 전신전화 공사 에서 채택하여 개발이 이루어졌으며 현재까지 NTT의 통신교환기로 거의 대부분사용되고있다.

–MTRON (Marcro TRON)
MTRON 복수의 ITRON BTRON CTRON 를 유기적인 네트워크로 결합하고 인간의 생활환경전체를 종합적으로 조작하는 것이다.

–eTRON (entity TRON)
eTRON 유비쿼터스 컴퓨팅 환경에서 보안을 위한 아키텍처로 만들어졌다.

---------------------------------------------------------------------------------

TRON에 대한 자세한 자료 들은

http://www.tron.org/

http://www.t-engine.org/

이곳에서 시중에 판매되는 서적을 PDF파일로 만들어둔 자료를 구할수있다.

간단한 일본어만 할수있다면 누구나 손쉽게 구하여 읽을수있다.

'SM. UNIV.DCEG > T-Engine' 카테고리의 다른 글

TRON이란...  (0) 2008.10.14
T-Engine 개발환경 구축의 기본 Cygwin 설치법  (0) 2008.10.14
T-Engine SH7727 보드 메뉴얼  (0) 2008.10.14

T-Engine 개발환경 구축의 기본 Cygwin 설치법

사용자 삽입 이미지


먼저 http://www.cygwin.com 사이트에서 설치 파일다운.
중앙에 Cygwin 로고 그림을 클릭 (Install or update now!)

사용자 삽입 이미지


다운 받으신 파을을 실행면 위와 같은 메뉴 호출

Install from internet               : 설치파일을 다운로드 하여 설치
Download Without Installing   : 설치하지 않고 설치파일만 저장
Install from Local Directory    : 미리 받아둔 설치 파일을 이용하여 설치


사용자 삽입 이미지


다음 메뉴에서 설치 위치를 지정하여 준다
밑의 선택 메뉴는 직접 읽어 해석하길 생략.

사용자 삽입 이미지



다음 메뉴는 다운 받는 방법 선택
Direct Connection 방식으로 선택한다.

사용자 삽입 이미지


한국에서 받기 빠른 사이트는 3곳.
카이스트 다음에서 제공하는 FTP HTTP 이렇게 3곳.

3개중에 한가지 선택
카이스트 : 생각 외로 속도가 느리다.
다음       : 속도는 빠르나 중간에 연결이 멈추는 경우가 있다.

추천으로는 다음쪽으로 하겠다 다음은 끈어 지더라도 FTP나 HTTP 만 바꿔
선택하여 준다면 바로 완료 설치까지 갈수 있다. 훨씬 빠른 설치.

사용자 삽입 이미지



다음메뉴 설치 페키지 선택 메뉴.
T-Engine 환경을 구축 하기 위하여 페키지 설치는 하는것이다.
All을 선택하여 전부 설치 하여도 좋지만 용량과 시간이 오래 걸리는 관계로 필요한것만
설치 하는것이 빠르고 편할것이다.

선택 페키지 :
Base, Devel, Editor, Interpeters, Utils
5가지 선택후 설치.

'SM. UNIV.DCEG > T-Engine' 카테고리의 다른 글

TRON이란...  (0) 2008.10.14
T-Engine 개발환경 구축의 기본 Cygwin 설치법  (0) 2008.10.14
T-Engine SH7727 보드 메뉴얼  (0) 2008.10.14

T-Engine SH7727 보드 메뉴얼

T-Engine SH7727 메뉴얼



T-Engine Sh7727 man.zip

T-Engine SH772메뉴얼

'SM. UNIV.DCEG > T-Engine' 카테고리의 다른 글

TRON이란...  (0) 2008.10.14
T-Engine 개발환경 구축의 기본 Cygwin 설치법  (0) 2008.10.14
T-Engine SH7727 보드 메뉴얼  (0) 2008.10.14

ELF Header 개념 정리

ELF Header

Program Header

.text section

.data section

.bss section

.symtab

.rel.txt

.rel.data

.debug

Section Header table



ELF Header

ELF Format 임을 표시하는 매직 넘버 이미지의 형태, 실행되는 CPU 정보, 리틀 엔디안 인지 빅엔디안 인지 표시하는 byte 순서와 같은 파일 내용의 기본적인 정보를 포함하고 있다.


Program Header

테이블 실행 파일의 메모리 구조 내용을 표시한다. ELF 에서는 세그먼트로 알려진 영역을 섹션으로 저장하고 있다. 이 테이블 에서는 어떠한 섹션이 존재하고 그 섹션의 정보가 있는 곳을 가지고 있다.


.text section

실제로 CPU에서 수행되는 이진 기계 코드가 저장되어 있는 영역이다.


.data section

프로그램이 실행될 때, 이미 초기화되어 있는 데이터가 저장되어 있는 영역이다.


.bss section

프로그램이 실행 될 때, 초기화되어 있지 않지만 static 이나 전역으로 성언된 변수가 위치하는 곳이다.


.symtab 

함수, 전역변수, 섹션의 이름 등이 저장된 영역이다. 실제 이진 기계코드가 실행되기 위해서는 심볼이 필요하지 않다. 링커에 의해서 모두 메모리 주소 값으로 변경된다. 이 정보는 링커나 사람에게 필요한 정보이다.


.rel.txt 

동적 라이브러리의 경우 라이브러리의 코드가 여러 으용 프로그램의 메모리 영역에 연결되는데, 이 때 항상 같은 주소로 연결되지 않는다. 주소가 바뀔 때마다 올바르게 실행되기 위해서 .text 섹션에 변경되어야 할 정보가 저장되어 있다.


.rel.data 

동적 라이브러리의 경우 라이브러리의 코드가 여러 응용 프로그램의 메모리 영역에 연결되는데, 이 때 항상 같은 주소로 연결되지 않는다. 주소가 바뀔 떄 마다 올바르게 실행되기 위해서 .data 섹션에 변경되어야 할 정보가 저장되어 있다.


.debug section

디버거시 필요한 정보를 가지고 있다(gcc 컴파일러에서 g옵션을 주면 이 부분에 gdb와 같은 디버거에서 필요로 하는 정보를 이 부분에 생성한다.) 

'SM. UNIV.DCEG > Embedded' 카테고리의 다른 글

Make File 간단한 개념및 사용상의 기본설명  (0) 2008.10.14
ELF Header 개념 정리  (0) 2008.09.26

'SM. UNIV.DCEG'에 해당되는 글 5건

1 →