코어 덤프 노트 섹션

Question

manually generating a core dump file에 관한 나의 질문에 이어, 나는 그것에 잠수하고 더러운 손을 잡기로 결정했습니다.

기본 코어 덤프 구조를 빌드하고 죽은 프로그램의 메모리를 큰 LOAD 섹션의 코어 덤프에 다시 가져올 수 있습니다. GDB에서 디버깅 할 때, 내 변수가 문제가되지 않습니다. 여기 까다로운 부분이 있습니다. GDB에서 프로그램이 추락했을 때의 위치 정보를 가져 오는 방법은 무엇입니까?

코어 덤프의 노트 섹션에이 정보가 포함되어 있다는 것을 알고 있습니다 (다른 것들 중에서도 cpu 레지스터).

Notes at offset 0x000000f4 with length 0x000001e8: 
    Owner  Data size Description 
    CORE  0x00000090 NT_PRSTATUS (prstatus structure) 
    CORE  0x0000007c NT_PRPSINFO (prpsinfo structure) 
    CORE  0x000000a0 NT_AUXV (auxiliary vector) 

: 그 .REG 부분이 어떤 구조에서 매핑 된 데이터를 포함하는 것을 readelf 덕분에 파악

core.28339:  file format elf32-i386 

Sections: 
Idx Name   Size  VMA  LMA  File off Algn 
    0 note0   000001e8 00000000 00000000 000000f4 2**0 
        CONTENTS, READONLY 
    1 .reg/28339 00000044 00000000 00000000 00000150 2**2 
        CONTENTS 
    2 .reg   00000044 00000000 00000000 00000150 2**2 
       CONTENTS 
    3 .auxv   000000a0 00000000 00000000 0000023c 2**2 
       CONTENTS 
    4 load1a  00001000 08010000 00000000 00001000 2**12 
       CONTENTS, ALLOC, LOAD, READONLY, CODE 
    .. other load sections ... 

: 여기 objdump를 -h가 "진짜"코어 덤프를 위해 제공 무엇인가

메모 섹션이 어떻게 구성되어 있는지 안내해 줄 수 있습니까? 필자는 이러한 구조를 직접 파일에 쓰려고 시도했지만 작동하지 않았으며 여기에 뭔가 빠져 있습니다. 나는 Google Coredumper code을보고 약간의 비트를 썼지 만, 노트 섹션을 작성하는 것이 그렇게 간단하지 않으며 정확히 무엇이 포함되어 있으며 형식이 환영되는지에 대한 자세한 정보는 환영 받는다.

편집 # 1 : 1 코멘트 다음 나는 다음과 같이 내 엘프 파일을 구성해야 알아 낸

:

• 엘프 헤더 ElfW (Ehdr)
• 프로그램 헤더 (Ehdr.e_phnum times ElfW (Phdr)), 여기에서는 기본적으로 하나의 PT_NOTE와 하나의 PT_LOAD 헤더를 사용했습니다.
• 참고 섹션 :
  • 섹션의 헤더 (.n_descsz 긴) (긴 .n_namesz) (ElfW (Nhdr))
  • 섹션의 이름
  • 섹션의 데이터

  모든 내 프로그램의 메모리를 포함

프로그램 섹션 나는 3 개의 노트 레코드를 넣어야 할 것이다. 하나는 prstatus이고, 하나는 prpsinfo이고 다른 하나는 보조 벡터이다.

이것은 올바른 방법 인 것 같습니다. readelf은 제가 실제 코어 덤프와 비슷한 결과물을 제공합니다.

편집 # 2 : 올바른 구조를

을받은 후 지금 노트 기록을 구성하는 다른 구조에 어려움을 겪고 있어요.

다음

Note segment of 540 bytes at offset 0x74: 
    Owner   Data size Type 
    CORE     336 PRSTATUS 
    CORE     136 PRPSINFO 
    CORE     8 AUXV 
    NULL 

실제 코어 덤프에 동일한 명령을 실행할 때 내가 무엇을 얻을 : 여기

는 유럽 연합 (EU)-readelf를 실행하는 내 코어 덤프에을 --notes 때 내가 무엇을 얻을

