YJcode :: YJcode

커널은 기본적으로 유저가 사용하기에 적절한 사용자 모드와, 커널을 직접 수정 혹은, 중요한 파일에 접근할 수 있는 커널 모드가 존재한다.

 

커널 모드에서는 모든 파일에 대한 접근이 가능하지만 사용자 모드에서는 제한된 권한을 가지고 허용된 파일만 보거나 쓸 수 있다.

 

굳이 사용자 모드를 별도로 두고 관리하는 이유는 무엇일까? 여러 이유가 있지만 아래에 2가지 대표적인 이유를 들겠다.

 

  • 보안 측면에서 권한을 제한하는 것은 정말 중요하다. 만약 컴퓨터를 부팅하고, 유저 인터페이스가 돌아가는 순간부터 모든 권한이 오픈되어 있다고 생각해보자. 해커들에게는 이보다 더한 천국이 있을 수가 없다. 왜냐하면, 모든 권한이 오픈되어 있다는 것은 달리 말하면 누군가가 원격이든, 직접적으로든, 특정 컴퓨터에 접근만 할 수 있다면, 바이러스를 여기저기 심어 두고, 중요한 개인정보를 아무 때나, 어디서나 뽑아가는 게 가능해지기 때문이다.
  • 건드리면 위험한 파일을 따로 관리할 수 있다. 커널 모드에서는 모든 파일에 대한 권한을, 유저 모드에서는 잘못 건드려서 망가져도 운영체제를 실행하는 데는 문제없는(ex. 부팅을 관장하는 부트로더와 같은 파일이 아닌 메모장과 같은 일반 파일) 파일들에 대한 접근만 허용한다면, 컴퓨터를 만질 때마다 차후 부팅이 실패할까 걱정할 필요가 없어진다. 잘못 건드리면 심각한 문제가 발생할 여지가 있는 파일 또는 프로그램에 대한 접근을 차단하여, 우발적인 시스템 손상을 방지하는 것이다.

 

리눅스뿐만 아니라 윈도우도 사실 이러한 모드의 구분을 하고 있다. windows10을 보면, 무엇인가 새로운 프로그램을 설치하려고 할 때 관리자 모드로 실행하겠냐고 묻는 대화 상자가 뜨는 것을 볼 수 있을 것이다.

이 또한 해당 프로그램 설치를 위해서 민감한 영역을 건드리고, 필요에 따라서 백그라운드로 프로그램을 실행하는 등 보안과 밀접하게 연관된 권한을 얻어야 한다는 이유에서 권한을 상승해서 커널 모드(관리자모드)로 프로그램을 설치하겠냐고 묻는 것이다.

게다가 지금에 와서는 윈도우나 리눅스 모드 멀티유저 환경을 제공하여 주고 있다.

한 컴퓨터에 여러 유저(계정)를 만들어 두고 각각의 계정으로 접속할 때 각기 다른 화면을 보여줌으로써 컴퓨터를 공유해서 사용하여야 하는 상황이 발생했을 때 조금 더 독립적인 환경을 구성할 수 있게 되는 것이다.

커널은 컴퓨터를 구동하는 핵심 운영체제를 의미하고 운영체제는 보통 2가지의 관점으로 쓰인다.

 

 

  • 컴퓨터 지원을 관리하는 핵심 소프트웨어와 인터프리터, GUI(그래픽 유저 인터페이스), 파일 유틸리티 시스템, 편집기 같은 기본적인 소프트웨어 도구를 아우르는 통합 패키지
  • CPU, RAM, 디바이스와 같은 컴퓨터의 하드웨어 자원을 관리하고 할당하는 핵심 소프트웨어

 

이중 보통은 핵심소프트웨어만을 커널로 보는 관점이 많은데 그 이유는 커널의 가장 큰 존재의의가 보다 효율적인 컴퓨터 하드웨어 자원의 관리를 통한 보다 편한 소프트웨어 구성, 보다편한 소프트웨어 사용, 그리고 한정된 자원에서 보다 확실하고 정확한 컴퓨터 하드웨어 자원을 관리할수 있는 관리자의 역할이기 때문이다.

 

