Symbols are a key part of GDB's operation. Symbols include variables, functions, and types.
심볼은 GDB 작동에서 중요한 부분이다. 심볼은 변수, 함수 그리고 타입을 포함한다.
GDB reads symbols from symbol files. The usual symbol file is the file containing the program which GDB is debugging. GDB can be directed to use a different file for symbols (with the `symbol-file' command), and it can also read more symbols via the `add-file' and `load' commands, or while reading symbols from shared libraries.
GDB는 symbol files에서 심볼을 읽는다. 일반적인 심볼 파일은 GDB가 디버깅하는 프로그램을 포함한 파일이다. GDB는 심볼(`symbol-file' 명령어로)을 위해 다른 파일을 사용하도록 지시할수 있으며 `add-file'와 `load' 명령어를 통해 더 많은 심볼을 읽을수 있으며 또 공유 라이브러리에서 심볼을 읽을수 있다.
Symbol files are initially opened by code in `symfile.c' using
the BFD library (see section Support Libraries). BFD identifies the type
of the file by examining its header. find_sym_fns then uses
this identification to locate a set of symbol-reading functions.
심볼 파일은 BFD 라이브러리(Support Libraries 섹션을 참조해라.)를 사용하는 `symfile.c'내 코드에 의해
열린다. BFD는 헤더를 검사하여 파일의 타입을 식별한다.
그리고 find_sym_fns는 심볼-읽는 함수 집합을 위치시키기 위해
이 식별을 사용한다.
Symbol-reading modules identify themselves to GDB by calling
add_symtab_fns during their module initialization. The argument
to add_symtab_fns is a struct sym_fns which contains the name (or name prefix) of the symbol format, the length of the prefix,
and pointers to four functions. These functions are called at various
times to process symbol files whose identification matches the specified
prefix.
심볼-읽기 모듈은 모듈 초기화동안 add_symtab_fns를 호출하여
GDB에서 그것들을 식별한다.
add_symtab_fns에 대한 인자는 심볼 형식의 이름, 접두사의 길이,
그리고 네 함수에 대한 포인터를 포함하는 struct sym_fns이다.
이들 함수는 지정된 접두사와 일치하여 식별된 심볼 파일을 처리하기 위해 여러번
호출된다.
The functions supplied by each module are:
각 모듈이 제공하는 함수는:
xyz_symfile_init(struct sym_fns *sf)
symbol_file_add when we are about to read a new
symbol file. This function should clean up any internal state (possibly
resulting from half-read previous files, for example) and prepare to
read a new symbol file. Note that the symbol file which we are reading
might be a new "main" symbol file, or might be a secondary symbol file
whose symbols are being added to the existing symbol table.
새 심볼 파일을 읽을때 symbol_file_add에서 호출된다.
이 함수는 내부 상태(예를 들어 half-read 전 파일의 결과)를 비우고 새 심볼 파일을 읽을
준비를 한다.
우리가 읽는 심볼 파일은 새로운 "main" 심볼 파일이거나 존재하는 심볼 테이블에 추가된
이차 심볼 파일이다.
The argument to xyz_symfile_init is a newly allocated
struct sym_fns whose bfd field contains the BFD for the
new symbol file being read. Its private field has been zeroed,
and can be modified as desired. Typically, a struct of private
information will be malloc'd, and a pointer to it will be placed
in the private field.
There is no result from xyz_symfile_init, but it can call
error if it detects an unavoidable problem.
xyz_symfile_init에 대한 인자는 새로 항당된 struct sym_fns
이며 bfd는 읽는 새로운 심볼 파일을 위해 BFD를 포함한다.
private 필드는 0이며 원하면 수정할수 있다. 전형적으로 개인 정보 구조는
malloc되며 이것에 대한 포인터는 private 필드에 놓인다.
xyz_symfile_init의 결과는 아니지만 만일 피할수 없는 문제가 발견된다면
error를 호출한다.
xyz_new_init()
symbol_file_add when discarding existing symbols.
This function needs only handle the symbol-reading module's internal
state; the symbol table data structures visible to the rest of
GDB will be discarded by symbol_file_add. It has no
arguments and no result. It may be called after
xyz_symfile_init, if a new symbol table is being read, or
may be called alone if all symbols are simply being discarded.
존재하는 심볼을 버릴때 symbol_file_add에서 호출된다.
이 함수는 심볼-읽는 모듈의 내부 상태를 처리할때만 필요하다.; GDB 나머지를 비주얼하게 하는
심볼 테이블 데이터 구조는 symbol_file_add에 의해 버려진다.
인자도 없고 반환값도 없다. 만일 새로운 심볼 테이블을 읽는다면 xyz_symfile_init 다음에 호출되거나, 만일 모든 심볼이 단순히 버려진다면 호출된다.
xyz_symfile_read(struct sym_fns *sf, CORE_ADDR addr, int mainline)
symbol_file_add to actually read the symbols from a
symbol-file into a set of psymtabs or symtabs.
sf points to the struct sym_fns originally passed to
xyz_sym_init for possible initialization. addr is
the offset between the file's specified start address and its true
address in memory. mainline is 1 if this is the main symbol
table being read, and 0 if a secondary symbol file (e.g. shared library
or dynamically loaded file) is being read.
심볼 파일의 psymtab이나 symtab 집합에서 심볼을 읽기 위해 symbol_file_add에서
호출된다.
sf는 가능한 초기화를 위해 xyz_sym_init에 전달되는 struct sym_fns에 대한 포인터이다. addr는 파일이 지정한 시작주소와
메모리내 실제 주소 사이의 offset이다. mainline는 만일 이것이 읽은 메인 심볼
테이블이라면 1, 만일 2차 심볼 파일(즉, 공유 라이브러리나 동적으로 로딩된 파일)이 읽었다면 0
이다.
In addition, if a symbol-reading module creates psymtabs when
xyz_symfile_read is called, these psymtabs will contain a pointer
to a function xyz_psymtab_to_symtab, which can be called
from any point in the GDB symbol-handling code.
게다가 만일 심볼 읽는 모듈이 xyz_symfile_read가 호출될때 psymtabs을 만든다면,
이들 psymtabs은 GDB 심볼 핸들링 코드내 어떤 포인트에서 호출되는 함수 xyz_psymtab_to_symtab에 대한 포인터를 포함한다.
xyz_psymtab_to_symtab (struct partial_symtab *pst)
psymtab_to_symtab (or the PSYMTAB_TO_SYMTAB macro) if
the psymtab has not already been read in and had its pst->symtab
pointer set. The argument is the psymtab to be fleshed-out into a
symtab. Upon return, pst->readin should have been set to 1, and
pst->symtab should contain a pointer to the new corresponding symtab, or
zero if there were no symbols in that part of the symbol file.
만일 psymtab이 이미 읽혀지지 않고 pst->symtab 포인터 집함을 가지고
있다면 psymtab_to_symtab(또는 PSYMTAB_TO_SYMTAB 매크로)에서 호출된다.
인자는 symtab과 일치하지 않게 하기 위한 psymtab이다. 반환시, pst->readin는
1로 설정되어야 하며 pst->symtab는 새로운 해당 symtab에 대한 포인터를 포함해야
하며, 만일 심볼 파일의 일부분에 심볼이 없다면, 0을 포함해야 한다.
GDB has three types of symbol tables:
GDB는 세 타입의 심볼 테이블을 가지고 있다:
부분적인 심볼 테이블(psymtabs). 이것은 전체 심볼 테이블에서 관련된 부분을 읽을때 알려줄 충분한 정보를 포함한다.
최소 심볼 테이블 (msymtabs). 이것은 비-디버깅 심볼에서 모아진 정보를 포함한다.
This section describes partial symbol tables.
이 섹션은 부분적인 심볼 테이블을 기술한다.
A psymtab is constructed by doing a very quick pass over an executable file's debugging information. Small amounts of information are extracted--enough to identify which parts of the symbol table will need to be re-read and fully digested later, when the user needs the information. The speed of this pass causes GDB to start up very quickly. Later, as the detailed rereading occurs, it occurs in small pieces, at various times, and the delay therefrom is mostly invisible to the user.
psymtab은 실행 파일 디버깅 정보를 매우 빠르게 전달되도록 만들어 졌다. 작은 양의 정보는 일부 심볼 테이블을 다시 읽을 필요가 있다는 것을 알아낸다. 그리고 사용자가 정보가 필요할때 나중에 완전히 소화된다. 전달 속도는 GDB가 매우 빠르게 시작하도록 야기한다. 나중에, 세부적으로 다시 읽기가 발생한다면, 여러번 작은 단위로 일어나며 그러한 딜레이는 사용자들이 가장 볼수 없는것이다.
The symbols that show up in a file's psymtab should be, roughly, those
visible to the debugger's user when the program is not running code from
that file. These include external symbols and types, static symbols and
types, and enum values declared at file scope.
파일의 psymtab에서 보여주는 심볼은 프로그램이 해당 파일에서 돌아가는 코드가 아닐때
디버거 사용자에게 이것들을 보여줘야 한다. 이것들은 외부 심볼과 타입, 정적 심볼과 타입,
그리고 파일 범위내 선언된 enum 변수를 포함한다.
The psymtab also contains the range of instruction addresses that the full symbol table would represent.
psymtab은 전체 심볼 테이블이 나타내는 명령어 주소의 범위를 포함한다.
The idea is that there are only two ways for the user (or much of the code in the debugger) to reference a symbol:
idea는 심볼을 참조하기 위해 사용자(또는 디버거내 많은 코드)에게는 2가지의 방법이 있다는 것이다.
find_pc_function, find_pc_line, and other
find_pc_... functions handle this.
주소로 (e.g. 실행은 파일에서 함수내 일부 주소에서 멈춘다.)
주소는 이 psymtab의 범위내에서 인식되고 전체 symtab은 읽혀진다.
find_pc_function, find_pc_line, 그리고 다른 find_pc_...
함수는 이것을 처리한다.
lookup_symbol
does most of the work here.
이름으로 (e.g. 사용자는 변수나 함수내 breakpoint 설정을 출력하도록 요구한다.)
전역 이름과 파일 범위 이름은 psymtab에서 발견되며, 뽑아내도록 symtab을 야기한다.
지역 이름은 전역 이름이나 파일 범위 이름으로 자격이 주어지며 그런 경우 우리는 자격이 있는
이름을 평가하기 위해 symtab을 읽는다.
또는, 지역 심볼은 우리가 지역 범위내 있을때 참조될수 있으며, 그런 경우 처음 경우가 적용된다.
lookup_symbol은 여기서 작업의 대부분을 한다.
The only reason that psymtabs exist is to cause a symtab to be read in at the right moment. Any symbol that can be elided from a psymtab, while still causing that to happen, should not appear in it. Since psymtabs don't have the idea of scope, you can't put local symbols in them anyway. Psymtabs don't have the idea of the type of a symbol, either, so types need not appear, unless they will be referenced by name.
psymtab이 존재하는 유일한 이유는 적당한 순간에 symtab을 읽도록 야기하는 것이다. psymtab에서 생략될수 있는 심볼은 나타나도록 야기하는 동안에도, 그곳에서 나타나서는 안된다. psymtab은 범위에 대한 아이디어를 가지고 있지만, 여러분은 어쨋든 지역 심볼을 놓을수 없다. psymtab은 심볼 타입에 대한 아이디어를 가지고 있지 않다. 그래서 이름으로 참조한다는것을 제외한다면 타입은 나타날 필요가 없다.
It is a bug for GDB to behave one way when only a psymtab has been read, and another way if the corresponding symtab has been read in. Such bugs are typically caused by a psymtab that does not contain all the visible symbols, or which has the wrong instruction address ranges.
psymtab이 읽여질때 하는 행동과 상응하는 symtab이 읽혀질때 다른 방법으로 행동하는 것은 GDB 버그이다. 그런 버그는 전형적으로 psymtab이 모든 비져블 심볼을 포함하지 않아서거나 잘못된 명령어 주소 범위를 가지기 때문이다.
The psymtab for a particular section of a symbol file (objfile) could be thrown away after the symtab has been read in. The symtab should always be searched before the psymtab, so the psymtab will never be used (in a bug-free environment). Currently, psymtabs are allocated on an obstack, and all the psymbols themselves are allocated in a pair of large arrays on an obstack, so there is little to be gained by trying to free them unless you want to do a lot more work.
심볼 파일(objfile)의 특정 섹션을 위한 psymtab은 symtab이 읽혀진후 버려진다. symtab은 항상 psymtab전에 검색되며, 그래서 psymtab은 결코 사용(buf-free environment)되지 않는다. 현재, psymtab은 obstack에서 할당되며 모든 psymbol은 obstack내 커다란 배열쌍으로 할당된다. 그래서 만일 여러분이 더 많이 일하길 원하지 않는다면 그것들을 해제할려고 시도하여 얻는 것은 거의 없다.
FT_VOID, FT_BOOLEAN).FT_VOID, FT_BOOLEAN).These are the fundamental types that GDB uses internally. Fundamental types from the various debugging formats (stabs, ELF, etc) are mapped into one of these. They are basically a union of all fundamental types that GDB knows about for all the languages that GDB knows about.
이것들은 GDB가 내부적으로 사용하는 기본 타입이다. 다양한 디버깅 형식(stab, ELF 등)에서 기본 타입은 이것들중 하나로 대응된다. 그들은 기본적으로 GDB가 알고 있는 모든 언어에 관해 GDB가 알고 있는 모든 기본 타입과 결합한다.
TYPE_CODE_PTR, TYPE_CODE_ARRAY).TYPE_CODE_PTR, TYPE_CODE_ARRAY).
Each time GDB builds an internal type, it marks it with one
of these types. The type may be a fundamental type, such as
TYPE_CODE_INT, or a derived type, such as TYPE_CODE_PTR
which is a pointer to another type. Typically, several FT_*
types map to one TYPE_CODE_* type, and are distinguished by
other members of the type struct, such as whether the type is signed
or unsigned, and how many bits it uses.
GDB는 매번 내부 타입을 만들며, 이것은 이들 타입중 하나로 표시된다.
타입은 TYPE_CODE_INT같은 기본 타입이거나 타른 타입을 포인터하는 TYPE_CODE_PTR 같은 파생 타입이다.
전형적으로, 몇몇 FT_* 타입은 TYPE_CODE_* 타입으로 대응하며
어떤 타입이 sign이나 unsign인지, 얼마나 많은 비트가 사용되는지와 같은 타입 구조의
다른 멤버들에 의해 구별된다.
builtin_type_void, builtin_type_char).builtin_type_void, builtin_type_char).
These are instances of type structs that roughly correspond to
fundamental types and are created as global types for GDB to
use for various ugly historical reasons. We eventually want to
eliminate these. Note for example that builtin_type_int
initialized in `gdbtypes.c' is basically the same as a
TYPE_CODE_INT type that is initialized in `c-lang.c' for
an FT_INTEGER fundamental type. The difference is that the
builtin_type is not associated with any particular objfile, and
only one instance exists, while `c-lang.c' builds as many
TYPE_CODE_INT types as needed, with each one associated with
some particular objfile.
이것들은 기본 타입과 관련되는 타입 구조 객체이며 다양한 역사적인 이유로 사용되는 GDB
전역 타입처럼 만들어진다. 결국 우리는 이것들을 줄이길 원한다. `gdbtypes.c'에서
초기화되는 builtin_type_int는 기본적으로 FT_INTEGER 기본 타입을
위해 `c-lang.c'에서 초기화되는 TYPE_CODE_INT 타입과 같다.
다른 점은 builtin_type는 어떤 특정 objfile과 관련이 없으며 단지 객체만 존재하고,
반면에 `c-lang.c'는 몇몇 특정 objfile과 관련될때마다 필요한
TYPE_CODE_INT 타입 만큼 만든다.
The a.out format is the original file format for Unix. It
consists of three sections: text, data, and bss,
which are for program code, initialized data, and uninitialized data,
respectively.
a.out 형식은 Unix의 원 파일 형식이다.
이 형식은 세 섹션으로 이루어져 있다:text, data, 그리고 bss,
각각은 프로그램 코드, 초기화된 데이터, 초기화되지 않은 데이터이다.
The a.out format is so simple that it doesn't have any reserved
place for debugging information. (Hey, the original Unix hackers used
`adb', which is a machine-language debugger!) The only debugging
format for a.out is stabs, which is encoded as a set of normal
symbols with distinctive attributes.
a.out 형식은 매우 단순하며 디버깅 정보를 위한 장소를 유지하지 않는다.
(원래 Unix 해커는 기계-언어 디버거인 `adb'를 사용한다.)
a.out를 위한 디버깅 형식은 stab이며 이것은 구별적인 특성을 가지는 보통의 심볼
집합처럼 인코딩된다.
The basic a.out reader is in `dbxread.c'.
기본적인 a.out 리더는 `dbxread.c'에 있다.
The COFF format was introduced with System V Release 3 (SVR3) Unix. COFF files may have multiple sections, each prefixed by a header. The number of sections is limited.
COFF 형식은 System V Release 3(SVR3) Unix에서 소개되었다. COFF 파일은 여러 섹션을 가지고 있으며 각각 헤더가 접두사로 놓인다. 섹션의 수는 제한되어 있다.
The COFF specification includes support for debugging. Although this was a step forward, the debugging information was woefully limited. For instance, it was not possible to represent code that came from an included file.
COFF 명세서는 디버깅 지원을 포함한다. 비록 이것이 앞 단계라 해도, 디버깅 정보는 제한되어 있다. 예를들어, 포함된 파일에서 온 코드를 나타내는것은 가능하지 않다.
The COFF reader is in `coffread.c'.
COFF 리더는 `coffread.c'에 있다.
ECOFF is an extended COFF originally introduced for Mips and Alpha workstations.
ECOFF는 Mips와 Alpha workstation을 위해 소개된 확장된 COFF이다.
The basic ECOFF reader is in `mipsread.c'.
기본 ECOFF 리더는 `mipsread.c'에 있다.
The IBM RS/6000 running AIX uses an object file format called XCOFF.
The COFF sections, symbols, and line numbers are used, but debugging
symbols are dbx-style stabs whose strings are located in the
.debug section (rather than the string table). For more
information, see section `Top' in The Stabs Debugging Format.
IBM RS/6000에서 돌아가는 AIX는 XCOFF라 불리는 객체 파일 형식을 사용한다.
COFF 섹션, 심볼 그리고 라인 넘버는 사용된다. 그러나 디버깅 심볼은 문자열이 .debug
섹션(문자열 테이블 보다는)에 위치하는 dbx 스타일 stab이다.
더 많은 정보를 위해 The Stabs Debugging Format의 'Top' 섹션을 참조해라.
The shared library scheme has a clean interface for figuring out what shared libraries are in use, but the catch is that everything which refers to addresses (symbol tables and breakpoints at least) needs to be relocated for both shared libraries and the main executable. At least using the standard mechanism this can only be done once the program has been run (or the core file has been read).
공유 라이브러리 구조는 공유 라이브러리가 사용되는 방법을 이해하기 위한 간편한 인터페이스를 가지고 있지만 catch는 주소를 참조하는 모든 것은 공유 라이브러리와 메인 실행을 위해 재할당할 필요가 있는 것이다. 적어도, 이렇게 할수 있는 표준 메카니즈의 사용은 돌아가는(또는 코어 파일을 읽는다.) 프로그램에서 행해진다.
Windows 95 and NT use the PE (Portable Executable) format for their executables. PE is basically COFF with additional headers.
Window 95와 NT는 실행을 위해 PE(Portable Executable) 형식을 사용한다. PE는 추가적인 헤더를 가지는 COFF이다.
While BFD includes special PE support, GDB needs only the basic COFF reader.
BFD가 특별한 PE 지원을 포함하는 반면, GDB는 기본 COFF 리더만이 필요하다.
The ELF format came with System V Release 4 (SVR4) Unix. ELF is similar to COFF in being organized into a number of sections, but it removes many of COFF's limitations.
ELF 형식은 System V Release 4(SVR4) 유닉스에서 왔다. ELF는 섹션수로 조직화되는 COFF와 비슷하지만 COFF의 제한 값을 제거하였다.
The basic ELF reader is in `elfread.c'.
기본 ELF 리더는 `elfread.c'에 있다.
SOM is HP's object file and debug format (not to be confused with IBM's SOM, which is a cross-language ABI).
SOM은 HP의 객체 파일이며 디버깅 형식(cross 언어 ABI인 IBM의 SOM과 혼동하지 마라.)이다.
The SOM reader is in `hpread.c'.
SOM 리더는 `hpread.c'에 있다.
Other file formats that have been supported by GDB include Netware Loadable Modules (`nlmread.c').
GDB가 지원하는 다른 파일 형식은 Netware Loadable Modules(`nlmread.c')을 포함한다.
This section describes characteristics of debugging information that are independent of the object file format.
이 섹션은 독립적인 객체 파일 형식의 디버깅 정보의 특성을 기술한다.
stabs started out as special symbols within the a.out
format. Since then, it has been encapsulated into other file
formats, such as COFF and ELF.
stabs는 a.out 형식내 특별한 심볼처럼 시작한다.
그렇기 때문에, COFF나 ELF 처럼 다른 파일 형식으로 캡슐화된다.
While `dbxread.c' does some of the basic stab processing, including for encapsulated versions, `stabsread.c' does the real work.
`dbxread.c'가 캡슐화된 버전을 포함하여 기본 stab 처리를 하는 동안, `stabsread.c'는 실제 작업을 한다.
The basic COFF definition includes debugging information. The level of support is minimal and non-extensible, and is not often used.
기본 COFF 정의는 디버깅 정보를 포함한다. 지원 레벨은 최소이고 비 확장이며 자주 사용되지 않는다.
ECOFF includes a definition of a special debug format.
ECOFF는 특별한 디버깅 형식의 정의를 포함한다.
The file `mdebugread.c' implements reading for this format.
파일 `mdebugread.c'는 이 형식을 위한 읽기를 수행한다.
DWARF 1 is a debugging format that was originally designed to be used with ELF in SVR4 systems.
DWARF 1은 SVR4 시스템에서 ELF와 함께 사용하기 위해 디자인된 디버깅 형식이다.
The DWARF 1 reader is in `dwarfread.c'.
DWARF 1 리더는 `dwarfread.c'에 있다.
DWARF 2 is an improved but incompatible version of DWARF 1.
DWARF 2는 향샹되었지만 DWARF 1과는 호환되지 않는다.
The DWARF 2 reader is in `dwarf2read.c'.
DWARF 2 리더는 `dwarf2read.c'에 있다.
Like COFF, the SOM definition includes debugging information.
COFF 처럼, SOM 정의는 디버깅 정보를 포함한다.
If you are using an existing object file format (a.out, COFF, ELF, etc),
there is probably little to be done.
만일 여러분이 존재하는 객체 파일 형식(a.out, COFF, ELF 등)을 사용한다면,
해야할것이 아마도 거의 없다.
If you need to add a new object file format, you must first add it to BFD. This is beyond the scope of this document.
만일 여러분이 새로운 객체 파일 형식을 추가할 필요가 있다면, 여러분은 우선 BFD에 추가해야 한다. 이것은 이 문서의 범위를 넘어선다.
You must then arrange for the BFD code to provide access to the debugging symbols. Generally GDB will have to call swapping routines from BFD and a few other BFD internal routines to locate the debugging information. As much as possible, GDB should not depend on the BFD internal data structures.
여러분은 디버깅 심볼에 접근을 제공하기 위해 BFD 코드를 재배열해야 한다. 일반적으로 GDB는 BFD에서 swap 루틴을 호출하고 디버깅 정보를 찾기 위해 다른 BFD 내부 루틴을 호출한다. 가능한 많이, GDB는 BFD 내부 데이터 구조에 의존하지 않아야 한다.
For some targets (e.g., COFF), there is a special transfer vector used to call swapping routines, since the external data structures on various platforms have different sizes and layouts. Specialized routines that will only ever be implemented by one object file format may be called directly. This interface should be described in a file `bfd/libxyz.h', which is included by GDB.
몇몇 타겟(e.g., COFF)를 위해, swap 루틴 호출시 사용하는 특별한 전송 벡터가 있다. 왜냐하면 다양한 플랫폼에서 내부 데이터 구조는 다른 크기와 레이아웃을 가지고 있기 때문이다. 한 객체 파일 형식에 의해서 수행되는 특정 루틴들은 직접 호출된다. 이 인터페이스는 GDB에 포함된 `bfd/libxyz.h' 파일내에 기술되어야 한다.
Go to the first, previous, next, last section, table of contents.