GDB consists of three major subsystems: user interface, symbol handling (the symbol side), and target system handling (the target side).
GDB는 3개의 주요 하위 시스템으로 이루어져 있다: 유저 인터페이스, 심볼 핸들링(심볼 부분), 그리고 타겟 시스템 핸들링(타겟 부분)
The user interface consists of several actual interfaces, plus supporting code.
유저 인터페이스는 몇몇 실제적인 인터페이스와 지원 코드로 이루어져 있다.
The symbol side consists of object file readers, debugging info interpreters, symbol table management, source language expression parsing, type and value printing.
심볼 부분은 객체 파일 리더, 디버깅 정보 해석기, 심볼 파일 관리, 소스 파일 표현식 파싱, 타입과 값 출력으로 이루어져 있다.
The target side consists of execution control, stack frame analysis, and physical target manipulation.
타겟 부분은 실행 제어, 스택 프레임 분석 그리고 물리적 타겟 조정로 이루어져 있다.
The target side/symbol side division is not formal, and there are a number of exceptions. For instance, core file support involves symbolic elements (the basic core file reader is in BFD) and target elements (it supplies the contents of memory and the values of registers). Instead, this division is useful for understanding how the minor subsystems should fit together.
타겟 부분/심볼부분 구분은 형식적이지는 않으며 몇가지 예외가 있다. 예를 들어, 코어 파일 지원은 심볼 요소(기본 코어 파일 리더는 BFD에 있다.)와 타겟 요소(메모리의 내용과 레지스터의 값들을 제공한다.)와 관련이 있다. 대신, 이러한 구분은 작은 하위 시스템이 어울리는 방법을 이해하는데 유용하다.
The symbolic side of GDB can be thought of as "everything you can do in GDB without having a live program running". For instance, you can look at the types of variables, and evaluate many kinds of expressions.
GDB의 심볼 부분은 "프로그램을 돌리는것 없이 여러분은 GDB내에서 모든것을 할수 있다"와 같은 의도일수 있다. 예를 들어, 변수 타입을 볼수 있으며 많은 종류의 표현식을 평가할수 있다.
The target side of GDB is the "bits and bytes manipulator". Although it may make reference to symbolic info here and there, most of the target side will run with only a stripped executable available--or even no executable at all, in remote debugging cases.
GDB의 타겟 부분은 "bits와 bytes 조종자"이다. 비록 여기 저기에 심볼릭 정보에 대한 참조를 만든다 할지라도, 타겟 부분의 대부분은 스트립된 실행 파일만으로 작동된다.--또는 비록 원격 디버깅의 경우에 실행가능하지 않을 지라도.
Operations such as disassembly, stack frame crawls, and register display, are able to work with no symbolic info at all. In some cases, such as disassembly, GDB will use symbolic info to present addresses relative to symbols rather than as raw numbers, but it will work either way.
역 어셈블리, 스택 프레임 돌아다니기 그리고 레지스터 출력과 같은 작동은 심볼릭 정보 없이도 작동될수 있따. 역 어셈블리 같은 몇몇 경우에, GDB는 심볼과 관련된 주소를 나타내기 위해 raw 수보다는 심볼릭 정보를 사용할수 있으며, 둘중 한 방법으로 작동될수 있다.
Host refers to attributes of the system where GDB runs. Target refers to the system where the program being debugged executes. In most cases they are the same machine, in which case a third type of Native attributes come into play.
Host는 GDB가 돌아가고 있는 시스템의 속성을 가리킨다. Target은 디버깅되는 프로그램이 실행되고 있는 시스템을 가리킨다. 대부분의 경우, 이것들은 같은 며신이며 세번째 타입의 Native 속성이 플레이에서 온다.
Defines and include files needed to build on the host are host support. Examples are tty support, system defined types, host byte order, host float format.
호스트에서 빌드될 필요가 있는 정의와 include 파일들은 호스트 지원이다. 예제들을 tty 지원, 시스템 정의 타입, 호스트 바이트 순서, 호스트 float 형식이다.
Defines and information needed to handle the target format are target dependent. Examples are the stack frame format, instruction set, breakpoint instruction, registers, and how to set up and tear down the stack to call a function.
타겟 형식을 처리하기 위해 필요한 정의와 정보는 타겟 의존적이다. 예제들은 스택 프레임 형식, 명령어 집합, breakpoint 명령어, 레지스터들 그리고 설정 방법 그리고 함수를 호출하는 스택 없애기이다.
Information that is only needed when the host and target are the same,
is native dependent. One example is Unix child process support; if the
host and target are not the same, doing a fork to start the target
process is a bad idea. The various macros needed for finding the
registers in the upage, running ptrace, and such are all
in the native-dependent files.
호스트와 타겟이 같을때 필요한 정보는 native 의존적이다. 한 예제는 Unix 자식 프로세스
지원이다; 만일 호스트와 타겟이 같지 않다면, 타겟 프로세스를 시작하기 위해 fork 하는것은
좋지 않은 생각이다. 다양한 매크로들이 upage내 레지스터를 발견하고 ptrace를 돌리는데 필요하며 그러한 것들은 모두 native 의존적 파일들내에 있다.
Another example of native-dependent code is support for features that
are really part of the target environment, but which require
#include files that are only available on the host system. Core
file handling and setjmp handling are two common cases.
native-dependent code의 다른 예제는 타겟 환경의 일부분인 특징들에 대한 지원이다.
그러나 호스트 시스템에서 이용할수 있는 #include 파일을 요구한다.
코어 파일 핸들링과 setjmp 핸들링은 두 일반적인 경우이다.
When you want to make GDB work "native" on a particular machine, you have to include all three kinds of information.
특정 머신에서 GDB가 "native"가 작동되도록 GDB를 만들기 원한다면, 여러분은 세 종류의 정보를 모두 포함해야 한다.
Go to the first, previous, next, last section, table of contents.