커널은 기본적으로 몇가지의 작업을 수행하는 것이 보편적이다.

 

 

  • 메모리 관리 : 여러 프로세스를 동시에 구동하여야 하는 경우 커널은 이 프로세스들을 구동하기 위해 메모리를 할당하고 관리하여야 한다. 하지만 메모리의 하드웨어적 제원은 항상 제한되어 있고 이 제한된 메모리를 여러 프로세스에 동시에 할당하기에는 부족한 경우 커널이 적극 개입하여 메모리를 적절한 시기에 각각의 프로세스에 할당하여 준다.
  • 프로세스 스케줄링 : 리눅스는 선점형 멀티태스킹을 기반으로 하고있다. 그렇기 때문에 프로세스 들이 멀티태스킹을 할 때 커널이 프로세스에 대한 스케줄을 제어하지 않으면 각각의 프로세스에 대한 공정한, 효율적인 CPU 할당이 불가능하다. 그렇기에 커널은 메모리에 올라와 있는 프로세스에 대한 CPU사용 우선순위와 같은 스케줄을 관리한다.
  • 디바이스 드라이버 제공 : 컴퓨터는 본체 뿐만이 아니라 모니터, 키보드, 마우스와 같은 많은 외부장치가 부착되어 있다. 하지만 이들 외부장치는 각각의 고유한 사용방법이 있으며, 이러한 사용방법을 컴퓨터 본체가 모르고, 제공하기 않는다면 외부장치들은 사용할 수가 없게된다. 이러한 사용방법을 명시해놓은 표준화된 사용설명서(인터페이스)를 디바이스 드라이버라고 생각하면 좋다.(주의 : 여기서 말하는 사용설명서는 사용자가 아닌 컴퓨터를 위한 설명서이다.) 이러한 디바이스 드라이버를 제공하여 주는 것이 커널이고, 커널이 인식하지 못하는 디바이스의 경우는 유저가 직접 해당 디바이스의 드라이버를 설치하여 줌으로써 커널이 디바이스를 인지하고 제어할수 있도록 하여 준다.
  • 프로세스 생성, 종료 : 운영체제가 있는 컴퓨터 환경에서 메모리 관리나 프로세스 스케줄링을 커널이 직접 관장하고 있기 때문에 새로운 프로세스가 실행될 때, 해당 프로세스 입장에서는 메모리의 어느부분에 올라가야 다른 프로세스의 영역을 침범하지 않는지 알 수있는 방법이 없다. 마찬가지로 프로세스가 종료될때도 스스로가 종료가 되면 다른 프로세스에게 자신이 종료되었음을 알려줄 방법이 없다. 다른 프로세스를 실행할 프로세스가 살펴보고, 마찬가지로 종료직전 자신이 종료될 것을 다른 프로세스에게 알려주면 되지 않느냐고 생각할 수도 있지만 다른 프로세스들을 살펴볼수 있게 되면 보안에 치명적인 구멍이 생기게 되고, 종료될 것을 다른프로세스에게 종료직전 알려주고 미처 스스로 종료하기도 전에 다른 프로세스가 아직 종료되지 않은 메모리 영역을 침범하게 되면 비정상 동작을 하는 등의 치명적인 오류가 발생할 수도 있다. 그렇기 때문에 이러한 프로세스의 생성과 종료는 커널이 관장하여야 한다. 여기까지만 봐도 커널이 하는 역할은 사용자가 실제로 사용할 프로세스의 관리, 매니징 역할 이라는 것을 알 수 있다.
  • 파일 유틸리티 시스템 제공 : 우리가 흔히 알고있는 파일 탐색기에 해당한다. 이것은 특정 프로그램이 관여하는 것이 아니라 커널에서 자체적으로 제공한다. 만약 파일 시스템이 커널레벨이 아닌 유저레벨에서 관리된다면, 파일 시스템을 삭제하는 순간 해당 파일 시스템에서 관리하던 파일에 대한 노드정보 소실로 의도하지 않은 파일손상을 불러오거나, 여러 파일시스템을 설치하였을때 서로간에 동일한 파일구조를 보여줄 수 없는등의 문제가 발생할 수있다. 그렇기 때문에 파일 유틸리티 시스템은 커널에서 직접 관리(EX.파일 검색, 생성, 삭제, 수정 등의 기능 관리 및 제공)하고 있다.
  • 네트워크 : 컴퓨터에 없어서는 안될 것이 네트워크이다. 지금 이 글을 보고 있는 이라면 OSI 7계층은 들어 보았을 것이다. 이것을 만약 구현하고자 하는 프로그래머가 일일이 전부 구현하여야 한다면 어떻겠는가? 아마 간단한 프로그램 하나를 만들기 위해 엄청난 시간과 자원을 투자하여야 할 것이다. 그렇기에 보통 네트워크 통신을 구현할 때 프로그래머가 구현하는 부분은 사실상 이 OSI 7계층의 각각 계층에서 무엇을 어떻게 작업하여 어떤 정보를 보내줄지 설계해주는 것이 다이고, 물리적인, 혹은 LOW LEVEL에서의 논리적인 기능은 커널이 관장하는 경우가 대부분이다.이러한 구조를 이용하면 프로그래머는 정해진 규칙대로 사용법만 명시하여주고, 커널은 이미 정해진 방법을 기반으로 이를 대신 처리하여 주는 방식으로 통신을 하게 되며, 정형화된 통신이 가능해지므로 더욱 정확하고 간단한 프로그래밍이 가능하게 된다.
  • 시스템 호출 API 제공 : 프로세스 입장에서는 필요한 기능이나, 보안과 같은 문제 때문에 프로세스 자체적으로는 실행 할 수 없는 기능들이 있다. 대표적인 것이 디바이스 드라이버, 특정 파일 열람과 같은 것들이다. 이러한 것들은 직접적인 접근은 커널에서만 접근을 할 수 있는데, 프로세스가 해당 정보를 필요로 할때는 커널에게 이러한 정보가 필요하니 알려달라고 요청, 혹은 이러한 정보를 적용해야 하니 적용을 해달라고 요청하게 된다. 이럴 경우 커널은 해당 정보를 받은 후 권한과 같은 적정석을 검토 후 실행을 하게 된다. 여기서 컴퓨터는 사람과 달리 의미가 비슷하면 알아서 이해하는 것이 아니라 정확한 요청 형식이 있어야 한다. 이는 컴퓨터가 의미를 통한 의사전달이 아니라 데이터에 의한 의사전달이 이루어지기 때문에 요청 형식에 있어서 조금의 차이만 있어도 다른 의미로 해석을 하기 때문이다. 그래서 커널이 제공할 수있는 수행기능에 대한 인터페이스가 있어야 하는데 그것이 API이다. 시스템 호출 API가 있음으로 유저레벨 프로세스가 더욱 자세하고 효율적인 기능을 수행할 수 있게 되었다. 

 

