임 소스 레벨 디버거에서 작업 중. elf 형식의 디버그 정보 '단계별 실행'은 어떻게 구현 될 수 있습니까? 문제는 'Point1'에 있습니다. 어쨌든 다음 소스 행 (.debug_line 테이블에서 읽음)을 기다릴 수 있습니다.단계 이상 수행, dwarf
덕분에
if (a == 1)
x = 1; //Point1
else if (a == 2)
x = 1;
z = 1;
나는 완전히 질문을 이해 모르겠지만, GDB는 step 명령을 구현하는 방법을 당신을 알 수 있습니다.
컨트롤이 특정 컴파일 단위에 들어가면 GDB는 해당 CU의 디버깅 정보를 읽습니다. 특히, .debug_line 섹션의 CU 부분을 읽고 명령 주소를 소스 코드 위치에 매핑하는 테이블을 작성합니다.
step이 시작되면 GDB는 현재 PC의 소스 위치를 찾습니다. 그런 다음 소스 위치가 변경 될 때까지 매번 새로운 PC의 소스 위치를 찾는 기계 명령을 수행합니다. 원본 위치가 변경되면 step이 완료되었습니다. 그 변경된 경우
는 또한 프레임 ID —에게 스택 프레임의 기본 주소, 및 각 공정 후의 — 함수의 시작 주소, 수표를 계산한다. 그것이 있다면, 이는 우리가 재귀 호출로 들어 갔거나 돌아 왔음을 의미하며, step이 완료되었습니다. 이 기능은 동일한 소스 라인에 전적으로 정의되어 있기 때문에
int fact(n) { if (n > 0) { return n * fact(n-1); } else return 1; }
: 그것은, 프레임 ID뿐만 아니라 소스 위치를 확인하려면 다음 함수를 호출 단계별로 고려할 필요가 왜
은 참조하십시오 소스 라인이 변경 될 때까지 명령에 따라 스테핑하면 모든 재귀 호출을 중단하지 않고 단계별로 진행됩니다. 그러나 fact에 대한 새 호출을 입력하면 스택 프레임 기본 주소가 변경되어 중지해야 함을 나타냅니다. 이것은 우리에게 다음과 같은 동작을 제공합니다
fact (n=10) at recurse.c:4
(gdb) step
fact (n=9) at recurse.c:4
(gdb) step
fact (n=8) at recurse.c:4
GDB의 next 명령은 함수 호출을 인식하고 완료로 복귀시키는 적절한 로직이 일반 동작을 결합합니다. 이전처럼 호출이 실제로 원래 프레임으로 되돌아 왔는지 결정할 때 프레임 ID를 사용해야합니다. 다른 합병증이 있습니다.
DWARF에서 설명하는 함수의 인라인 인스턴스를 처리하는 방법에 대해서는 약간의 가치가 있습니다. 하지만이 질문에 대해서는 약간의 차이가 있습니다.
디버거 프로젝트를 시작한다면 실험을 중단하지 말고 오픈 소스 인 Apple의 진행중인 디버거 인 lldb을보고 싶습니다.