중단점

Breakpoint
중단점에 일시 중단된 프로그램이 있는 이클립스의 디버깅 인터페이스입니다.스택 트레이스(왼쪽 위)와 감시 변수(오른쪽 위)가 있는 패널을 볼 수 있습니다.

소프트웨어 개발에서 브레이크 포인트는 프로그램 에서 의도적으로 정지하거나 일시 정지하는 장소이며 디버깅을 위해 배치됩니다.이것은 때때로 단순히 일시정지라고도 불린다.

일반적으로 중단점은 프로그램을 실행하는 동안 프로그램에 대한 지식을 습득하는 수단입니다.인터럽트 중에 프로그래머는 테스트 환경(범용 레지스터, 메모리, 로그, 파일 등)을 검사하여 프로그램이 예상대로 기능하고 있는지 여부를 확인합니다.실제로 중단점은 프로그램 실행을 중단해야 하는 시기를 결정하는 하나 이상의 조건으로 구성됩니다.

중단점은 최초의 디지털 컴퓨터 중 하나[1]ENIAC를 위해 프로그래머 Betty Holberton에 의해 발명되었다.ENIAC의 초기 설계에서는 한 유닛에서 다른 유닛으로 케이블을 연결하여 프로그램 플로우를 설정했습니다.프로그램을 특정 지점에서 정지시키기 위해 [2]중단점이라고 불리는 케이블이 제거되었습니다.

기계 중단점

IBM/360과 같은 초기 메인프레임 컴퓨터에는 특정 명령 스토리지 주소에서 중단점을 허용하고 "단일 주기" 작동을 제공하여 콘솔 조명에서 레지스터와 메모리의 내용을 직접 관찰할 수 있도록 하는 콘솔 스위치/다이얼이 있었습니다.멀티태스킹의 출현으로 기계 전체가 정지되었기 때문에 이 옵션의 사용이 제한되었습니다.

인터랙티브하지 않은 중단점

프로그래머는 컴퓨터 초기부터 기계 코드 패치를 사용하여 코어 덤프를 발생시키는 단일 파괴 중단점을 구현해 왔습니다.코어 덤프는 의도적인 "충돌"의 정확한 순간에 레지스터와 메모리의 상태를 제공합니다.

인터랙티브 브레이크 포인트

1960년대 텔레타이프라이터 콘솔의 등장은 보다 인터랙티브한 명령줄 디버깅 기능을 가능하게 했지만 1970년대 초가 되어서야 메인프레임에 연결된 유비쿼터스 비디오 모니터가 등장하여 멀티태스킹 환경에서 완전한 인터랙티브한 풀스크린 디버깅이 실현되었습니다.또한 옵션 레지스터와 메모리 변경을 동시에 표시하여 진정한 프로그램 애니메이션 방식으로 프로그램을 단계적으로 실행할 수 있었습니다.처음에는 이런 유형의 애니메이션이 분해 또는 디컴파일된 기계 코드 수준이었지만 나중에는 HLL 소스 수준 애니메이션으로 발전했습니다.

중단점 조건

중단점은 프로그래머 지정 명령 실행 직전에 실행 중인 프로그램을 중단하기 위해 가장 일반적으로 사용됩니다.이를 명령 중단점이라고 합니다.

메모리 영역 내 특정 위치의 읽기, 쓰기 또는 수정과 같은 다른 종류의 조건도 사용할 수 있습니다.이것은 보통 조건부 중단점, 데이터 중단점 또는 워치포인트라고 불립니다.한편, 로그 포인트라고 불리는 비브레이크 포인트는 실행을 중지하지 않고 브레이크 포인트에서 코드 조각의 전체 상태를 표시할 수 있습니다.

브레이크 포인트는, 특정의 시각, 키 입력시에 실행을 중단하기 위해서도 사용할 수 있습니다.

검사 도구

중단점에 도달하면 다양한 도구를 사용하여 프로그램 상태를 검사하거나 변경합니다. 스레드의 스택트레이스를 사용하여 일시정지 명령으로 이어진 함수 호출 체인을 확인할 수 있습니다.시계 목록을 통해 선택한 변수와 값을 볼 수 있습니다.레지스터의 내용, 로드된 프로그램 모듈 및 기타 정보를 표시하는 도구도 있을 수 있습니다.

실장

하드웨어

대부분의 프로세서에는 중단점(일반적으로 명령 및 데이터 중단점)에 대한 하드웨어 지원이 포함되어 있습니다.예를 들어 x86 명령 집합 아키텍처는 x86 디버깅 레지스터를 사용하여 중단점을 하드웨어로 지원합니다.이러한 하드웨어에는 예를 들어 분기 지연 슬롯에 있는 명령에서 브레이크 포인트를 허용하지 않는 등의 제한이 포함될 수 있습니다.이러한 제한은 프로세서의 마이크로아키텍처(architecture)에 의해서 다릅니다.

소프트웨어

