2016-09-30 3 views
2

Apple에서 이러한 크래시 로그를 생성하고 내 스레드 0이 다운되었지만이 문제는 문제가 아닙니다. 이것은 일반적인 질문이며 충돌 분석에서 이러한 프로세서 레지스터 값을 어떻게 활용할 수 있는지 궁금합니다. 그들은 당신의 충돌을 조사하는 것을 어떻게 도울까요? 내 마음에 오는 유일한 것은 레지스터 중 하나가 rcx과 같은 NULL 포인터를 가지고 있다면 코드에서 가능한 null 포인터 디 레퍼런스에 대한 아이디어를 제공합니다. 올바른 가정입니까?충돌 보고서의 CPU 레지스터 주소는 분석에서 어떻게 유용합니까?

Thread 0 crashed with X86 Thread State (64-bit): 
    rax: 0x00000001046e17a0 rbx: 0x00000001043665f0 rcx: 0x0000000000000000 rdx: 0x00000001046e14f0 
    rdi: 0x00000001046e14e0 rsi: 0x00000001046314e8 rbp: 0x00007fff5b89f890 rsp: 0x00007fff5b89f7e0 
    r8: 0x00007fff686a7690 r9: 0x0000000000000250 r10: 0x00007fffa2478201 r11: 0x000000000009ea18 
    r12: 0x00000001046b11d8 r13: 0x00007fff686a75c8 r14: 0x00007fff686ae638 r15: 0x0000000000000000 
    rip: 0x00000001043601be rfl: 0x0000000000010206 cr2: 0x0000000000000060 

Logical CPU:  0 
Error Code:  0x00000004 
Trap Number:  14 
+0

그들은 모든 종류의 방식으로 도움을줍니다. 단순한 사실은 메모리 주소에 무엇이 있는지 또는 레지스터의 값이 무엇인지를 알 수 있다는 것입니다. –

+0

@ l' L' l' ls thats true 그러나 당신이 그것을 사용하는 방법은 무엇입니까? – PnotNP

답변

3

RIP (Instruction Pointer) 레지스터를 사용하여 어떤 기계 명령이 실패했는지 확인할 수 있습니다. GDB가 Mac OSx에서 작동하는지 확실하지 않지만 Linux에서 GDB (GNU Debugger)를 사용하여 어셈블리 명령어를 분석하여 오류를 생성 한 정확한 명령어를 찾을 수 있습니다. 또한 레지스터 RBP (프레임 포인터) 및 RSP (스택 포인터)는 메모리의 스택 맨 아래와 맨 위를 각각 가리 킵니다. 이 모든 것을 알면 크래시 당시의 스택과 크래시를 유발 한 명령을 정확히 볼 수 있습니다.

+0

OS X는 gdb를 사용하지만, 요즘에는 lldb가 표준입니다. –

+0

'-fomit-frame-pointer'는 몇 년 동안 디폴트 (32 비트 코드조차도)를 가지고 있습니다. 그래서 RBP는 프레임 포인터가 아니라 RBX 나 R12-R15와 같은 다른 레지스터입니다. 이런 종류의 스택 해제는 메타 데이터 ('.eh_frame' 섹션에서)와 스택 메모리의 내용을 필요로하기 때문에 코어 덤프가 있다면 얻을 수 있습니다. –

0

@nrabbit이 말한 것에 덧붙여 레지스터를 사용하여 코드의 호출 규칙을 알고있는 경우 함수에 대한 일부 인수 값과 함수 호출 결과를 이해할 수 있습니다 . Here are some examples of Intel calling conventions. 따라서 eax 레지스터는 일반적으로 32 비트 프로그램에서 함수 결과를 보유합니다 (예 :).

+0

함수 CALL 또는 RET 명령에서 크래시가 발생했음을 알고있는 경우에만. 함수 안에서, 레지스터는'eax'의 최종 수정이 반환 값을 생성 할 때까지 임시 스크래치 공간입니다. 함수는 arg 레지스터도 수정합니다. 따라서 C 변수가 무엇을 의미하는지 알아 내려면 충돌 위치에서 asm을 살펴 봐야합니다. ** RIP의 가치에 관한 코드를주의 깊게 보지 않고 말할 수있는 유용한 것은 없습니다. ** –