커널과 사용자 모드의 목적, 그리고 커널 모드와 사용자 모드 간의 전환이 어떻게 일어나는지 이해합니다. 그러나 커널 모드에서 발생하는 크래시는 디버그하기 어렵고 telnet (예 : here is an example)을 통해 연결하여 원격으로 수행해야한다고 많은 소식통이 말합니다.왜 커널 모드에서의 디버깅이 어렵습니까?
왜 디버깅하기가 어렵습니까? 커널 스레드 중 하나에 (커널) 디버거를 연결하고 일반적인 방법으로 사용할 수없는 이유는 무엇입니까?
커널 모드에서 충돌하면 디버거 자체 에서조차 데이터 구조 이 (가) 인 메모리에있는 모든 데이터가 손상 될 수 있습니다. 그 방탄을 만드는 것은 어렵습니다.
정상적인 디버깅에서는 디버거와 디버깅중인 두 개의 완전히 격리 된 프로세스가 있습니다. 그들은 평등하게 창조 된 "동료"입니다. 디버깅중인 프로세스는 디버거가 무엇을 하든지 관계없이 디버거를 만질 수 없습니다. 반면에 디버거는 모든 일반 사용자 프로세스에 항상 적용 가능한 고정적이고 예측 가능한 방식으로 디버깅되는 프로세스와 상호 작용할 수 있습니다.
예 : 로컬 디버깅의 경우 키보드 인터페이스를 디버그 하시겠습니까? 아니면 시리얼 포트를 통해 RS232 코드를 디버깅 하시겠습니까? 네트워크를 통해 NIC 드라이버 또는 네트워크 스택? 그 중 하나에 중단 점을 설정하면 디버거를 제어하는 장치에 액세스 할 수 없기 때문에 복구 할 수 없습니다. 최악의 경우, 어떻게 커널 디버거를 디버그하겠습니까? GDB를 사용하면 적어도 이론적으로 GDB 인스턴스를 GDB의 다른 인스턴스에 연결할 수 있습니다. 커널 공간에서는 사물을 중재 할 수있는 위의 층이 없기 때문에 불가능합니다.
커널을 대화식으로 (또는 로컬로) 디버깅 할 수 없습니다. 커널 자체가 모니터에 그림을 표시하는 경우에도 (적절한 디스플레이 드라이버와 통신하여) 그리고 그 이상을 담당하기 때문입니다. 나는 당신의 질문을 다른 방식으로 넣을 것이다 : 텔넷을 통해 연결하는 것보다 커널을 디버그하는 것이 더 쉬운가?
그 질문에 내 대답은 : 예, 그렇습니다. 적어도 가상화를 사용하여 X86/X64 아키텍처. 내 로컬 컴퓨터에서 디버깅 할 수있는 게스트 OS를 실행하기 위해 VirtualBox를 사용하고 있습니다. 또한 VirtualKD (http://virtualkd.sysprogs.org/)를 사용하여 디버깅 시스템 (호스트)과 VM간에 통신 속도를 크게 높입니다.
VirtualKD에는 게스트 Windows의 boot.ini를 수정하는 패키지가 포함되어 있으므로 Windows에서 표시되는 적절한 메뉴 항목을 선택하여 부팅 할 때 디버깅을 활성화 할 수 있습니다.
좋아, 나는 그것을 이해한다고 생각한다. 내가 잘못했다면 나를 바로 잡으십시오 : 그것은 커널 모드에서 실행중인 모든 프로세스가 동일한 주소 공간을 공유한다는 것을 의미합니까? 그리고 그것이 사실이라면 그 이유가 있습니까? – qdii
예 커널 주소 공간이 모든 프로세스에서 공유됩니다. linux 커널 용 일반 커널 코드 (특정 장치 용 드라이버가 아님)가 있으면 QEMU를 사용할 수 있습니다. QEMU에서 실행되는 소프트웨어에 gdb를 첨부 할 수 있으므로 gdb를 사용하는 사용자 코드와 같은 커널 코드를 단계별로 실행할 수 있습니다. 그러나 코드가 사용 가능한 에뮬레이션이없는 장치 드라이버와 같은 장치에만 해당되는 경우 소프트웨어가 실행되지 않습니다. – Saurabh
@ user420536 질문은 실제로 Linux 또는 아키텍처를 지정하지 않습니다. 매우 다른 경우가 있습니다. – Flexo