하드웨어가 지원되지 않으면(또한 멀티태스킹 환경에서도), 디버거는 소프트웨어에 중단점을 구현해야 합니다.명령 중단점의 경우, 이는 중단점의 위치에 있는 명령을 다음 중 하나로 대체하는 비교적 간단한 작업입니다.

  • 디버거를 직접 호출하는 명령(를 들어 시스템 호출) 또는
  • 의도적인 프로그램 인터럽트를 일으키는 잘못된 명령(그 후 디버거에 의해 가로채거나 차단됨)

이 기술은 공유 프로그램 스토리지를 사용하는 멀티태스킹 시스템에서 구현하기가 더 어려울 수 있습니다(인터럽트가 다른 스레드에서 발생할 수 있으므로 해당 스레드에 대한 원래 명령을 다시 실행해야 합니다).또, 프로그램이 보호된 메모리에 있는 경우는, 명령의 덮어쓰기를 방지할 수 있습니다.

또,

  • 명령 집합 시뮬레이터는 자체 정상 프로그램 주기 내에 적절한 조건 테스트를 포함시킴으로써 무조건 또는 조건부 중단점을 구현할 수 있으며, 이는 비침습적 중단점을 자연스럽게 허용하기도 합니다(예: 읽기 전용 프로그램).
  • 통역된 언어는 프로그램 사이클에서 위와 같은 개념을 효과적으로 사용할 수 있습니다.
  • 내부 또는 외부 디버깅서브루틴을 호출하는 함수를 발행하는 추가 소스 문과 함께 모든 소스 코드를 "계장"하는 것은 또 다른 일반적인 접근법이다.이 방법은 바이너리 크기를 증가시켜 일반 메모리 할당 및 예외 핸들러에 악영향을 미칠 수 있습니다.일부 컴파일러에는 이 기술을 반투과적으로 구현하기 위한 "디버깅" 옵션이 있습니다.

일부 디버거는 메모리 내의 레지스터 또는 프로그램 변수를 재개하기 전에 수정할 수 있도록 하여 테스트 목적으로 "수작업으로 코딩된" 임시 할당을 효과적으로 도입할 수 있도록 합니다.마찬가지로 프로그램 명령을 건너뛰어 프로그램 로직 변경의 영향을 확인할 수 있습니다.이것에 의해, 프로그램 실행에 관한 질문에 대해서, 직접(즉, 가정이나 추측 없이) 회답할 수 있습니다.대부분의 경우 일시적인 소스 변경을 남길 위험 없이 거의 실행되지 않는 불명확한 "이벤트 주도" 오류 서브루틴을 테스트하는 유일한 실용적인 방법이 될 수 있습니다.일시정지된 프로그램 내에서 재개 위치를 수동으로 변경하면 실행이 거의 이루어지지 않는 코드 섹션(특정 하드웨어 상태 핸들러 등)을 입력할 수 있습니다.

그러나 소프트웨어에 데이터 중단점을 구현하면 디버깅되는 애플리케이션이 동일한 [3]프로세서 상에서 추가 리소스를 사용하기 때문에 성능이 크게 저하될 수 있습니다.단, 이는 테스트 중에 일반적으로 허용되며 디버거에서 사용할 수 있는 정보의 양은 하드웨어에 알려진 디버깅 데이터의 제한에 의해 제한되지 않습니다.예를 들어 소프트웨어 구현은 프로그램/서브루틴/명령 수준에서 논리 경로 데이터를 수집하여 검사를 위해 특정 하드웨어 플랫폼에 의해 저장될 수 있는 것을 상당히 증가시킬 수 있습니다.명령 집합 시뮬레이션 방법은 (반복되는) 명령 대체 방법에 비해 오버헤드를 크게 줄여 캐시 누락도 줄여줍니다.

일부 프로그래밍 언어 구현은 다른 프로그램에서 사용할 수 있도록 디버깅 함수를 노출합니다.예를 들어, 일부 FORTRAN 방언에는AT원래 명령 중단점으로 기능하기 위한 문입니다.Python은 Python [4]프로그램에서 액세스할 수 있는 디버거를 구현합니다.이러한 설비는 COME FROM 스테이트먼트와 같이 동작하기 위해 악용될 수 있습니다[5].

「 」를 참조해 주세요.

레퍼런스

  1. ^ Abbate, Janet (2012), Recoding Gender: Women's Changing Participation in Computing, MIT Press, p. 32, ISBN 9780262018067
  2. ^ Thomas Haigh; Mark Priestley; Crispen Rope (2016). ENIAC in Action:Making and Remaking the Modern Computer. MIT Press. p. 153. ISBN 978-0-262-03398-5.
  3. ^ 2011년 11월 29일 Wayback Machine에서 GDB 내부 아카이브 완료
  4. ^ Python 라이브러리 참조: 2008년 9월 13일 Wayback Machine에서 아카이브된 Python Debugger
  5. ^ entrian.com – Python용 goto 및 from