몰랐거나, 알고싶지 않았던 것들

이 글에서는 리눅스 헤더로 부터 넘어온 첫 번째 함수 stext에 대해서 알아볼 것이다.

stext 함수는 여기서 ENTRY라는 마치 함수와 같은 것으로 둘려져 있는데, 여기서 ENTRY는 링커스크립트의 것과는 다르게 리눅스 내에서 매크로로 정의되어 있는 function-like macro일 뿐이다.

2번 째 줄의 preserve_boot_args에 대해서 간략하게 알아보자면, 이전 글의 마지막에서 언급한 적이 있는데, 리눅스는 시작 할 때 몇 개의 값을 전달 받고 시작하게 된다고 언급한 적이 있다. 이 값들이 지금 당장은 쓰이지 않지만 나중에 쓰이기 위해 따로 저장하기 위함이라 볼 수 있다.

linux/arch/arm64/kernel/setup.c 에 위치하고 있는 아래의 boot_args에 저장하게 되는 꼴이 된다.

사실, 이 글은 딱히 ARM architecture에 국한 된 것은 아니다.

"Alignment가 무엇인가" 대한 글인데.. 살짝 요약하기 전에 바로 본론으로 들어가보도록 한다.

컴퓨터라는 놈은 특히 ARM architecture에서는 무언가를 실행하기 위해서, CPU 바로 옆에 있는 레지스터와 메모리 사이에 읽고 쓰는

연산이 굉장히 많다. 이때 주의깊게 봐야 할 점은 메모리에서, 어떤 주소에서 얼마 만큼 읽어 올 것인가가 주된 내용이다.

아래 그림에서 각 메모리 주소들은 주소를 나타내고 각 주소마다 1byte 만큼을 의미한다.

• READ 주소0 부터 1byte: 아래 색칠 되어있는 0 부분만 읽어오는 것

• READ 주소3 부터 2byte: 아래 색칠되어있는 3 그리고 4를 읽어오는 것
  

• READ 주소3 부터 4byte: 아래 색칠되어있는 3, 4, 5 그리고 6를 읽어오는 것

하지만, 실제 컴퓨터의 동작은 프로그래머가 생각하는 방식으로 동작하지 않고 읽거나 쓸 때 Chunk 단위로 동작하는데 이 단위는 CPU에 따라 다르다. 예를 들어 32bit architecutre에서는 32bit chunk 단위로 움직이고, 64bit architecture에서는 64bit chunk 단위로 움직이게 된다. 즉,

• READ 주소0 부터 1byte: 0 번째 byte를 읽기 위해서 0,1,2 그리고 3번째 byte를 모두 읽고, 그 중 0번 째 byte 값만 다시 OR 연산을 통해
                                           해당 0 번째 byte만을 결과로 갖는다.

• READ 주소3 부터 2byte: 3 번째 부터 2 byte를 읽기 위해서 0,1,2,3 그리고 4,5,6,7 번째 byte를 모두 읽고, 그 중 3번 째, 4번째 byte 값만 다시
                                          OR 연산을 통해 결과로 갖는다

• READ 주소3 부터 4byte: 3 번째 부터 4 byte를 읽기 위해서 0,1,2,3 그리고 4,5,6,7 번째 byte를 모두 읽고, 그 중 3,4,5,6번 째 byte 값만 다시 OR
                                           연산을 통해 결과로 갖는다.

 이처럼, 프로그래머가 읽고 싶은 번째부터 몇 개의 byte만을 읽기 위해서 실제로는 chunk 단위로 읽어 들여야 하다 보니 생각치 못한 오버헤드가 생긴다. 그래서 CPU가 자체적으로 이렇게 오버헤드가 생기지 않게 하기 위해서, Alignment check를 통해서 자체적으로 오버헤드를 줄일 수 있게 해 놓았다.(읽고자 하는 단위와, 주소를 통해서 Alignment를 체크한다.)

위에 테이블과 같이 해당 메모리는 접근 할 때, 위에 표를 참조하여 Alignment를 체크하고 올바르지 않은 접근을 하게 되면 Alignment Fault를 발생시킨다.

• 메모리에 적재시켜주는데... 메모리 몇 번지에 로드시켜야 하는가?
• 커널 이미지는 누가 메모리에 로드시켜 주는가?