GDB uses a number of debugging-specific algorithms. They are often not very complicated, but get lost in the thicket of special cases and real-world issues. This chapter describes the basic algorithms and mentions some of the specific target definitions that they use.
GDB는 한개의 디버깅-특정 알고리즘을 사용한다. 알고리즘이 복잡하지는 않지만, 특정 경우와 실제 세계의 이슈들과 비슷하게 난감하다. 이장은 기본 알고리즘을 기술하고 사용하는 특정 타겟 정의들을 언급한다.
A frame is a construct that GDB uses to keep track of calling and called functions.
프레임은 GDB가 호출 발자취와 호출 함수를 유지하기 위해 사용할려고 생성한다.
FRAME_FP in the machine description has no meaning to the
machine-independent part of GDB, except that it is used when
setting up a new frame from scratch, as follows:
머신 설명서내 FRAME_FP은 다음 처럼 스크래치에서 새 프레임을 설정할때
사용되는것을 제외하고 GDB의 기계-독립적인 부분에 아무런 의미도 가지지 않는다.
create_new_frame (read_register (FP_REGNUM), read_pc ()));
Other than that, all the meaning imparted to FP_REGNUM is
imparted by the machine-dependent code. So, FP_REGNUM can have
any value that is convenient for the code that creates new frames.
(create_new_frame calls INIT_EXTRA_FRAME_INFO if it is
defined; that is where you should use the FP_REGNUM value, if
your frames are nonstandard.)
그것 외에, FP_REGNUM에 알리는 모든 의미는 머신 의존적인 코드가
알려준다. 그래서, FP_REGNUM는 새 프레임을 만드는 코드에 편리한 어떤 값을
가질수 있다. (만일 정의되어 있다면, create_new_frame는 INIT_EXTRA_FRAME_INFO을 호출한다; 만일 여러분의 프레임이 표준이 아니라면, FP_REGNUM
값을 사용해야 한다.)
Given a GDB frame, define FRAME_CHAIN to determine the
address of the calling function's frame. This will be used to create
a new GDB frame struct, and then INIT_EXTRA_FRAME_INFO
and INIT_FRAME_PC will be called for the new frame.
호출 함수의 프레임 주소를 결정하기 위해 FRAME_CHAIN를 정의하고
GDB 프레임을 준다.
이것은 새 GDB 프레임 구조를 만드는데 사용되며 INIT_EXTRA_FRAME_INFO와 INIT_FRAME_PC는 새 프레임을 위해 호출될수 있다.
In general, a breakpoint is a user-designated location in the program where the user wants to regain control if program execution ever reaches that location.
일반적으로, breakpoint는 만일 프로그램 실행이 그 위치에 닫는다면 제어를 복귀하길 원하는 프로그램내 사용자 정의 위치이다.
There are two main ways to implement breakpoints; either as "hardware" breakpoints or as "software" breakpoints.
breakpoint를 수행하는 2가지 주요 방법이 있다; "hardware" breakpoint나 "software" breakpoint
Hardware breakpoints are sometimes available as a builtin debugging features with some chips. Typically these work by having dedicated register into which the breakpoint address may be stored. If the PC (shorthand for program counter) ever matches a value in a breakpoint registers, the CPU raises an exception and reports it to GDB.
Hardware breakapoint는 일부 칩내 내장 디버깅 특징으로써 이용된다. 전형적으로 이것들은 breakpoint가 저장되는 곳의 레지스터를 가지고 작동된다. 만일 PC(program counter)가 brekapoint 레지스터내 값과 일치한다면, CPU는 예외가 일어나고 GDB에게 이것을 알린다.
Another possibility is when an emulator is in use; many emulators include circuitry that watches the address lines coming out from the processor, and force it to stop if the address matches a breakpoint's address.
다른 가능성은 에뮬레이터가 사용될때이다; 많은 에뮬레이터들은 프로세서에서 나오는 주소 라인을 검사하는 circuitry를 포함하며, 만일 주소가 breakpoint 주소와 일치한다면 멈추도록 한다.
A third possibility is that the target already has the ability to do breakpoints somehow; for instance, a ROM monitor may do its own software breakpoints. So although these are not literally "hardware breakpoints", from GDB's point of view they work the same; GDB need not do nothing more than set the breakpoint and wait for something to happen.
세번째 가능성은 타겟이 이미 어떻게든 brekapiont를 할수 있는 능력을 가지고 있는 것이다.; 예를 들어, ROM 모니터는 자신의 software breakpoint를 가지고 있다. 그래서 비록 이것들이 "hardware breakpoint"이 없다할지라도, GDB 관점에서는 같은것으로 작동한다.; GDB는 breakpoint를 설정하고 무엇이 일어나길 기다리는것 외에는 아무것도 할 필요가 없다.
Since they depend on hardware resources, hardware breakpoints may be limited in number; when the user asks for more, GDB will start trying to set software breakpoints. (On some architectures, notably the 32-bit x86 platforms, GDB cannot alsways know whether there's enough hardware resources to insert all the hardware breakpoints and watchpoints. On those platforms, GDB prints an error message only when the program being debugged is continued.)
breakpoint가 하드웨어 자원에 의존하기 때문에, hardware breakpoint는 수가 제한되어 있다; 사용자가 더 요구할때, GDB는 software breakpoint 설정을 시도한다. (몇몇 아키텍쳐에서, 특히 32-bit x86 플레폼에서, GDB는 모든 hardware breakpoint와 watchpoint를 넣을 정도로 충분한 hardware 자원이 있는지를 알지 못한다. 이들 플렛폼에서, GDB는 디버깅되는 프로그램이 계속 될때만 에러 메세지를 출력한다.)
Software breakpoints require GDB to do somewhat more work. The basic theory is that GDB will replace a program instruction with a trap, illegal divide, or some other instruction that will cause an exception, and then when it's encountered, GDB will take the exception and stop the program. When the user says to continue, GDB will restore the original instruction, single-step, re-insert the trap, and continue on.
Software breakpoint는 어쨋든 DB가 더 작동하도록 요구한다. 기본 이론은 GDB는 trap, 불법적인 나누기, 또는 예외를 야기할수 있는 일부 다른 명령어를 가진 프로그램 명령어로 대체할수 있다는 것이다. 그리고 만났을때, GDB는 예외를 가지고 프로그램을 멈춘다. 사용자가 continue를 할때, GDB는 원래 명렁어를 재저장하고, single-step, trap의 재 삽입 그리고 계속한다.
Since it literally overwrites the program being tested, the program area must be writeable, so this technique won't work on programs in ROM. It can also distort the behavior of programs that examine themselves, although such a situation would be highly unusual.
글자 그대로 테스트되는 프로그램을 덮어 쓰기때문에, 프로그램영역은 쓰기 가능이어야 하다. 그래서 이 기술은 ROM에 있는 프로그램에서는 작동하지 않는다. 비록 그러한 상황이 매우 드물다할지라도, 그것들을 검사하는 프로그램의 행동을 잘못되게 할수 있다.
Also, the software breakpoint instruction should be the smallest size of instruction, so it doesn't overwrite an instruction that might be a jump target, and cause disaster when the program jumps into the middle of the breakpoint instruction. (Strictly speaking, the breakpoint must be no larger than the smallest interval between instructions that may be jump targets; perhaps there is an architecture where only even-numbered instructions may jumped to.) Note that it's possible for an instruction set not to have any instructions usable for a software breakpoint, although in practice only the ARC has failed to define such an instruction.
또한, software breakpoint 명령어는 명령어의 크기가 매우 작아야만 한다. 그래서 타겟으로 점프할 명령어를 덮어 쓰지 않아야 한다. 프로그램이 breakpoint 명령어의 중간으로 점프되면 문제점이 발생한다. (엄격히 말해서, breakpoint는 타겟으로 점프할 명령어 사이의 가장 작은 내부보다 커서는 안된다.;아마 여기에는 단지 짝수 명령어들만이 점프하는 아키텍쳐가 있다.) 비록 실제적으로 ARC가 그런 명령어를 정의하는데 실패한다 할지라도, software breakpoint에 유용한 어떤 명령어를 가지지 않는 명령어 집합이 가능하다는 점에 주의해라.
The basic definition of the software breakpoint is the macro
BREAKPOINT.
software breakponit의 기본 정의는 매크로 BREAKPOINT이다.
Basic breakpoint object handling is in `breakpoint.c'. However, much of the interesting breakpoint action is in `infrun.c'. 기본 breakpoint 객체 핸들링은 `breakpoint.c'에서 한다. 그러나 흥미있는 breakpoint 행동의 대부분은 `infrun.c'에서 한다.
GDB has support for figuring out that the target is doing a
longjmp and for stopping at the target of the jump, if we are
stepping. This is done with a few specialized internal breakpoints,
which are visible in the output of the `maint info breakpoint'
command.
GDB는 타겟이 longjmp를 하고 만일 stepping 한다면, 점프한 타겟에서
멈추도록 하는것을 지원한다.
이것은 몇몇 특별한 내부 breakpoint와 함께 하며, 이것은 `maint info breakpoint' 명령어 출력으로 볼수 있다.
To make this work, you need to define a macro called
GET_LONGJMP_TARGET, which will examine the jmp_buf
structure and extract the longjmp target address. Since jmp_buf
is target specific, you will need to define it in the appropriate
`tm-target.h' file. Look in `tm-sun4os4.h' and
`sparc-tdep.c' for examples of how to do this.
이 작동을 하도록 하기 위해, 여러분은 GET_LONGJMP_TARGET라 불리는
매크로를 정의해야 하며, 이것은 jmp_buf 구조를 검사핫고 longjmp target
주소를 알아낸다. jmp_buf가 타겟 의존적이기때문에, 여러분은 적당한
`tm-target.h' 파일에 이것을 정의해야 한다.
이것을 하는 방법에 대한 예를 위해 `tm-sun4os4.h'과 `sparc-tdep.c'를 보아라.
Watchpoints are a special kind of breakpoints (see section Algorithms) which break when data is accessed rather than when some instruction is executed. When you have data which changes without your knowing what code does that, watchpoints are the silver bullet to hunt down and kill such bugs.
Watchpoint는 일부 명령어가 실행되는거이외 데이터가 접근될때 break하는 특별한 종류의 breakpoint이다. 여러분이 코드가 하는일이 무엇인지에 대해 알지 못하고 변경된 데이터를 가지고 있다면, watchpiont는 쫒아가서 그러한 버그를 죽인다.
Watchpoints can be either hardware-assisted or not; the latter type is known as "software watchpoints." GDB always uses hardware-assisted watchpoints if they are available, and falls back on software watchpoints otherwise. Typical situations where GDB will use software watchpoints are:
Watchpoints는 하드웨어-보조이거나 아닐수 있다.; 나중 타입은 "software watchpoints"이다. 이용할수 있다면, GDB는 항상 하드웨어-보조 watchpoint를 사용하며 그렇지 않으면 software watchpoint를 사용한다. GDB가 software watchpoint를 사용하는 전형적인 상황들은 다음과 같다:
검사할려는 메모리 영역이 hardware watchpoint가 지원하는 것보다 크다. 예를 들어, 각 x86 debug register는 4바이트의 메모리를 검사할수 있다. 그래서 16바이트 이상인 크기의 데이터 구조를 볼려고 시도할려면 GDB가 software watchpoint를 사용하도록 해야 한다.
검사할려는 표현식 값은 레지스터(메모리와 반대로)내 데이터에 의존한다.
너무 많은 다른 watchpoint가 요구될때.(몇몇 아키텍쳐에서, 이 상황은 디버그되는 프로그램이 다시 시작할때까지는 발견될수 없다.) x86 debug register는 hardware breakpoint와 watchpoint를 위해 사용된다. 그래서 너무 많은 hardware breakpoint 설정은 watchpoint 삽입이 실패하도록 할수 있다.
어떤 hardware-보조 watchpoint들도 타겟 수행에서 제공되지 않는다.
Software watchpoints are very slow, since GDB needs to single-step the program being debugged and test the value of the watched expression(s) after each instruction. The rest of this section is mostly irrelevant for software watchpoints.
Software watchpoint는 매우 느리다. 왜냐하면 GDB는 디버깅되는 프로그램을 단일-step할 필요가 있고 각 명령어 후 검사할려는 표현식의 값을 검사하여야 하기 때문이다. 이 섹션의 나머지는 대부분 software watchpoint와는 관련이 없다.
GDB uses several macros and primitives to support hardware watchpoints:
GDB는 hardware watchpoint를 지원하기 위해 몇몇 매크로와 primitive를 사용한다.
TARGET_HAS_HARDWARE_WATCHPOINTS
TARGET_CAN_USE_HARDWARE_WATCHPOINT (type, count, other)
설정 가능한 타입 type의 hardware watchpoint의 수를 반환한다. 만일 이 타입의 count watchpoint가 설정될수 있다면 값은 양수, 이 타입의 watchpoint 설정이 지원되지 않는다면 0, 그리고 count가 설정될수 있는 타입 type의 최대 watchpoint 수 이상이면 값은 음수이다. 만일 다른 타입의 watchpoint가 현재 enable되었다면 other는 0이 아니다.
TARGET_REGION_OK_FOR_HW_WATCHPOINT (addr, len)
만일 hardware watchpoint가 주소가 addr이고 길이가 바이트로 len인 영역을 보기 위해 사용된다면 0이 아닌 값이 반환된다.
TARGET_REGION_SIZE_OK_FOR_HW_WATCHPOINT (size)
TARGET_REGION_OK_FOR_HW_WATCHPOINT is not
defined.
만일 hardware watchpoint가 크기가 size인 영역을 보기 위해 사용될수 있다면
0이 아닌 값이 반환된다. GDB는 TARGET_REGION_OK_FOR_HW_WATCHPOINT가 정의되어
있지 않는 경우, fall-back처럼 이 매크로를 사용한다.
TARGET_DISABLE_HW_WATCHPOINTS (pid)
pid로 식별되는 프로세스내 watchpoint를 disable시킨다. 예를 들어, 이것은 플랫폼내 hardware watchpoint를 수행하는 페이지-레벨 메모리 보호를 disable, enable 하도록 작동을 제공하는 HP-UX에서 사용된다.
TARGET_ENABLE_HW_WATCHPOINTS (pid)
pid로 식별되는 프로세스내 watchpoint를 enable시킨다. 예를 들어, 이것은 플랫폼내 hardware watchpoiont를 수행하는 페이지-레벨 메모리 보호를 disable, enable 하도록 작동을 제공하는 HP-UX에서 사용된다.
TARGET_RANGE_PROFITABLE_FOR_HW_WATCHPOINT (pid,start,len)
몇몇 주소는 검사하기 위해 하드웨어를 사용하기에 알맞지 않거나 어드레싱된 객체가 영역 외에 있을때 이해하기 어렵다. 그러므로 hardware watchpoint로 검사해서는 안된다. 몇몇 타겟에서, 이것은 심각한 성능 문제를 야기하며, 우리는 정규 watchpoint를 사용하고 다른 위치를 위해 hardware watchpoint(가능한 정확한)를 저장한다.
target_insert_watchpoint (addr, len, type)
target_remove_watchpoint (addr, len, type)
target_hw_bp_type,
defined by `breakpoint.h' as follows:
len 바이트를 위해, addr에서 시작하는 hardware watchpoint를
삽입하거나 제거해라. type은 watchpoint 타입이며, 나열된 데이터 타입 target_hw_bp_type 중 가능한 값들중 하나이며, 다음 처럼 `breakpoint.h'에
정의되어 있다.
enum target_hw_bp_type
{
hw_write = 0, /* Common (write) HW watchpoint */
hw_read = 1, /* Read HW watchpoint */
hw_access = 2, /* Access (read or write) HW watchpoint */
hw_execute = 3 /* Execute HW breakpoint */
};
These two macros should return 0 for success, non-zero for failure.
target_remove_hw_breakpoint (addr, shadow)
target_insert_hw_breakpoint (addr, shadow)
주소 addr에 hardware-지원 breakpoint를 삽입하거나 제거해라. 성공시 0을 반환하고, 실패시 0이 아닌 값을 반환해라. shadow는 watchpoint가 삽입된 곳의 바이트의 실제 내용이다.; 일반적으로 hardware breakpoint가 사용될때 유효하지 않지만, 다른 코드들이 이들 값을 건들지 않기 때문에, 위 두 매크로의 수행은 내부 목적을 위해 사용될수 있다.
target_stopped_data_address ()
만일 아래에 트리거할 몇몇 watchpoint가 있다면, 해당 watchpoint와 관련된 주소를 반환한다. 그렇지 않으면, 0을 반환한다.
DECR_PC_AFTER_HW_BREAK
DECR_PC_AFTER_HW_BREAK after a hardware break-point. This
overrides the value of DECR_PC_AFTER_BREAK when a breakpoint
that breaks is a hardware-assisted breakpoint.
정의되었다면, GDB는 hardware 중지점 후 DECR_PC_AFTER_HW_BREAK 값에 의해
program counter를 줄인다. 중지하는 breakpoint가 hardware-보조 breakpoint일때 DECR_PC_AFTER_BREAK 값을 오버라이딩한다.
HAVE_STEPPABLE_WATCHPOINT
0이 아닌 값으로 정의되었다면, watchpoint를 그 위로 step하는 것을 disable할 필요가 없다.
HAVE_NONSTEPPABLE_WATCHPOINT
만일 0이 아닌 값으로 정의되었다면, GDB는 그 위 내부로 step하기 위해 watchpoint를 disable 해야 한다.
HAVE_CONTINUABLE_WATCHPOINT
만일 0이 아닌 값으로 정의되었다면, 이것은 watchpoint가 히트된후 하위로 continue하는것이 가능하다.
CANNOT_STEP_HW_WATCHPOINTS
만일 0이 아닌 값으로 정의되었다면, GDB는 하위로 step하기 전에 모든 watchpoint를 제거한다.
STOPPED_BY_WATCHPOINT (wait_status)
struct target_waitstatus, defined by `target.h'.
watchpoint로 멈추었다면 0이 아닌 값을 반환한다. wait_status는 타입 struct target_waitstatus이며, `target.h'에 정의되어 있다.
The 32-bit Intel x86 (a.k.a. ia32) processors feature special debug registers designed to facilitate debugging. GDB provides a generic library of functions that x86-based ports can use to implement support for watchpoints and hardware-assisted breakpoints. This subsection documents the x86 watchpoint facilities in GDB.
32-bit Intel x86 (a.k.a. ia32) 프로세서는 디버깅을 편하게 할수 있도록 디자인된 특별한 디버깅 레지스터들이 있다. GDB는 x86-기반 포트는 watchpoint와 hardware-보조 breakpoint 지원을 하기 위해 사용될수 있는 일반 라이브러리 함수들을 제공한다. 이 하위 섹션은 GDB에서 편리하게 이용할수 있는 x86 watchpoint에 대한 문서들이다.
To use the generic x86 watchpoint support, a port should do the following:
일반 x86 watchpoint 지원을 사용하기 위해, 포트는 다음을 해야 한다:
I386_USE_GENERIC_WATCHPOINTS somewhere in the
target-dependent headers.
타겟-의존적인 헤더에 매크로 I386_USE_GENERIC_WATCHPOINTS를 정의해라.
I386_USE_GENERIC_WATCHPOINTS.
I386_USE_GENERIC_WATCHPOINTS 정의후에 `config/i386/nm-i386.h'
헤더 파일을 포함해라.
NATDEPFILES (see section Native Debugging) or
TDEPFILES (see section Target Architecture Definition).
`i386-nat.o'를 Make 변수 값 NATDEPFILES(Native Debugging 섹션을 참조해라.)이나 TDEPFILES(Target Architecture Definition 섹션을 참조해라.)에 추가해라.
I386_DR_LOW_* macros described
below. Typically, each macro should call a target-specific function
which does the real work.
아래 설명한 I386_DR_LOW_* 매크로를 위한 수행을 제공한다. 전형적으로,
각 매크로는 실제 작업을 하는 타겟에 의존적인 함수를 호출해야 한다.
The x86 watchpoint support works by maintaining mirror images of the debug registers. Values are copied between the mirror images and the real debug registers via a set of macros which each target needs to provide:
x86 watchpoint는 디버그 레지스터의 미러(mirror) 이미지를 유지하여 작업을 지원한다. 값들은 각 타겟이 제공될 필요가 있는 매크로 집합을 통해서 미러 이미지와 실제 디버그 레지스터 사이에 복사된다.
I386_DR_LOW_SET_CONTROL (val)
I386_DR_LOW_SET_ADDR (idx, addr)
I386_DR_LOW_RESET_ADDR (idx)
I386_DR_LOW_GET_STATUS
I386_DR_LOW_GET_STATUS, so as to support per-thread status
register values.
Debug Status (DR6) 레지스터의 값을 반환한다. 이 값은 쓰레드당 상태 레지스터 값들을 지원하기 위해 I386_DR_LOW_GET_STATUS에 의해 반환된후 즉시 사용된다.
For each one of the 4 debug registers (whose indices are from 0 to 3) that store addresses, a reference count is maintained by GDB, to allow sharing of debug registers by several watchpoints. This allows users to define several watchpoints that watch the same expression, but with different conditions and/or commands, without wasting debug registers which are in short supply. GDB maintains the reference counts internally, targets don't have to do anything to use this feature.
4개의 디버그 레지스터(0에서 3으로 인덱스된다.)들 각각은 주소들을 저장하며, 참조 카우터(reference count)는 몇몇 watchpoint에 의한 디버그 레지스터들의 공유를 허용하기 위해 GDB에 의해 유지된다. 이것은 같은 표현식을 검사하는 몇몇 watchpoint 를 정의하도록 사용자에게 허용한다. 그러나 다른 조건 and/or 명령어와, 디버그 레지스터를 낭비하는 것 없이. GDB는 내부적으로 참조 카운터를 유지하며, 타겟은 이 특징을 사용할 어떤 것도 가지고 있지 않다.
The x86 debug registers can each watch a region that is 1, 2, or 4 bytes long. The ia32 architecture requires that each watched region be appropriately aligned: 2-byte region on 2-byte boundary, 4-byte region on 4-byte boundary. However, the x86 watchpoint support in GDB can watch unaligned regions and regions larger than 4 bytes (up to 16 bytes) by allocating several debug registers to watch a single region. This allocation of several registers per a watched region is also done automatically without target code intervention.
x86 debug 레지스터는 각 1, 2 또는 4바이트 long인 영역을 검사할수 있다. ia32 아키텍쳐는 각 검사 영역은 적절한 정렬이 요구된다: 2-byte 경계에 2-byte 영역, 4-byte 경계에 4-byte 영역. 그러나, GDB에서 지원하는 x86 watchpoint은 정렬되지 않은 영역과 단일 영역을 검사하기 위해 몇몇 디버그 레지스터들을 할당하여 4바이트(16 바이트까지) 보다 큰 영역을 검사할수 있다. 검사 영역당 몇몇 레지스터 할당은 타겟 코드 중재 없이 자동적으로 행해진다.
The generic x86 watchpoint support provides the following API for the GDB's application code:
일반 x86 watchpoint는 GDB 응용프로그램 코드를 위해 다음 API를 제공한다.:
i386_region_ok_for_watchpoint (addr, len)
TARGET_REGION_OK_FOR_HW_WATCHPOINT is set to call
this function. It counts the number of debug registers required to
watch a given region, and returns a non-zero value if that number is
less than 4, the number of debug registers available to x86
processors.
매크로 TARGET_REGION_OK_FOR_HW_WATCHPOINT는 이 함수를 호출하기 위해 설정한다.
주여진 영역의 검사를 요구하는 디버그 레지스터의 수를 세고 만일 x86 프로세서가 이용할수 있는
디버그 레지스터의 수가 4보다 작다면 0이 아닌 값을 반환한다.
i386_stopped_data_address (void)
STOPPED_BY_WATCHPOINT and
target_stopped_data_address are set to call this function. The
argument passed to STOPPED_BY_WATCHPOINT is ignored. This
function examines the breakpoint condition bits in the DR6 Debug
Status register, as returned by the I386_DR_LOW_GET_STATUS
macro, and returns the address associated with the first bit that is
set in DR6.
매크로 STOPPED_BY_WATCHPOINT과 target_stopped_data_address는
이 함수 호출을 위해 설정한다. STOPPED_BY_WATCHPOINT에 전달되는 인자는 무시된다.
이 함수는 I386_DR_LOW_GET_STATUS 매크로가 반환하는 DR6 Debug Status 레지스터내
breakpoint 조건 비트를 검사하며 DR6내 설정된 첫 비트와 관련된 주소를 반환한다.
i386_insert_watchpoint (addr, len, type)
i386_remove_watchpoint (addr, len, type)
target_insert_watchpoint and target_remove_watchpoint
are set to call these functions. i386_insert_watchpoint first
looks for a debug register which is already set to watch the same
region for the same access types; if found, it just increments the
reference count of that debug register, thus implementing debug
register sharing between watchpoints. If no such register is found,
the function looks for a vacant debug register, sets its mirrorred
value to addr, sets the mirrorred value of DR7 Debug Control
register as appropriate for the len and type parameters,
and then passes the new values of the debug register and DR7 to the
inferior by calling I386_DR_LOW_SET_ADDR and
I386_DR_LOW_SET_CONTROL. If more than one debug register is
required to cover the given region, the above process is repeated for
each debug register.
i386_remove_watchpoint does the opposite: it resets the address
in the mirrorred value of the debug register and its read/write and
length bits in the mirrorred value of DR7, then passes these new
values to the inferior via I386_DR_LOW_RESET_ADDR and
I386_DR_LOW_SET_CONTROL. If a register is shared by several
watchpoints, each time a i386_remove_watchpoint is called, it
decrements the reference count, and only calls
I386_DR_LOW_RESET_ADDR and I386_DR_LOW_SET_CONTROL when
the count goes to zero.
watchpoint를 삽입하고 제거한다. 매크로 target_insert_watchpoint와 target_remove_watchpoint는 이들 함수를 호출하기 위해 설정한다. i386_insert_watchpoint는 우선 같은 접속 타입을 위해 같은 영역을 검사하도록 이미 설정된 디버그 레지스터를 찾는다.;
만일 반견된다면, 디버그 레지스터의 참조 수를 증가시키고, watchpoint 사이에 공유되는
디버그 레지스터를 수행한다. 만일 그런 레지스터가 발견되지 않는다면, 함수는 빈 디버그 레지스터를
찾고 미러된 값을 addr로 설정하고, len와 type 파라미터에
적절하게 DR7 Debug Control 레지스터의 값을 설정하고 디버그 레지스터와 DR7의 새 값을
I386_DR_LOW_SET_ADDR와 I386_DR_LOW_SET_CONTROL를 호출하여
하위로 던진다. 만일 한개 이상의 디버그 레지스터가 주어진 영역을 커버하기 위해 요구된다면,
위 프로세스는 각 디버그 레지스터를 반복한다.
i386_remove_watchpoint은 반대로 한다.;이것은 디버그 레지스터의 반영 값내
주소와 읽기/쓰기 그리고 DR7의 반영값내 길이 bits를 리셋하고 이들 새로운 값을 I386_DR_LOW_RESET_ADDR와 I386_DR_LOW_SET_CONTROL를 통해 하위로 전달한다.
만일 레지스터가 몇몇 watchpoint에 의해 공유된다면, 매번 i386_remove_watchpoint
가 호출되며, 참조 수를 줄이고 카운트가 0일때 I386_DR_LOW_RESET_ADDR와 I386_DR_LOW_SET_CONTROL를 호출한다.
i386_insert_hw_breakpoint (addr, shadow
i386_remove_hw_breakpoint (addr, shadow)
target_insert_hw_breakpoint and
target_remove_hw_breakpoint are set to call these functions.
These functions work like i386_insert_watchpoint and
i386_remove_watchpoint, respectively, except that they set up
the debug registers to watch instruction execution, and each
hardware-assisted breakpoint always requires exactly one debug
register.
이들 함수는 hardware-보조 breakpoint를 삽입하고 제거한다.
매크로 I386_DR_LOW_SET_CONTROL와 target_remove_hw_breakpoint는
이들 함수를 호출하기 위해 설정한다. 이들 함수는 명령어 실행을 보기 위해 디버그 레지스터를
설정하고 각 hardware-보조 breakpoint는 항상 한개의 디버그 레지스터를 요구한다는것을 제외하고
i386_insert_watchpoint와 i386_remove_watchpoint처럼 작동한다.
i386_stopped_by_hwbp (void)
i386_stopped_data_address, except that it doesn't return the
address whose watchpoint triggered.
이 함수는 만일 내부에 일부 watchpoint나 트리거되는 hardware breakpoint가 있다면 0이 아닌 값을
반환한다. 이것은 트리거되는 watchpoint의 주소를 반환하지 않는다는것을 제외하고
i386_stopped_data_address와 같게 작동한다.
i386_cleanup_dregs (void)
이 함수는 참조 수, 주소, 디버그 레지스터의 반영 이미지내 제어 비트를 모두 지운다. 이것은 내부 프로세스내 실제 디버그 레지스터에 영향을 주지 않는다.
Notes:
enum target_hw_bp_type doesn't even have an enumeration for I/O
watchpoints, this feature is not yet available to GDB running
on x86.
x86 프로세서는 I/O 읽기 또는 쓰기에서 watchpoint 설정을 지원한다.
그러나, 어떤 타겟도 이것(March 2001)을 지원하지 않기 때문에, 그리고 enum target_hw_bp_type는 I/O watchpoint를 위해 열거를 가지지 않기 때문에, 이 특징은 x86에서 돌아가는
GDB에서 아직 이용할수 없다.
x86 프로세서는 현재 task만을 위해 지역적으로나 전체 task를 위해 전역적으로 watchpoint를 enable할수 있다. 각 디버그 레지스터를 위해, 관련 주소가 지역적으로 보여지는지 전역적으로 보여지는지를 결정하는 DR7 Debug Control 레지스터내 비트가 있다. GDB에서 지원하는 x86 watchpoint의 현재 수행은 항상 지역적으로 enable되도록 watchpoint를 설정한다. 왜냐하면 전역 watchpoint는 기반 OS와 상충되고 아마도 많은 플랫폼에서 이용할수 없기 때문이다.
Go to the first, previous, next, last section, table of contents.