Go to the first, previous, next, last section, table of contents.

Coding

코딩

This chapter covers topics that are lower-level than the major algorithms of GDB.

이 장은 GDB의 주요 알고리즘보다 더 하위 레벨 주제들에 대해 다룬다.

Cleanups

Cleanups are a structured way to deal with things that need to be done later. When your code does something (like malloc some memory, or open a file) that needs to be undone later (e.g., free the memory or close the file), it can make a cleanup. The cleanup will be done at some future point: when the command is finished, when an error occurs, or when your code decides it's time to do cleanups.

Cleanup은 나중에 할 필요가 있는 것들을 다루기 위한 구조화된 방법이다. 여러분의 코드가 나중에(e.g., 메모리를 free 하거나 file을 닫거나)할 필요가 없는 것(e.g., 메모리를 malloc 하거나 file을 열거나)을 할때, 그것은 cleanup을 만들수 있다. cleanup은 몇몇 미래 시점에서 행해진다; 명령어를 마쳤을때, 에러가 일어날때, 코드가 cleanup을 해야할때라고 결정할때.

You can also discard cleanups, that is, throw them away without doing what they say. This is only done if you ask that it be done.

여러분은 cleanup을 버릴수 있다. 즉, 말하는 것을 하는것 없이 쫒아 버릴수 있따. 이것은 만일 여러분이 해야하는것을 물어본다면 행해진다.

Syntax:

문법:

struct cleanup *old_chain;

Declare a variable which will hold a cleanup chain handle.

cleanup chain 핸들을 가지는 변수를 선언한다.

old_chain = make_cleanup (function, arg);

Make a cleanup which will cause function to be called with arg (a char *) later. The result, old_chain, is a handle that can be passed to do_cleanups or discard_cleanups later. Unless you are going to call do_cleanups or discard_cleanups yourself, you can ignore the result from make_cleanup.

나중에 arg (a char *)와 함께 호출되는 function를 야기하는 cleanup을 만든다. 그 결과 old_chain은 do_cleanups나 discard_cleanups에 전달될수 있는 핸들이다. 만일 여러분이 do_cleanups나 discard_cleanups를 호출하지 않는다면, 여러분은 make_cleanup에서의 결과를 무시할수 있다.

do_cleanups (old_chain);

Perform all cleanups done since make_cleanup returned old_chain. E.g.:

모든 cleanup을 한다. 왜냐하면 make_cleanup가 old_chain를 반환하기 때문이다. E.g.:

make_cleanup (a, 0); 
old = make_cleanup (b, 0); 
do_cleanups (old);

will call b() but will not call a(). The cleanup that calls a() will remain in the cleanup chain, and will be done later unless otherwise discarded.

b()는 호출하지만 a()는 호출하지 않는다. a()를 호출하는 cleanup은 cleanup chain에 남아 있으며 버려지지 않는다면 나중에 행해진다.

discard_cleanups (old_chain);

Same as do_cleanups except that it just removes the cleanups from the chain and does not call the specified functions.

chain에서 cleanup을 제거하고 지정된 함수를 호출하지 않는다는 점을 제외하고 do_cleanups와 같다.

