source

GDB: 크래시된 프로세스의 모든 매핑 메모리 영역 목록 표시

gigabyte 2022. 8. 29. 22:15
반응형

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

반응형