The target vector defines the interface between GDB's abstract handling of target systems, and the nitty-gritty code that actually exercises control over a process or a serial port. GDB includes some 30-40 different target vectors; however, each configuration of GDB includes only a few of them.
타겟 벡터는 타겟 시스템의 GDB 추상적 핸들링과 프로세스와 시리얼 포트에서 제어를 실제적으로 할수 있는 코드사이의 인터페이스를 정의한다. GDB는 몇몇 30-40 다른 타겟 벡터를 포함한다; 그러나, GDB 각 설정은 이것들중 일부만을 포함한다.
Both executables and core files have target vectors.
실행파일과 코어 파일은 타겟 벡터를 가지고 있다.
GDB's file `remote.c' talks a serial protocol to code that runs in the target system. GDB provides several sample stubs that can be integrated into target programs or operating systems for this purpose; they are named `*-stub.c'.
GDB의 파일 `remote.c'는 타겟 시스템에서 작동하는 코드를 위한 시리얼 프로토콜을 말한다. GDB는 타겟 프로그램이나 이런 목적을 위한 OS에 통합될수 있는 몇몇 샘플 stubs를 제공한다; `*-stub.c'으로 이름지어져 있다.
The GDB user's manual describes how to put such a stub into your target code. What follows is a discussion of integrating the SPARC stub into a complicated operating system (rather than a simple program), by Stu Grossman, the author of this stub.
GDB 사용자 매뉴얼은 이러한 stub를 타겟 코드에 넣는 방법을 기술한다. 다음은 이 stub의 저자인 Stu Grossman에 의해, SPARC stub를 복잡한 오퍼레이팅 시스템(간단한 프로그램 이상으로)에 통합하는 내용이다.
The trap handling code in the stub assumes the following upon entry to
trap_low:
stub내 trap 핸들링 코드는 trap_low에 대한 엔트리를 다음과 같이 가정한다.:
%l1과 %l2은 trap시 각각 pc와 npc를 포함한다.:
trap은 disable된다.:
여러분은 정확한 trap window안에 있다.
As long as your trap handler can guarantee those conditions, then there
is no reason why you shouldn't be able to "share" traps with the stub.
The stub has no requirement that it be jumped to directly from the
hardware trap vector. That is why it calls exceptionHandler(),
which is provided by the external environment. For instance, this could
set up the hardware traps to actually execute code which calls the stub
first, and then transfers to its own trap handler.
trap handler가 이들 조건을 보장할수 있는 한, 여러분이 stub를 가진 trap을
공유해야하는 이유가 없다. stub는 hardware trap vector에서의 직접 점프를
요구하지 않는다. 이것이 외부 환경에서 제공하는 exceptionHandler()를
호출하는 이유이다. 예를 들어, 우선 stub를 호출한 코드를 실행하도록 hardware trap을 설정할수 있으며 그리고 자신의 trap handler에 전달한다
For the most point, there probably won't be much of an issue with
"sharing" traps, as the traps we use are usually not used by the kernel,
and often indicate unrecoverable error conditions. Anyway, this is all
controlled by a table, and is trivial to modify. The most important
trap for us is for ta 1. Without that, we can't single step or
do breakpoints. Everything else is unnecessary for the proper operation
of the debugger/stub.
일반적으로, trap 공유시 많은 말은 없을 것이다. 왜냐하면 우리가 사용하는 trap은
커널에 의해 사용되지 않으며 자주 회복할수 없는 에러 조건들을 가리키기 때문이다.
어쨋든, 이것은 테이블에 의해 모두 제어되며 수정된다. 우리에게 가장 중요한
trap은 ta 1이다. 그것이 없다면, 우리는 단일 step이나 breakpoint를
할수 없다. 그 밖의 모든 것은 debugger/stub 작동에 불필요하다.
From reading the stub, it's probably not obvious how breakpoints work. They are simply done by deposit/examine operations from GDB.
stub를 읽을때, breakpoint가 작동하는 방법은 분명하지 않다. 이것들은 GDB에서 작동 검사시 간단히 행해진다.
Go to the first, previous, next, last section, table of contents.