Some functions, e.g. fputs_filtered() or error(), specify that they "should not be called when cleanups are not in place". This means that any actions you need to reverse in the case of an error or interruption must be on the cleanup chain before you call these functions, since they might never return to your code (they `longjmp' instead).

몇몇 함수, e.g. fputs_filtered() 나 error()는 "cleanup이 제자리에 있지 않을때 호출되어서는 안된다"는 것을 가리킨다. 이것은 에러나 인터럽션의 경우 거꾸로되 필요가 있는 행동은 여러분이 이들 함수를 호출하기 전에 cleanup chain에 있어야 한다. 왜냐하면 그것들은 코드에서 반환하지 않기 때문이다.(대신에 `longjmp')

Wrapping Output Lines

Output Lines 싸기

Output that goes through printf_filtered or fputs_filtered or fputs_demangled needs only to have calls to wrap_here added in places that would be good breaking points. The utility routines will take care of actually wrapping if the line width is exceeded.

printf_filtered나 fputs_filtered, fputs_demangled를 통해 가는 출력은 좋은 break 지역이 곳에 추가되어 wrap_here를 호출할때만 필요하다. utility 루틴은 만일 라인 폭이 초과된다면 실제 wrapping으로 다뤄어진다.

The argument to wrap_here is an indentation string which is printed only if the line breaks there. This argument is saved away and used later. It must remain valid until the next call to wrap_here or until a newline has been printed through the *_filtered functions. Don't pass in a local variable and then return!

wrap_here에 대한 인자는 만일 라인이 거기서 break된다면 출력되는 들여쓰여진 문자열이다. 이 인자는 저장되고 나중에 불려진다. wrap_here에 대한 다음 호출이나 뉴 라인이 *_filtered 함수를 통해 출력될대까지 유효하게 유지되어야 한다. 지역변수에 전달하지 마라. 그리고 반환하지 마라.

It is usually best to call wrap_here after printing a comma or space. If you call it before printing a space, make sure that your indentation properly accounts for the leading space that will print if the line wraps there.

콤마나 스페이스 출력후 wrap_here를 호출하는것이 가장 좋다. 만일 여러분이 스페이스 출력전에 호출한다면, 들여쓰기는 만일 라인이 레핑된다면 출력될 선행 스페이스를 설명한다는 점을 확실히 해라.

Any function or set of functions that produce filtered output must finish by printing a newline, to flush the wrap buffer, before switching to unfiltered (printf) output. Symbol reading routines that print warnings are a good example.

어떤 함수나 필터된 출력을 만드는 함수 집합은 wrap buffer를 비우기 위해 필터되지 않은(printf) 출력으로 바뀌기 전에 newline 출력시 끝나야 한다. 경고를 출력하는 심볼 읽기 루틴이 좋은 예이다.

`GDB Coding Standards`


GDB 코딩 표준





GDB follows the GNU coding standards, as described in
`etc/standards.texi'.  This file is also available for anonymous
ftp From GNU archive sites.  GDB takes a strict interpretation of the
standard; in general, when the GNU standard recommends a practice but
does not require it, GDB requires it.


GDB는 `etc/standards.texi'에서 기술한 것처럼, GNU 코딩 표준을 따른다.
이 파일은 GNU archive site에서 anonymous ftp를 통해 이용할수 있다.
GDB는 표준의 엄격한 해석을 가진다.; 일반적으로, GNU 표준은 실제적인것을 추천하지만 그것을 요구하지는 않지만, GDB는 이것을 요구한다.


GDB follows an additional set of coding standards specific to
GDB, as described in the following sections.


GDB는 다음 섹션에서 기술한 것처럼, GDB에 추가적으로 특정 코딩 표준집합을 허용한다.



You can configure with `--enable-build-warnings' or
`--enable-gdb-build-warnings' to get GCC to check on a number of
these rules.  GDB sources ought not to engender any complaints,
unless they are caused by bogus host systems.  (The exact set of enabled
warnings is currently `-Wimplicit -Wreturn-type -Wcomment
-Wtrigraphs -Wformat -Wparentheses -Wpointer-arith -Wuninitialized'.


여러분은 이 규칙의 수를 검사하도록 GCC를 가지기 위해 `--enable-build-warnings' 또는 `--enable-gdb-build-warnings'를 가지고 설정할수 있다.
GDB 소스는 만일 가상 호스트 시스템에 의해 야기되지 않는다면, 어떤 불평도 하지 않는다. (가능한 정확한 경고 집합은 현재 `-Wimplicit -Wreturn-type -Wcomment
-Wtrigraphs -Wformat -Wparentheses -Wpointer-arith -Wuninitialized'이다.



Formatting
형식



The standard GNU recommendations for formatting must be followed
strictly.

형식을 위한 표준 GNU 추천은 엄격히 따랴야 한다.


Note that while in a definition, the function's name must be in column
zero; in a function declaration, the name must be on the same line as
the return type.


정의에서, 함수 명은 column zero에 있어야 한다.; 함수 선언에서, 이름은 반환
타입과 같은 라인에 있어야 한다.



In addition, there must be a space between a function or macro name and
the opening parenthesis of its argument list (except for macro
definitions, as required by C).  There must not be a space after an open
paren/bracket or before a close paren/bracket.


게다가, 함수나 매크로 이름과 인자 리스트의 열린 가로사이에는 스페이스가
있어야 한다.(C에서 요구한 것처럼, 매크로 정의를 제외하고).
열린 괄호/bracket 다음과 닫힌 paren/bracket 전에는 스페이스가 있어서는
안된다.


While additional whitespace is generally helpful for reading, do not use
more than one blank line to separate blocks, and avoid adding whitespace
after the end of a program line (as of 1/99, some 600 lines had whitespace
after the semicolon).  Excess whitespace causes difficulties for
diff and patch utilities.


추가적인 whitespace는 일반적으로 읽기를 도와주지만, block을 분리하기 위해
하나 이상의 빈라인을 사용하지 마라. 그리고 프로그램 라인 끝 다음에는
whitespace를 추가하는것을 피해라.(99/1처럼, 몇몇 600 라인들은
세미콜론 다음에 whitespace를 가진다.) 과도한 whitespace는 diff와
patch 유틸리티에 어려움을 야기한다.


Comments
주석



The standard GNU requirements on comments must be followed strictly.


주석에서 표준 GNU 요구사항는 엄격히 따랴야 한다.



Block comments must appear in the following form, with no `/*'- or
`*/'-only lines, and no leading `*':


Block 주석은 다음 형태로 나타나야 하며, 라인당 `/*'나 `*/'를 하지 않고 앞에 `*'도 하지 않는다:





/* Wait for control to return from inferior to debugger.  If inferior
   gets a signal, we may decide to start it up again instead of
   returning.  That is why there is a loop in this function.  When
   this function actually returns it means the inferior should be left
   stopped and GDB should read more commands.  */



(Note that this format is encouraged by Emacs; tabbing for a multi-line
comment works correctly, and M-q fills the block consistently.)


(이 형식은 Emacs에서 추천하고 있따; 다중 라인 tabbing은 잘 작동하며 M-q는 일관성 있게 블럭을 채운다.)



Put a blank line between the block comments preceding function or
variable definitions, and the definition itself.


선행 함수나 변수 정의에 대한 block 주석과 정의 사이에 blank 라인을 넣어라.



In general, put function-body comments on lines by themselves, rather
than trying to fit them into the 20 characters left at the end of a
line, since either the comment or the code will inevitably get longer
than will fit, and then somebody will have to move it anyhow.


일반적으로, 그것들을 라인 끝에서 20 문자를 남겨놓은 곳에 맞출려고 하는것보다는, 
라인위에 function-body 주석을 넣어라. 왜냐하면 주석이나 코드는 맞추는 것 이상으로 더 길어지기 때문이다. 그리고 누군가가 어떻게든 그것을 옮길 것이다.



C Usage
C 사용법



Code must not depend on the sizes of C data types, the format of the
host's floating point numbers, the alignment of anything, or the order
of evaluation of expressions.


Code는 C 데이터 타입의 크기와 호스트 부동 소수점 수의 형식, 정렬 또는 표현식의
순서에 의존하지 않는다.




Use functions freely.  There are only a handful of compute-bound areas
in GDB that might be affected by the overhead of a function
call, mainly in symbol reading.  Most of GDB's performance is
limited by the target interface (whether serial line or system call).


함수는 자유스럽게 사용해라. 주소 심볼 읽기시, 함수 호출의 오버헤드로 영향을 받는 것은 
GDB내 경계 영역 계산만이다.
대부분의 GDB 성능은 타겟 인터페이스에 제한된다.(시리얼 라인이나 시스템 콜)


However, use functions with moderation.  A thousand one-line functions
are just as hard to understand as a single thousand-line function.


그러나, 함수는 적절히 사용해라. 천개의 한 라인 함수는 한개의 천라인 함수만큼 이해하기
어렵다.



Function Prototypes
함수 원형



Prototypes must be used to declare functions, and may be used
to define them.  Prototypes for GDB functions must
include both the argument type and name, with the name matching that
used in the actual function definition.


Prototypes은 함수를 선언하기 위해 사용되며 그것들을 정의하기 위해 사용된다.
GDB 함수를 위한 Prototype은 실제 함수 정의시 사용되는 이름과 일치되는 인자 타입과 이름을 포함해야 한다.


All external functions should have a declaration in a header file that
callers include, except for _initialize_* functions, which must
be external so that `init.c' construction works, but shouldn't be
visible to random source files.


모든 외부 함수들은  _initialize_* 함수를 제외하고, 호출자가 포함하는 헤더 파일내 선언되어야 한다. 이 함수들은 `init.c' 생성자는 작동하는 external 이어야 하지만
임의의  소스 파일을 보아서는 안된다.


All static functions must be declared in a block near the top of the
source file.


모든 static 함수들은 소스 파일의 탑 근처에 블럭에 선언되어야 한다.



Clean Design and Portable Implementation
깔끔한 디자인과 호환 가능한 수행



In addition to getting the syntax right, there's the little question of
semantics.  Some things are done in certain ways in GDB because long
experience has shown that the more obvious ways caused various kinds of
trouble.


옳은 문법을 가지는것 이외에, 의미론에는 거의 의문 사항이 없다.
일부는 GDB에서 확실한 방법으로 행해진다. 왜냐하면 오래된 경험은 명백한 방법이 여러 종류의
문제를 야기한다는것을 보여주기 때문이다.




You can't assume the byte order of anything that comes from a target
(including values, object files, and instructions).  Such things
must be byte-swapped using SWAP_TARGET_AND_HOST in
GDB, or one of the swap routines defined in `bfd.h',
such as bfd_get_32.


여러분은 타겟(value, 객체 파일, 명령어를 포함하여)에서의 바이트 순서를 가정할수 없다. 그러한 것은 GDB내 SWAP_TARGET_AND_HOST를 사용하여 byte-swap이어야 하든지 bfd_get_32처럼 `bfd.h'에
정의되어 있는 swap routine중 하나이어야 한다.


You can't assume that you know what interface is being used to talk to
the target system.  All references to the target must go through the
current target_ops vector.


여러분은 어떤 인터페이스가 타겟 시스템과 얘기할때 사용되는지를 안다고 가정할수 없다.
타겟 시스템에 대한 모든 참조는 현재 target_ops를 통해야 한다.


You can't assume that the host and target machines are the same machine
(except in the "native" support modules).  In particular, you can't
assume that the target machine's header files will be available on the
host machine.  Target code must bring along its own header files --
written from scratch or explicitly donated by their owner, to avoid
copyright problems.


여러분은 호스타와 타겟 머신이 같은 머신이라고 가정할수 없다.("native" 지원 모듈을 
제외하고) 특별히, 여러분은 타겟 머신 헤더 파일은 호스트 머신에서 이용할수 있는것으로
가정할수 없다. 타겟 코드는 자신의 헤더파일을 가져야 한다.--copyright 문제를 피하기 위해,
scratch나 소유자가 기증한 헤더 파일.





Insertion of new #ifdef's will be frowned upon.  It's much better
to write the code portably than to conditionalize it for various
systems.


새로운 #ifdef의 삽입은 좋지 않다. 다양한 시스템을 위해 그것을 조건화 하는것보다
코드를 호환성 있게 쓰는것이 더 좋다.




New #ifdef's which test for specific compilers or manufacturers
or operating systems are unacceptable.  All #ifdef's should test
for features.  The information about which configurations contain which
features should be segregated into the configuration files.  Experience
has proven far too often that a feature unique to one particular system
often creeps into other systems; and that a conditional based on some
predefined macro for your current system will become worthless over
time, as new versions of your system come out that behave differently
with regard to this feature.


특정 컴파일러나 제조 업자나 오퍼레이팅을 테스트하는 새로운 #ifdef는 
받아들일수 없다. 모든 #ifdef은 특징들을 위해 검사되어야 한다. 
특징들을 포함하는 설정 사항에 관한 정보는 설정 파일들로 나누어져야 한다.
지금까지의 경험은 특정 시스템에서 유일한 특징은 다른 시스템에서는 어긋날수 있다는 것을 증명해준다.; 그리고 시스템을 위한 기정의 매크로 기반 조건들은
시간이 지남에 따라 가치가 없어질수 있다. 왜냐하면 시스템의 새로운 버전은 이 특징에
따라서 다르게 행동할수 있기 때문이다.




Adding code that handles specific architectures, operating systems,
target interfaces, or hosts, is not acceptable in generic code.  If a
hook is needed at that point, invent a generic hook and define it for
your configuration, with something like:


특정 아키텍쳐, OS, 타겟 인터페이스나 호스트를 핸들링하는 코드를 추가하는것은
일반적인 코드에서는 받아들여지지 않는다.
만일 훅이 그시점에서 필요하다면, 일반적 훅을 만들고 다음과 같이 설정에 그것을 정의해라.:



#ifdef	WRANGLE_SIGNALS
   WRANGLE_SIGNALS (signo);
#endif



In your host, target, or native configuration file, as appropriate,
define WRANGLE_SIGNALS to do the machine-dependent thing.  Take a
bit of care in defining the hook, so that it can be used by other ports
in the future, if they need a hook in the same place.


호스트, 타겟 또는 native 설정 파일에서, 적당히 머신 의존적인 것을 할때는 
WRANGLE_SIGNALS를 정의해라. 훅 정의시 주의해라. 만일 같은 곳에 훅이 필요하다면,
왜냐하면 그것은 미래에 다른 포트에서 사용될수 있기 때문이다.


If the hook is not defined, the code should do whatever "most" machines
want.  Using #ifdef, as above, is the preferred way to do this,
but sometimes that gets convoluted, in which case use


만일 훅이 정의되지 않았다면, 코드는 대부분의 머신이 원하는것은 무엇이든 해야 한다.
위처럼 #ifdef를 사용하는 것은 이것을 하는데 더 좋은 방법이다. 그러나
가끔 뒤얽힐수 있다.



#ifndef SPECIAL_FOO_HANDLING
#define SPECIAL_FOO_HANDLING(pc, sp) (0)
#endif



where the macro is used or in an appropriate header file.


매크로가 사용된 곳이나 적당한 헤더 파일내.


Whether to include a small hook, a hook around the exact pieces of
code which are system-dependent, or whether to replace a whole function
with a hook, depends on the case.  A good example of this dilemma can be
found in get_saved_register.  All machines that GDB 2.8 ran on
just needed the FRAME_FIND_SAVED_REGS hook to find the saved
registers.  Then the SPARC and Pyramid came along, and
HAVE_REGISTER_WINDOWS and REGISTER_IN_WINDOW_P were
introduced.  Then the 29k and 88k required the GET_SAVED_REGISTER
hook.  The first three are examples of small hooks; the latter replaces
a whole function.  In this specific case, it is useful to have both
kinds; it would be a bad idea to replace all the uses of the small hooks
with GET_SAVED_REGISTER, since that would result in much
duplicated code.  Other times, duplicating a few lines of code here or
there is much cleaner than introducing a large number of small hooks.


시스템 의존적인 정확한 코드 조각 주위의 작은 훅을 포함하든지 훅을 가진 전체 함수를
대체하든지 경우에 의존적이다. 이 딜레마의 좋은 예는 get_saved_register에서
발견될수 있따. GDB 2.8가 돌아가는 모든 머신은 저장된 레지스터를 발견하기 위해 
FRAME_FIND_SAVED_REGS 훅이 필요하다.
그리고 SPARC과 Pyramid는 독자적으로 왔고 HAVE_REGISTER_WINDOWS과 REGISTER_IN_WINDOW_P는 소개되었다.
그리고 29k와 88k는 GET_SAVED_REGISTER 훅을 요구한다. 처음 3개는 작은 훅의
예제이다; 나중은 전체 함수로 바뀌었다. 특별한 경우에, 두 종류를 가지는 것이 유용하다.;
GET_SAVED_REGISTER을 가지는 작은 훅을 사용하는 모두를 바꾸는 것은 좋지 않은
생각이다. 왜냐하면 그것은 대부분 중복된 코드 결과이기 때문이다. 다른 때, 여기 저기에서
중복된 라인들은 많은 수의 작은 훅을 소개하는것보다 더 명백하다.




One particularly notorious area where system dependencies tend to
creep in is handling of file names.  The mainline GDB code
assumes Posix semantics of file names: absolute file names begin with
a forward slash `/', slashes are used to separate leading
directories, case-sensitive file names.  These assumptions are not
necessarily true on non-Posix systems such as MS-Windows.  To avoid
system-dependent code where you need to take apart or construct a file
name, use the following portable macros:


특별히 시스템 의존성이 문제가 생기기 쉬운 영역은 파일 이름 핸들링이다.
GDB 코드는 Posix 의미의 파일이름으로 가정한다.;절대 파일 이름은 `/'로 시작하며,
슬래쉬는 선행 디렉토리에 사용되며, case-sensitive 파일명이다.
이러한 가정은 MS-Windows같이 비-Posix 시스템에서는 사실이 아니다.
시스템 의존적인 코드를 피하기 위해, 여러분은 파일 이름을 분해하거나 만들어야 할 필요가
있으며, 다음처럼 호환 가능한 매크로를 사용해라.




HAVE_DOS_BASED_FILE_SYSTEM


 
This preprocessing symbol is defined to a non-zero value on hosts
whose filesystems belong to the MS-DOS/MS-Windows family.  Use this
symbol to write conditional code which should only be compiled for
such hosts.


이 프리프로세싱 심볼은 파일 시스템이 MS-DOS/MS-Windows 계열에 속하는 호스트의 경우에
비 zero로 정의되어 있다.
그러한 호스트에서 컴파일 되어야하는 조건적 코드를 쓰기 위해 이 심볼을 사용해라.


IS_DIR_SEPARATOR (c

Evaluates to a non-zero value if c is a directory separator
character.  On Unix and GNU/Linux systems, only a slash `/' is
such a character, but on Windows, both `/' and `\' will
pass.


만일  c가 디렉토리 분리 문자이면 non-zero로 평가된다.
Unix와 GNU/Linux 시스템에서, 슬래쉬 `/'는 그런 문자이며, Windows에서는
`/'와 `\' 모두 통과된다.


IS_ABSOLUTE_PATH (file)

Evaluates to a non-zero value if file is an absolute file name.
For Unix and GNU/Linux hosts, a name which begins with a slash
`/' is absolute.  On DOS and Windows, `d:/foo' and
`x:\bar' are also absolute file names.


만일 file이 절대 파일이름 이라면 non-zero로 평가된다.
Unix와 GNU/Linux 호스트에서, 슬래쉬 `/'로 시작하는 이름은 절대적이다.
DOS와 Window에서, `d:/foo'와 `x:\bar'는 역시 절대 파일이름이다.


FILENAME_CMP (f1, f2)

Calls a function which compares file names f1 and f2 as
appropriate for the underlying host filesystem.  For Posix systems,
this simply calls strcmp; on case-insensitive filesystems it
will call strcasecmp instead.


호스트 파일시스템에 근거하여 파일 이름 f1과 f2를 비교하는 함수를
호출한다.
Posix 시스템에서, 이것은 단순히 strcmp를 호출한다.; case-insensitive 파일
시스템에서는 대신에 strcasecmp를 호출한다.


DIRNAME_SEPARATOR

Evaluates to a character which separates directories in
PATH-style lists, typically held in environment variables.
This character is `:' on Unix, `;' on DOS and Windows.


PATH 스타일 리스트내 디렉토리를 분리하는 문자를 평가하며 전형적으로
환경 변수에서 가져온다.
이 문자는 Unix에서 `:'이고, DOS와 Windows에서 `;'이다.


SLASH_STRING

This evaluates to a constant string you should use to produce an
absolute filename from leading directories and the file's basename.
SLASH_STRING is "/" on most systems, but might be
"\\" for some Windows-based ports.

이것은 여러분이 선행 디렉토리와 파일 기본 이름에서 절대 파일 이름을 만들기 위해 사용해야 하는 상수 문자열을 평가한다.
SLASH_STRING는 대부분의 시스템에서 "/"이지만, 몇몇
Window 기반 포트에서 "\\"이다.



In addition to using these macros, be sure to use portable library
functions whenever possible.  For example, to extract a directory or a
basename part from a file name, use the dirname and
basename library functions (available in libiberty for
platforms which don't provide them), instead of searching for a slash
with strrchr.


이들 매크로를 사용하는것 위에, 가능할때는 언제나 호환가능한 라이브러리 함수를 사용해야 한다.
예를 들어, 디렉토리 인용이나 파일 이름에서 기본이름을 분리하기 위해 strrchr를
가지고 슬래쉬를 찾는것 대신에 dirname와 basename 라이브러리 함수
(그것들을 제공하지 않는 플랫폼을 위해서 libiberty에서 이용가능하다.)를 사용해라. 



Another way to generalize GDB along a particular interface is with an
attribute struct.  For example, GDB has been generalized to handle
multiple kinds of remote interfaces--not by #ifdefs everywhere, but
by defining the target_ops structure and having a current target (as
well as a stack of targets below it, for memory references).  Whenever
something needs to be done that depends on which remote interface we are
using, a flag in the current target_ops structure is tested (e.g.,
target_has_stack), or a function is called through a pointer in the
current target_ops structure.  In this way, when a new remote interface
is added, only one module needs to be touched--the one that actually
implements the new remote interface.  Other examples of
attribute-structs are BFD access to multiple kinds of object file
formats, or GDB's access to multiple source languages.


특정 인터페이스에 따라 GDB를 일반화 하기 위한 다른 방법은 구초체 속성이다.
예를 들어, GDB는 여러 종류의 원격 인터페이스를 처리하기위해 일반화되어 있다.--
모든 곳에서 #ifdef가 아니고, target_ops 구조체를 정의하고
현재 타겟을 가진다.(메모리 참조를 위해, 타겟의 스택은 그것 아래에도)
원격 인터페이스에 의존할 필요가 있을때는 언제나, 우리는 현재 target_ops structure의
플래그를 검사하거나 현재 target_ops structure내 포인터를 호출할때 함수를 사용한다.
이런 방법으로, 새로운 원격 인터페이스가 추가될때, 건드려야 하는 유일한 모듈은 새로운 
원격 인터페이스를 실제 수행하는 모듈이다.
속성-struct의 다른 예제는 여러 종류의 객체파일 형식에 대한 BFD 접근이나 여러 소스 언어에
대한 GDB 접속이다.



Please avoid duplicating code.  For example, in GDB 3.x all
the code interfacing between ptrace and the rest of
GDB was duplicated in `*-dep.c', and so changing
something was very painful.  In GDB 4.x, these have all been
consolidated into `infptrace.c'.  `infptrace.c' can deal
with variations between systems the same way any system-independent
file would (hooks, #if defined, etc.), and machines which are
radically different don't need to use `infptrace.c' at all.


중복 코드를 피해라. 예를 들어, GDB 3.x에서 ptrace와 GDB의 나머지에서의
모든 코드 인터페이스는 `*-dep.c'에 중복되며 그래서 바꾸는 것은 매우 고통스럽다.
GDB 4.x에서, 이것들은 모두 `infptrace.c'로 합쳐졌다.
`infptrace.c'는 시스템 독립적인 파일이훅, #if defined 등) 합쳐지는 시스템 사이의 변종을 다루며 근본적으로 다른 머신들은 모두 `infptrace.c'를 사용할 필요가 없다.



Don't put debugging printfs in the code.



Go to the first, previous, next, last section, table of contents.