gdb - 실제 메모리 덤프 파일이있는 커널 디버깅

Question

실제 메모리 덤프 파일과 심볼 파일 (vmlinux)이 있습니다. gdb의 심볼 파일로 덤프 파일의 내용을 분석하고 싶습니다. 예를 들어, 실제 메모리 덤프 그 시간에 init_task의 상태를 들여다 :

(gdb) print &init_task 
=> show the address of init_task in physical memory dump file, said 0xc0XXXXXX 

(gdb) print ((struct task_struct *) 0xc0XXXXXX)->tasks 
=> show the content of init_task.tasks in physical memory dump file) 

난 그냥 "복원"과 "목표의 핵심"명령 gdb를 시도, 모두가 작동되지 않습니다. "복원"은 실행중인 프로세스에서 사용해야하고 "대상 코어"는 코어 파일 (ELF 64 비트 LSB 코어 파일)에서 입력해야합니다.

(gdb) restore binary physical-memory-dump-file 
You can't do that without a process to debug. 

(gdb) target core physical-memory-dump-file 
"physical-memory-dump-file" is not a core dump: File format not recognized 

아이디어가 있으십니까? 감사.

업데이트 1 : 안녕하세요 Pavan, 상기시켜 주셔서 감사합니다; 특별한 플랫폼에서 작업하고 있기 때문에 부트 로더를 사용하면 커널을 재부팅 한 후 전체 물리적 메모리를 덤프 파일로 저장할 수 있습니다. 따라서 실제 메모리 덤프 파일은 실제 RAM과 동일한 크기를 가지며 커널의 첫 번째 바이트부터 0xc000 : 0000에 매핑 될 수 있습니다.

Answer 1

실제 메모리 덤프와 코어 파일은 완전히 똑같은 것은 아닙니다. 코어 파일은 주소 공간에 매핑되는 실행 가능 이미지 일뿐입니다. 커널이 패닉 상태가되면 이미지의 다른 부분을 가리키는 하드 코딩 된 주소로 메모리의 일부 위치에 ELF 파일을 남겨 두어야합니다. GDB가 그것을 받아 들여 가지고있는 기호와 일치시키기 전에 당신이 가지고있는 메모리 덤프로부터 ELF 이미지를 추출해야 할 것입니다.