GDB: 크래시된 프로세스의 모든 매핑 메모리 영역 목록 표시
GDB에서 디버깅하려고 하는 x86 Linux 머신(중요한 경우에는 커널 2.6.35-22)의 데드 프로세스에서 풀히프 코어 덤프를 취득했습니다.
이 프로세스에 의해 할당된 모든 메모리주소 영역의 목록을 표시하다GDB 명령어가 있나요?즉, 이 덤프에서 검사할 수 있는 모든 유효한 메모리주소를 알 수 있을까요?
질문하는 이유는 프로세스 힙 전체에서 특정 바이너리 문자열을 검색해야 하며find
명령어, 시작 주소와 끝 주소가 필요합니다.0x00부터 0xff까지 검색만 하면 됩니다.동작하지 않는 이유는find
는, 액세스 할 수 없는 주소를 발견하면 즉시 정지합니다.
(gdb) /w 0x440000, 0xff0000, 0x12345678을 찾습니다.
경고:0x105ef883에서 대상 메모리에 액세스할 수 없습니다. 검색을 중지합니다.
그래서 메모리에서 읽을 수 있는 모든 주소 영역의 목록을 가져와 한 번에 하나씩 검색할 수 있어야 합니다.
(이것이 필요한 이유는, 메모리내의 특정의 주소를 가리키는 모든 구조를 찾을 필요가 있기 때문입니다.
어느 것도show mem
,show proc
,info mem
,info proc
내가 필요한 걸 하는 것 같아
GDB 7.2의 경우:
(gdb) help info proc
Show /proc process information about any running process.
Specify any process id, or use the program being debugged by default.
Specify any of the following keywords for detailed info:
mappings -- list of mapped memory regions.
stat -- list a bunch of random process info.
status -- list a different bunch of random process info.
all -- list all available /proc info.
너는 원한다info proc mappings
단, 이 기능이 없는 경우는 동작하지 않습니다./proc
(예를 들어 pos-mortem 디버깅 중).
해라maintenance info sections
대신.
(gdb) maintenance info sections
Exec file:
`/path/to/app.out', file type elf32-littlearm.
0x0000->0x0360 at 0x00008000: .intvecs ALLOC LOAD READONLY DATA HAS_CONTENTS
이것은 위의 phihag의 코멘트에서 나온 것으로, 다른 답변을 받을 가치가 있습니다.이게 먹히 되는데info proc
는 gcc-arm-none-eabi Ubuntu 패키지의 arm-none-eabi-gdb v7.4.1.20130913-cvs에서는 지원되지 않습니다.
프로그램 및 코어 파일이 있는 경우 다음 단계를 수행할 수 있습니다.
1) 코어 파일과 함께 프로그램에서 gdb를 실행합니다.
$gdb ./test core
2) info 파일을 입력하고 코어 파일에 어떤 세그먼트가 있는지 확인합니다.
(gdb)info files
출력 예:
(gdb)info files
Symbols from "/home/emntech/debugging/test".
Local core dump file:
`/home/emntech/debugging/core', file type elf32-i386.
0x0055f000 - 0x0055f000 is load1
0x0057b000 - 0x0057c000 is load2
0x0057c000 - 0x0057d000 is load3
0x00746000 - 0x00747000 is load4
0x00c86000 - 0x00c86000 is load5
0x00de0000 - 0x00de0000 is load6
0x00de1000 - 0x00de3000 is load7
0x00de3000 - 0x00de4000 is load8
0x00de4000 - 0x00de7000 is load9
0x08048000 - 0x08048000 is load10
0x08049000 - 0x0804a000 is load11
0x0804a000 - 0x0804b000 is load12
0xb77b9000 - 0xb77ba000 is load13
0xb77cc000 - 0xb77ce000 is load14
0xbf91d000 - 0xbf93f000 is load15
저 같은 경우에는 15개의 세그먼트가 있습니다.각 세그먼트에는 주소의 시작과 끝의 주소가 있습니다.데이터를 검색할 세그먼트를 선택합니다.예를 들어 load11을 선택하고 패턴을 검색합니다.Load11의 시작 주소는 0x08049000이고 끝은 0x804a000입니다.
3) 세그먼트내의 패턴을 검색합니다.
(gdb) find /w 0x08049000 0x0804a000 0x8048034
0x804903c
0x8049040
2 patterns found
실행 파일이 없는 경우 코어 파일의 모든 세그먼트의 데이터를 인쇄하는 프로그램을 사용해야 합니다.그런 다음 주소에서 특정 데이터를 검색할 수 있습니다.그런 프로그램을 찾을 수 없습니다.코어 또는 실행 파일의 모든 세그먼트의 데이터를 출력하는 다음 링크에서 프로그램을 사용할 수 있습니다.
http://emntech.com/programs/printseg.c
이 경우에도 하실 수 있습니다.info files
프로세스 바이너리로 로드된 모든 바이너리의 모든 섹션을 나열합니다.
저는 방금 다음을 보았습니다.
set mem inaccessible-by-default [on|off]
메모리 액세스 가능 여부에 관계없이 검색할 수 있습니다.
maintenance info sections
명령어가 바이너리의 섹션 헤더에서 정보를 추출하려고 합니다.트립되어 를 들어, 「」에 의해서)는하지 않습니다.sstrip
「」의 ).RELRO
를 참조해 주세요.
언급URL : https://stackoverflow.com/questions/5691193/gdb-listing-all-mapped-memory-regions-for-a-crashed-process
'source' 카테고리의 다른 글
Vuejs 2 @click.middle이 작동하지 않음 (0) | 2022.08.29 |
---|---|
json 데이터에서 VueJs를 사용하여 목록 요소를 렌더링하는 방법 (0) | 2022.08.29 |
HashMap에서 삽입 순서를 유지하는 방법 (0) | 2022.08.29 |
vue에서 created() 메서드를 사용하는 경우 (0) | 2022.08.29 |
C 컴파일러는 연속된 할당을 휘발성 변수에 병합할 수 있습니까? (0) | 2022.08.29 |