이전 블로그에서는 gdb가 coredump를 디버그 할 때 일반적으로 사용되는 몇 가지 명령과 위치 지정 방법을 3 가지 예제를 통해 소개했습니다. 이 콘텐츠에서는 gdb 디버깅 coredump의 원칙과 그 뒤에있는 몇 가지 사항을 살펴 보겠습니다.
Coredump 원리
1. 코어 덤프 소개
이전 블로그에서 coredump를 코어 덤프라고도 언급했는데, 실제로 실행중인 프로세스 중 메모리 스냅 샷입니다. 프로세스가 충돌하면 운영 체제가 비정상적인 명령을받은 후 프로세스가 충돌하기 전에 프로세스를 수행합니다. 메모리 스냅 샷은이 정보를 코어 덤프 파일 인 파일에 저장합니다.
이 파일은 프로세스의 메모리에 주소 정보, 레지스터 정보, 스택 호출 정보 등을 포함합니다.
프로세스 코어 덤프를 유발할 수있는 신호는 다음과 같습니다.
| 이름 |
기술 |
ANSI C POSIX.1 |
SVR4 4.3 + BSD |
기본 동작 |
| SIGABRT |
중단 (중단) |
. . |
. . |
코어에서 종료 |
| SIGBUS |
하드웨어 오작동 |
. |
. . |
코어에서 종료 |
| SIGEMT |
하드웨어 오작동 |
|
. . |
코어에서 종료 |
| SIGFPE |
산술 예외 |
. . |
. . |
코어에서 종료 |
| 봉인 |
잘못된 하드웨어 명령 |
. . |
. . |
코어에서 종료 |
| SIGIOT |
하드웨어 오작동 |
|
. . |
코어에서 종료 |
| SIGQUIT |
터미널 출구 |
. |
. . |
코어에서 종료 |
| SIGSEGV |
잘못된 저장소 액세스 |
. . |
. . |
코어에서 종료 |
| SIGSYS |
잘못된 시스템 호출 |
|
. . |
코어에서 종료 |
| SIGTRAP |
하드웨어 오작동 |
|
. . |
코어에서 종료 |
| SIGXCPU |
CPU 제한 초과 (setrlimit) |
|
. . |
코어에서 종료 |
| SIGXFSZ |
파일 길이 제한 (setrlimit) 초과 |
|
. . |
코어에서 종료 |
예를 들어, 가장 일반적인 segmentfault는 위의 SIGSEGV에 해당하며 이는 kill 명령 11에 해당하는 신호입니다.
위의 모든 신호는 kill 명령에 해당합니다.
2. Coredump 파일 형식
1) 파일 명령을 사용하여보기
root @ ubuntu : / var / core_log # 파일 core_DumpNewTest_1483768078_6527
core_DumpNewTest_1483768078_6527 : './DumpNewTest'의 ELF 32 비트 LSB 코어 파일 Intel 80386, 버전 1 (SYSV), SVR4 스타일
위와 같이 파일 명령을 통해이 파일이 코어 파일임을 알 수 있으며 동시에 어떤 프로세스가 생성되는지 알 수 있습니다.
2) readelf를 사용해보십시오
Readelf -h core * 코어 파일 유형이 다음과 같이 표시되어 있음을 알 수 있습니다.
다음은 ELF.h 헤더 파일의 정의입니다.
그림에 표시된대로 ELF 파일 유형을 식별하는 바이트가 있습니다.
위와 같이 ELF 형식에는 주로 4 가지 유형의 파일이 있습니다. Core 파일에 해당하는 e_type의 값은 4입니다.
3) 코어 파일의 내용보기
readelf-코어 *
objdump -t를 사용하여 확인하십시오.
objdump -t 코어 *
위와 같이 readelf 및 objdump를 통해 다른 ELF 형식 파일에 비해 코어 파일의 헤드 노드 정보가 훨씬 적고 심볼 테이블 정보 및 디버깅 정보가 없음을 알 수 있습니다.
그러나 스택 및 레지스터와 같은 정보뿐만 아니라 프로그램 이전의 로딩 주소 및 주소 오프셋을 기록합니다.
gdb의 원리
GDB는 세 부분으로 구성됩니다.
(1) 기존 CLI 인터페이스를 지원하는 것 외에도 mi 인터페이스 (ddd와 같은 도구에서 사용)도 지원합니다.
(2) GDB에서 읽을 심볼 처리 계층에서 심볼 처리 gdb ./debugme 이후 파일의 심볼 정보, 다음 원본 코드, 변수 / 함수 / 유형의 표시는 모두이 부분에서 수행됩니다 (라이브 프로세스없이 수행 할 수있는 모든 작업).
(3) 대상 시스템 처리. 실행 제어, 중단 점 설정, 1 단계 실행, 스택 분석 등의 작업이 모두이 부분에서 수행됩니다.
BFD는 여러 가지 방법으로 gdb에 대한 지원을 제공합니다.
실행 파일 및 코어 파일 식별
BFD는 a.out, coff 및 여러 변형을 포함하여 다양한 파일 유형을 식별합니다.
그뿐만 아니라 여러 종류의 코어 파일.
파일 섹션에 대한 액세스
BFD는 파일 헤더를 구문 분석하여 이름, 가상 주소, 크기,
파일에있는 모든 다양한 명명 된 섹션의 파일 위치 (예 : 텍스트
섹션 또는 데이터 섹션). gdb는 단순히 BFD를 호출하여 섹션 x를 읽거나 씁니다.
길이 z에 대한 바이트 오프셋 y에서.
전문 코어 파일 지원
BFD는 코어에 저장된 실패한 명령 이름을 판별하는 루틴을 제공합니다.
파일, 프로그램이 실패한 신호 및 코어 파일이 일치하는지 여부
(즉, 코어 덤프가 될 수 있음) 특정 실행 파일.
기호 정보 찾기
gdb는 BFD의 내부 인터페이스를 사용하여 기호를 찾을 위치를 결정합니다.
실행 파일 또는 기호 파일의 정보. BFD는 디버그 기호를 "이해"하지 못하기 때문에 gdb 자체는 기호 읽기를 처리하지만 gdb는
기호, 문자열 테이블 등을 찾기위한 BFD의 캐시 된 정보
위와 같이 gdb 공식 사용자 매뉴얼에서 gdb는 BFD를 통해 코어 파일을 인식하는 동시에 기존의 메커니즘을 통해 코어 파일의 프로그램 크래시 명령과 크래시 관련 신호를 결정한다고 명시되어 있습니다. BFD에서 제공하며 코어 파일이 실행 프로그램과 일치하는지 여부를 확인할 수 있습니다. BFD는 또한 gdb가 실행 파일의 기호 정보를 읽을 수있는 인터페이스 세트를 제공합니다.
위의 스크린 샷에 표시된대로 regset_from_core_section 인터페이스는 올바른 레지스터 정보를 읽고 구문 분석하는 기능을 제공합니다.
위와 같이 gdb는 BFD를 사용하여 자체적으로 일부 인터페이스를 캡슐화하고 구현하여 실행 파일과 함께 코어 파일 정보를 식별하고 읽을 수 있으며 코어 파일에서 호출 스택, 충돌 신호 및 명령을 읽을 수 있습니다. 정보 및 기타 콘텐츠 등록 그런 다음 실행 파일에서 일치하는 기호 정보를 찾으면 gdb가 코어 파일을 디버그 할 때 16 진수 대신 주소 및 주소 오프셋에 해당하는 기호를 볼 수 있습니다.
BFD에 대한 Gdb의 의존성
위의 GDB 공식 사용자 매뉴얼에 따르면 gdb는 BFD를 통해 코어 파일의 스택, 레지스터 및 기타 정보를 읽으므로이 관점에서 gdb는 bfd에 종속됩니다.
헤더 파일에서 :
헤더 파일 참조로 판단하면 gdb는 BFD 헤더 파일을 참조합니다. 그래서 저는 GDB가 BFD 라이브러리에 의존해야한다는 것을 이해할 수 있다고 생각합니다.
그러나 ldd를 통해 있지만 종속성이 표시되지 않습니다.
위의 스크린 샷에서 볼 수 있듯이 objudmp는 bfd에 종속되지만 gdb는 bfd의 종속성을 볼 수 없습니다. 무슨 일이야?
처음에는 gdb가 bfd에 간접적으로 의존한다고 생각했습니다 .gdb가 의존하는 모든 라이브러리를 ldd로 확인했지만 bfd에 의존하는 라이브러리는 없으며 간접 의존도 ldd를 통해 볼 수 있어야합니다. 이 문제는 오랫동안 문제가되었습니다. 마지막으로 gdb의 소스 디렉토리 구조를 살펴본 결과 gdb 소스 코드에 실제로 BFD가 있음을 발견했습니다. 즉, gdb에는 bfd가 직접 포함되어 있습니다.
위에 표시된대로 gdb 소스 코드에는 BFD의 완전한 구현을 포함하는 별도의 BFD 디렉토리가 있습니다. 따라서 gdb는 시스템의 bfd 라이브러리에 의존하지 않지만 bfd의 완전한 구현을 직접 포함합니다.
다음 그림은 gdb의 전체 구조입니다.