위의 기능들은 리눅스관점에서의 기능이나 대부분의 커널들이 이와 비슷한 맥락으로 동작하므로 커널 그 자체의 기능이라고 봐도 무방할 것이다.

오늘은 저번시간에 진행하였던 VScode기반 C,C++ 컴파일환경 구현에 이어 디버깅 환경을 구현하도록 하겠습니다.


만약 VScode에서 C,C++ 컴파일 환경을 구현하지 않았다면 다음 링크를 통해 먼저 컴파일 환경을 구현 후 오시기 바랍니다.


2018/12/26 - [C언어/C언어 개발환경 구축] - 우분투 리눅스에서 VScode설치, C,C++코딩을 위한 환경설정하기



컴파일 환경까지 구현하셨다면 이제 디버깅을 구현하여야 하는데요, 디버깅이 무엇인지 왜 필요한지 모르신다면 "나중을 위해 환경을 설정해둔다."

이정도로만 알고 따라하셔도 무방합니다.


1. 컴파일 환경 구현때 설정한 task.json 파일을 일부 수정한다.

-- 컴파일환경을 제 블로그를 참고하여 구현하셨다면 파일탐색창에서 .VScode폴더안에 tasks.json 파일이 생성되어 있고 위 스크린샷과 같이 설정이 되어 있을 겁니다.


하지만 자세히 살펴보면 마냥 같지는 않고 조금 다른점을 볼 수 있는데요.

