스테핑(디버깅)
Stepping (debugging) |
프로그램 애니메이션 또는 스테핑은 코드 1개의 명령 또는 행을 한 번에 실행하는 디버깅 방법을 말합니다.프로그래머는 특정 코드 라인의 실행 전후에 프로그램, 기계 및 관련 데이터의 상태를 검사할 수 있습니다.이를 통해 프로그래머는 각 문이나 명령의 효과를 독립적으로 평가할 수 있으며, 따라서 실행 중인 프로그램의 동작(또는 잘못된 동작)에 대한 통찰력을 얻을 수 있습니다.거의 모든 최신 IDE 및 디버거는 이 실행 모드를 지원합니다.
역사
명령 스테핑 또는 싱글 사이클은 원래 프로세서 클럭을 정지하고 한 번에 1 사이클씩 수동으로 진행하는 기술을 말합니다.그러기 위해서는 다음 3가지가 필요합니다.
- 클럭을 정지할 수 있는 컨트롤(예: "Stop" 버튼)
- 정지된 클럭을 한 사이클씩 수동으로 진행할 수 있는 두 번째 컨트롤(예: "지시 단계" 스위치 및 "시작" 버튼)
- 각 사이클 후에 프로세서의 상태를 기록하는 몇 가지 방법(예: 레지스터 및 메모리 디스플레이).
1964년에 발표된 IBM System 360 프로세서 제품군에서 이러한 시설은 전면 패널 스위치, 버튼 및 네온 램프 뱅크에 의해 제공되었습니다.PDP-11과 같은 다른 시스템에서도 유사한 설비가 제공되었습니다.
물리적으로 클럭의 정지를 지원하지 않고 내부 상태가 너무 많아 패널에 표시할 수 없는 새로운 프로세서에서는 트랩 플래그를 통해 동일한 기능이 제공될 수 있습니다.트랩 플래그를 활성화하면 각 명령 후에 프로세서가 중단점과 동일하게 정지하도록 지시됩니다.
멀티프로세싱이 보편화됨에 따라, 많은 독립적인 프로세스가 동시에 중단되기 때문에 이러한 기법은 실용성에 한계가 있을 것입니다.이로 인해 유사한 기능을 제공하지만 특정 주소 공간 및 스레드에 대한 특정 애플리케이션 프로그램으로의 브레이크 포인트 및 명령 스텝을 의도적으로 제한한 여러 독립 벤더로부터 독점 소프트웨어를 개발하게 되었습니다.프로그램 상태(선택한 응용 프로그램/스레드에 적용 가능한 경우)는 각 단계에서 검사를 위해 저장되었다가 다시 시작하기 전에 복원되어 단일 사용자 환경처럼 느껴졌습니다.이것은 보통 애플리케이션 층의 문제를 진단하는 데 충분합니다.
물리적인 정지 버튼을 사용하여 실행을 일시 정지하는 대신 애플리케이션 프로그램을 단계별로 진행하려면 브레이크 포인트 또는 "일시정지" 요청을 사전에 설정해야 합니다(일반적으로 프로그램의 특정 문/지시에 미리 또는 기본적으로 첫 번째 지시에서 선택).
프로그램의 전체 화면 "화면"을 제공하려면 일반적으로 비디오 모니터와 같은 적절한 I/O 장치가 필요합니다. 이 장치는 코드의 합리적인 부분(예: 분해된 기계 코드 또는 소스 코드 형식)을 표시하고 현재 명령 또는 소스 코드 행에 대한 포인터(예: <==)를 제공할 수 있습니다.이러한 이유로 메인프레임 세계에서 이러한 풀스크린 애니메이터의 광범위한 사용은 1970년대 초 CICS와 같은 트랜잭션 처리 시스템의 도래를 기다려야 했으며 처음에는 해당 환경에서 작동하는 애플리케이션 프로그램의 디버깅으로 제한되었습니다.같은 제품의 최신 버전에서는 배치 프로그램 및 기타 운영 체제 및 플랫폼의 지역 간 감시/디버깅이 제공되었습니다.
1980년 경부터 퍼스널컴퓨터가 등장하면서 통합 디버거는 이 단일 사용자 도메인에 더욱 폭넓게 통합될 수 있게 되었고 프로그래머의 상호작용을 제공하기 위해 사용자 화면을 분할하고 디버깅 "콘솔"을 추가함으로써 유사한 애니메이션을 제공할 수 있게 되었습니다.
Borland Turbo Debugger는 1989년 PC용 풀스크린 프로그램 애니메이션을 제공하는 독립 실행형 제품입니다.이후 버전에서는 컴파일 시 추출된 실제 소스 라인과 애니메이션을 결합할 수 있는 지원이 추가되었습니다.
프로그램 애니메이션 기술
프로그램 실행 중에 '애니메이션'을 생성하기 위한 최소 세 가지 소프트웨어 기술이 있습니다.
- instrumentation은 컴파일 시에 프로그램에 소스 코드를 추가하여 각 스테이트먼트 전후에 애니메이터를 호출하여 정상적인 실행을 중지하는 것을 포함합니다.이 기능은 파이썬 모듈처럼 런타임 라이브러리의 일부이거나 외부 디버거가 연결된 경우 트리거하는 브레이크 포인트 명령을 삽입하는 형태를 취할 수 있습니다.
- 유도 인터럽트 이 기술은 실행 시 프로그램의 특정 포인트에서 브레이크 포인트를 강제하는 것을 포함합니다.보통 그 포인트에서 기계 코드 명령을 변경하고(이것은 삽입된 시스템 호출이거나 의도적으로 비활성화된 조작일 수 있음) 인터럽트를 기다리는 것입니다.인터럽트가 발생하면 테스트 툴이 처리하여 상태를 프로그래머에게 보고합니다.이 방법을 사용하면 (인터럽트가 발생할 때까지) 최대 속도로 프로그램을 실행할 수 있지만 인터럽트에 이르는 대부분의 명령어가 툴에 의해 감시되지 않는다는 단점이 있습니다.
- 명령 세트 시뮬레이터 이 기술은 컴파일된 프로그램의 기계 코드를 입력 '데이터'로 처리하여 호스트 기계 명령을 완전히 시뮬레이션하고, 코드를 모니터링하여 조건부 또는 무조건 중단점 또는 프로그래머가 매 단계 사이에 "단일 사이클" 애니메이션 요청을 요청합니다.
방법 비교
마지막 방법의 장점은 진단 기능을 제공하기 위해 컴파일된 프로그램을 변경하지 않고 소프트웨어 추적 기능을 추가하여 호스트 시스템 진단을 강화할 수 있기 때문에 광범위한 진단을 수행할 수 있는 범위가 거의 무제한이라는 것입니다.또한 스토리지 위반 및 버퍼 오버플로우를 포함하여 이 기술을 사용하여 많은 프로그램 오류를 자동으로 진단하고 예방할 수 있습니다.자동 명령 트레이스와 명령 카운트 임계값(예: 10,000 명령 후 일시 중지, 마지막 n 명령 표시)을 사용하여 루프 검출도 가능합니다.두 번째 방법은 실행되기 전에 중지되는 명령만 변경하고 프로그래머에 의한 선택적 재개 전에 복원할 수도 있습니다.일부 애니메이터는 필요에 따라 여러 방법을 선택적으로 사용할 수 있습니다.예를 들어 방법 2를 사용하여 특정 지점까지 최대 속도로 실행한 후 명령 집합 시뮬레이션을 사용한다.
기타 기능
애니메이터는 프로그램 트레이스, 덤프, 조건부 중단점 및 메모리 변경, 프로그램 흐름 변경, 코드 커버리지 분석, "핫 스폿" 검출, 루프 검출 등 기타 테스트/디버깅 기능을 조합할 수도 있고 그렇지 않을 수도 있습니다.