Note segment of 488 bytes at offset 0xf4: 
    Owner   Data size Type 
    CORE     144 PRSTATUS 
    info.si_signo: 11, info.si_code: 0, info.si_errno: 0, cursig: 11 
    sigpend: <> 
    sighold: <> 
    pid: 28339, ppid: 41446, pgrp: 28339, sid: 41446 
    utime: 0.000000, stime: 0.000000, cutime: 0.000000, cstime: 0.000000 
    orig_eax: -1, fpvalid: 0 
    ebx:    -1 ecx:    0 edx:    0 
    esi:    0 edi:    0 ebp:  0xffb9fcbc 
    eax:    -1 eip:  0x08014b26 eflags: 0x00010286 
    esp:  0xffb9fcb4 
    ds: 0x002b es: 0x002b fs: 0x0000 gs: 0x0000 cs: 0x0023 ss: 0x002b 
    CORE     124 PRPSINFO 
    state: 0, sname: R, zomb: 0, nice: 0, flag: 0x00400400 
    uid: 9432, gid: 6246, pid: 28339, ppid: 41446, pgrp: 28339, sid: 41446 
    fname: pikeos_app, psargs: ./pikeos_app 
    CORE     160 AUXV 
    SYSINFO: 0xf7768420 
    SYSINFO_EHDR: 0xf7768000 
    HWCAP: 0xbfebfbff <fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe> 
    PAGESZ: 4096 
    CLKTCK: 100 
    PHDR: 0x8010034 
    PHENT: 32 
    PHNUM: 2 
    BASE: 0 
    FLAGS: 0 
    ENTRY: 0x80100be 
    UID: 9432 
    EUID: 9432 
    GID: 6246 
    EGID: 6246 
    SECURE: 0 
    RANDOM: 0xffb9ffab 
    EXECFN: 0xffba1feb 
    PLATFORM: 0xffb9ffbb 
    NULL 

누군가 내 메모 기록이 제대로 읽히지 않는 이유에 대한 단서가 있습니까? 잘못된 오프셋이 원인 일 수 있다고 생각했지만 레코드가 올바르게 나열되는 이유는 무엇입니까?

감사합니다.

Answer 1

메모 섹션이 어떻게 구성되어 있는지 안내해 줄 수 있습니까?

메모 섹션은 가변 크기 메모 레코드의 연결입니다. 각 노트 레코드는 ElfW(Nhdr) 구조로 시작하고 가변 길이의 이름 (길이가 .n_namesz, 패딩되어 디스크의 전체 크기가 4로 나눌 수 있음) 및 데이터 (길이가 .n_descsz, 이와 유사하게 패딩 됨)로 시작됩니다.

Answer 2

는 몇 가지 테스트 후이 정보를 찾는 사람을 위해 응답, 일을 알아 냈 :

수 있습니까 올바른 방법으로 내 엘프 파일이 방법을 구조화를 가고 사람의 확인?

예.

GDB가 파일을 수락하기 때문에 올바른 방법 일 것 같습니다. 에 표시된 결과 readelf -a 올바른 구조, 좋은 지금까지 보여줍니다.

나는 데이터를 배치해야하는 위치에 대해 확실하지 오전 내 파일에 (& 프로그램 섹션을주의) : 필수 순서가, 또는이 내 프로그램 헤더는 데이터가 어디에 정의 오프셋?

Phdr.p_offset에 제공된 오프셋은 데이터가 Elf 파일에있는 위치를 가리켜 야합니다. 그들은 파일의 맨 처음부터 시작합니다. 예를 들어

는 :

PT_NOTE 프로그램 헤더의 p_offset는 sizeof(ElfW(Ehdr)) + ehdr.e_phnum*sizeof(ElfW(Phdr))로 설정되어야한다. ehdr.e_phnum은 Elf 파일에있는 프로그램 헤더의 수입니다.

PT_LOAD 프로그램 헤더의 경우 약간 더 길기 때문에 메모 섹션의 길이도 추가해야합니다. 메모의 세그먼트가 PT_LOAD 데이터 (Phdr.p_offset) 오프셋 NT_PRSTATUS, NT_PRPSINFO 및 NT_AUXV 섹션을 containg와 "표준"코어 덤프 들어있을 것입니다 :

sizeof(ElfW(Ehdr)) + ehdr.e_phnum*sizeof(ElfW(Phdr)) 
+ sizeof(ElfW(Nhdr)) + sizeof(name_of_section) + sizeof(struct prstatus) 
+ sizeof(ElfW(Nhdr)) + sizeof(name_of_section) + sizeof(struct prpsinfo) 
+ sizeof(ElfW(Nhdr)) + sizeof(name_of_section) + sizeof(struct auxv_t) 

Answer 3

이 CRIU 변환 내 프로젝트 전 같은 문제 몇 시간을 보내고 되었습니까 이미지를 코어 덤프로 Python으로 완벽하게 작성되었으므로 (elf 구조체도 ctypes에 있음),이를 지침으로 사용할 수 있습니다. https://github.com/efiop/criu-coredump을 참조하십시오.모든 것이 어떻게 구성되어 있는지 여기에서 볼 수 있습니다 https://github.com/efiop/criu-coredump/blob/master/criu_coredump/core_dump.py.