//C++ 컴파일
{
"label": "save and compile for C++",
"command": "g++",
"args": [
"-g3",
"${file}",
"-o",
"${fileDirname}/${fileBasenameNoExtension}"
],
"group": "build",

이부분과

//C 컴파일
{
"label": "save and compile for C",
"command": "gcc",
"args": [
"-g3",
"${file}",
"-o",
"${fileDirname}/${fileBasenameNoExtension}"
],
"group": "build",

이부분이 조금 다를 겁니다.

디버깅을 위해서는 컴파일을 실행할 당시에 디버깅 정보를 포함하여 주어야 하는데요, 이 컴파일정보를 포함하는 옵션을 g++과 gcc에 추가로 주기 위하여


"-g3"


이걸 "args": [ 

"이부분에 삽입합니다.",

"${file}",

"-o",

...

이런 형식으로 추가하여 주어야 합니다.

만약 찾아서 직접 수정하기 힘드시다면 그냥 아래 코드를 통째로 복사하셔서 tasks.json파일에 덮어쓰셔도 상관없습니다.

{
"version": "2.0.0",
"runner": "terminal",
"type": "shell",
"echoCommand": true,
"presentation" : { "reveal": "always" },
"tasks": [
//C++ 컴파일
{
"label": "save and compile for C++",
"command": "g++",
"args": [
"-g3",
"${file}",
"-o",
"${fileDirname}/${fileBasenameNoExtension}"
],
"group": "build",



"problemMatcher": {
"fileLocation": [
"relative",
"${workspaceRoot}"
],
"pattern": {
"regexp": "^(.*):(\\d+):(\\d+):\\s+(warning error):\\s+(.*)$",
"file": 1,
"line": 2,
"column": 3,
"severity": 4,
"message": 5
}
}
},
//C 컴파일
{
"label": "save and compile for C",
"command": "gcc",
"args": [
"-g3",
"${file}",
"-o",
"${fileDirname}/${fileBasenameNoExtension}"
],
"group": "build",



"problemMatcher": {
"fileLocation": [
"relative",
"${workspaceRoot}"
],
"pattern": {
"regexp": "^(.*):(\\d+):(\\d+):\\s+(warning error):\\s+(.*)$",
"file": 1,
"line": 2,
"column": 3,
"severity": 4,
"message": 5
}
}
},

{

"label": "execute",

"command": "cd ${fileDirname} && ./${fileBasenameNoExtension}",

"group": "test"

}
]
}


코드 작성이 끝나셨으면 Ctrl + S 키를 통해 저장을 하시고,


2. 위와같이 Ctrl + Shift + D 혹은 왼쪽상단의 거미모양 아이콘을 눌러서 디버그 모드로 들어갑니다.



여기서 좌측상단에 보면 초록색 재생버튼이 보입니다. 이걸 클릭해주면 위 사진처럼 어떤 디버그 환경을 구현할지 설정하는 화면이 나옵니다. 여기서는 C와 C++을 디버깅 할 것이므로 해당하는 디버거인 GDB/LLDB 를 선택합니다.


여기까지 진행하면,



위 스크린 샷 처럼 launch.json 이 생성됩니다.


만약 코드가 아래와 같다면 그대로 두셔도 상관 없습니다만, 만약 다르다면 아래코드를 launch.json 내용물에 그대로 덮어쓰시면 됩니다.

{
"version": "0.2.0",
"configurations": [
{
"name": "(gdb) Launch",
"type": "cppdbg",
"request": "launch",
"program": "${fileDirname}/${fileBasenameNoExtension}",
"args": [],
"stopAtEntry": false,
"cwd": "${workspaceFolder}",
"environment": [],
"externalConsole": false,
"MIMode": "gdb",
"setupCommands": [
{
"description": "Enable pretty-printing for gdb",
"text": "-enable-pretty-printing",
"ignoreFailures": true
}
]
}
]
}


사실 여기까지 하셨다면 디버깅환경 구현은 끝난 셈입니다. 한번 확인해볼까요?


#include <stdio.h>

int main() {

int a = 0, b = 0;

a = 10;
b = 20;

printf("%d\t%d\n",a,b);
}


3. 제일먼저 위 코드를 샘플파일로 아래와 같이 파일을 하나 만들고 입력합니다.



여기서 코드를 작성한 내용물 왼쪽에 보면 행(라인)마다 숫자가 붙어 있는 것이 보일 겁니다.

그 왼쪽에 마우스 커서를 올리면,



이렇게 빨간 동그라미가 희미하게 나타납니다. 이걸 클릭해주면 동그라미 색이 진하게 나타나고 마우스 커서를 치워도 그대로 남아있게 됩니다.

이걸 브레이크포인트 라고 부릅니다.

디버깅 환경에서 테스트를 할 때 정지해서 그때 그때 변수값이나 상태를 체크하는 지점을 설정해주는 것입니다.


4. 저는 아래와같이 4개의 브레이크포인트를 생성하였습니다.



이제 컴파일을 진행하여 주세요. 컴파일을 어떻게 해야 할 지 모르신다면 상단에 있는 링크를 통해 전에 포스팅한 컴파일 방법을 다시한번 살펴보시기 바랍니다.



위 사진처럼 정상적으로 컴파일이 되지 않고 에러 메시지가 뜬다면 launch.json 파일과 task.json 파일 수정부분을 다시한번 찬찬히 읽어보시기 바랍니다.


여기까지 진행이 완료되었다면 디버깅을 진행하는데요, 디버깅은 저번 포스팅에서 설정한 실행 커멘드를 통해서 실행하지 않고 


1.F5 키를 누르거나,

2.Ctrl + Shift + D 혹은 왼쪽 상단의 거미모양 아이콘 선택 후 위쪽에 초록색 재생버튼 클릭


이 두가지 방법을 이용해서 실행이 가능합니다.


그럼 아래같은 화면이 나옵니다.



이제 상단에 새로 생긴 디버그컨트롤러 창을 통해 아래처럼 브레이크포인트를 한번씩 이동하며 변수의 변화를 볼 수 있고,

 조사식이나 스택상태등 상당히 강력한 디버깅을 할 수 있게 되었습니다.



여기까지 따라오시느라 고생이 많으셨습니다. 다음시간부터는 본격적으로 C언어를 탐구하여 보도록 하겠습니다.

+ Recent posts