Check the `README' file, it often has useful information that does not appear anywhere else in the directory.
`README' 파일을 체크해라. 이 파일은 디렉토리내 그 밖의 내용에서는 보이지 않는 유용한 정보를 가지고 있다.
GDB is a large and complicated program, and if you first starting to work on it, it can be hard to know where to start. Fortunately, if you know how to go about it, there are ways to figure out what is going on.
GDB는 크고 복잡한 프로그램이며 만일 GDB를 시작한다면, 어디서 시작해야할지 알기 어렵다. 운좋게도, 만일 여러분이 GDB를 시작하는 방법을 안다면, 무엇을 해나가야 할지 이해하기 위한 방법이 있다.
This manual, the GDB Internals manual, has information which applies generally to many parts of GDB.
GDB Internal manual은 GDB의 많은 부분에 적용되는 정보가 있다.
Information about particular functions or data structures are located in comments with those functions or data structures. If you run across a function or a global variable which does not have a comment correctly explaining what is does, this can be thought of as a bug in GDB; feel free to submit a bug report, with a suggested comment if you can figure out what the comment should say. If you find a comment which is actually wrong, be especially sure to report that.
특별한 함수나 데이터 구조에 대한 정보는 이 함수들이나 데이터 구조 관련 주석에 있다. 만일 무엇을 하는지에 대한 정확한 주석을 가지고 있지 않는 함수나 전역 변수를 우연히 만난다면, 이것은 GDB내 버그로 생각할수 있다; 만일 주석이 말하는것이 무엇인지를 이해했다면 주석과 함께 버그 리포트를 부담없이 보내라. 만일 잘못된 주석을 발견한다면, 특히 주석 보고를 확실히 해라.
Comments explaining the function of macros defined in host, target, or native dependent files can be in several places. Sometimes they are repeated every place the macro is defined. Sometimes they are where the macro is used. Sometimes there is a header file which supplies a default definition of the macro, and the comment is there. This manual also documents all the available macros.
호스트, 타겟 또는 native 의존적인 파일들에 정의된 매크로 함수들을 설명하는 주석은 몇몇 장소에 있을수 있다. 가끔 이것들은 매크로가 정의된 모든 장소에서 반복된다. 가끔 매크로가 상용된곳에도 있다. 가끔 매크로의 기본 정의를 대신하는 헤더 파일이 잇으며 코멘트가 있다. 이 매뉴얼 역시 이용할수 있는 매크로 모두를 문서화했다.
Start with the header files. Once you have some idea of how GDB's internal symbol tables are stored (see `symtab.h', `gdbtypes.h'), you will find it much easier to understand the code which uses and creates those symbol tables.
헤더 파일로 시작해라. 일단 여러분이 GDB 내부 심볼 테이블이 저장(`symtab.h', `gdbtypes.h')되는 방법에 대한 몇가지 idea를 가지고 있다면, 사용된 코드를 이해하고 이 심볼 테이블을 만드는것이 쉽다는것을 발견할 것이다.
You may wish to process the information you are getting somehow, to enhance your understanding of it. Summarize it, translate it to another language, add some (perhaps trivial or non-useful) feature to GDB, use the code to predict what a test case would do and write the test case and verify your prediction, etc. If you are reading code and your eyes are starting to glaze over, this is a sign you need to use a more active approach.
여러분은 여러분이 이해하고 있는 것을 강화하기 위해 가지고 있는 정보를 처리하길 원할지 모른다. 요약해서, 그것을 다른 언어로 번역하고, GDB에 몇몇 특징을 추가하고, 테스트 경우가 무엇인지 예상되는 코드를 사용하고, 테스트 케이스를 적고, 예상을 검사해라. 만일 코드를 읽고 눈이 흐려지기 시작한다면, 이것은 더 적극적인 접근을 사용할 필요가 있다는 표시이다.
Once you have a part of GDB to start with, you can find more
specifically the part you are looking for by stepping through each
function with the next command. Do not use step or you
will quickly get distracted; when the function you are stepping through
calls another function try only to get a big-picture understanding
(perhaps using the comment at the beginning of the function being
called) of what it does. This way you can identify which of the
functions being called by the function you are stepping through is the
one which you are interested in. You may need to examine the data
structures generated at each stage, with reference to the comments in
the header files explaining what the data structures are supposed to
look like.
일단 시작시 GDB의 일부를 가지고 있다면, 여러분은 next 명령어로 각 함수를 step하며,
찾고자 하는 부분을 더 발견할수 있다.
step을 사용하지 마라. 그렇지 않으면 여러분은 어지러울 것이다;
다른 함수를 호출하여 stepping 하는 함수들은 이 함수들이 무엇을 하는지를 이해(호출되는
함수의 시작시 주석을 사용하여)할수 있도록 커다란 그림을 가지도록 해준다.
여러분이 stepping하는 함수에 의해 호출되는 함수가 어느것인지 인식할수 있는 방법은
여러부이 흥미로워하는 것이다. 여러분은 데이터 구조를 설명하는 헤더 파일내 주석에 대한
참조와 함께 각 단계에서 만들어지는 데이터 구조를 검사할 필요가 있다.
Of course, this same technique can be used if you are just reading the code, rather than actually stepping through it. The same general principle applies--when the code you are looking at calls something else, just try to understand generally what the code being called does, rather than worrying about all its details.
물론, 이 기술은 만일 여러분이 코드를 읽는다면 stepping하는 것이상으로 사용될수 있다. 일반적인 원리가 적용된다.--여러분이 찾는 코드가 무엇을 호출할때, 세부적인 모든것에 대해 걱정하기 보다는 호출된 코드가 무엇을 하는지 이해하도록 시도해라.
A good place to start when tracking down some particular area is with
a command which invokes that feature. Suppose you want to know how
single-stepping works. As a GDB user, you know that the
step command invokes single-stepping. The command is invoked
via command tables (see `command.h'); by convention the function
which actually performs the command is formed by taking the name of
the command and adding `_command', or in the case of an
info subcommand, `_info'. For example, the step
command invokes the step_command function and the info
display command invokes display_info. When this convention is
not followed, you might have to use grep or M-x
tags-search in emacs, or run GDB on itself and set a
breakpoint in execute_command.
몇몇 특별 영역을 쫒아갈때 시작할 좋은 위치는 그 특징을 호출하는 명령어에서부터이다.
여러분이 단일-stepping 작업을 하는 방법을 알기를 원한다고 가정하자.
GDB 사용자로써, 여러분은 단일 stepping을 위해 step 명령어를 알아야 한다.
명령어는 명령어 테이블(`command.h'를 참조해라.)을 통해 호출된다.;
명령어를 실행하는 함수는 명령어 이름과 `_command'나 info 명령어의
하위 명령어 경우로 `_info'로 구성되어 있다.
예를 들어, step 명령어는 step_command 함수를 호출하고 info
display 명령어는 display_info를 호출한다. 이 규약이 성립되지 않을때, 여러분은
grep이나 emacs에서 M-x tags-search, 또는 GDB를 돌리고 execute_command에 breakpoint를 설정한다.
If all of the above fail, it may be appropriate to ask for information
on bug-gdb. But never post a generic question like "I was
wondering if anyone could give me some tips about understanding
GDB"---if we had some magic secret we would put it in this manual.
Suggestions for improving the manual are always welcome, of course.
만일 위의 모든것이 다 실패한다면, bug-gdb에 정보를 요구해라. 그러나 "누가 GDB를
이해할수 있는 팁을 나에게 줄지 궁금하다"같은 일반적 질문은 하지 마라. -- 만일 우리가
커다란 비밀을 가지고 있다면, 이 매뉴얼에 넣을 것이다.
물론, 매뉴얼을 개선하는 작업은 언제나 환영한다.
If GDB is limping on your machine, this is the preferred way to get it fully functional. Be warned that in some ancient Unix systems, like Ultrix 4.2, a program can't be running in one process while it is being debugged in another. Rather than typing the command ./gdb ./gdb, which works on Suns and such, you can copy `gdb' to `gdb2' and then type ./gdb ./gdb2.
만일 GDB가 머신에서 느리다면, 완전히 기능적으로 가지는것이 더 좋은 방법이다. Ultrix 4.2 같은 몇몇 예전 Unix system에서, 프로세스는 한 프로세서에서 돌아가지 않는 반면 다른 프로세르로는 디버깅이 된다. 명령어 ./gdb ./gdb를 타이핑하는것보다는 여러분은 `gdb'를 `gdb2'로 복사하고 ./gdb ./gdb2 같이 타이핑해라.
When you run GDB in the GDB source directory, it will read a
`.gdbinit' file that sets up some simple things to make debugging
gdb easier. The info command, when executed without a subcommand
in a GDB being debugged by gdb, will pop you back up to the top level
gdb. See `.gdbinit' for details.
여러분이 GDB 소스 디렉토리에서 GDB를 돌린다면, gdb를 쉽게 디버깅하도록 만들기 위해
몇몇 간단한 것을 설정하는 `.gdbinit' 파일을 읽는다.
gdb가 디버깅하는 GDB의 하위 명령어가 없이 실행될때, info 명령어는
gdb 최상위 레벨로 가도록 한다. 세부사항을 위해 `.gdbinit'를 참조해라.
If you use emacs, you will probably want to do a make TAGS after
you configure your distribution; this will put the machine dependent
routines for your local machine where they will be accessed first by
M-.
만일 여러분이 emacs를 사용한다면, 배포을 설정한후 make TAGS를 하길 원할 것이다.;
이것은 M-.가 우선 접속하는 로컬 머신을 위한 머신 독립적인 루틴을 놓는다.
Also, make sure that you've either compiled GDB with your local cc, or
have run fixincludes if you are compiling with gcc.
또한, 로컬 cc를 가지고 GDB를 컴파일하였는지 확실히 해라. 그렇지 않고, gcc를 가지고 컴파일 했다면 fixincludes를 돌려라.
Thanks for thinking of offering your changes back to the community of GDB users. In general we like to get well designed enhancements. Thanks also for checking in advance about the best way to transfer the changes.
GDB 사용자 커뮤니티에 여러분의 변경사항들을 제공할려는 생각에 감사한다. 일반적으로 우리는 강화되어 잘 정의된것을 원한다. 또한 변경사항을 보내주는 가장 좋은 방법을 확인하면 미리 감사하겠다.
The GDB maintainers will only install "cleanly designed" patches. This manual summarizes what we believe to be clean design for GDB.
GDB 메인테이너들은 "명백히 디자인된" 패치들만 인스톨한다. 이 매뉴얼은 우리가 GDB를 위한 디자인을 명백히 하도록 믿는다고 요약해서 말한다.
If the maintainers don't have time to put the patch in when it arrives, or if there is any question about a patch, it goes into a large queue with everyone else's patches and bug reports.
만일 메인테이너가 도착한 패치를 넣을 시간이 없다면 또는 패치에 관한 의문점이 있다면, 이 패치는 다른 모든 사람들의 패치와 버그 리포트와 함께 커다란 큐로 보내진다.
The legal issue is that to incorporate substantial changes requires a
copyright assignment from you and/or your employer, granting ownership
of the changes to the Free Software Foundation. You can get the
standard documents for doing this by sending mail to gnu@gnu.org
and asking for it. We recommend that people write in "All programs
owned by the Free Software Foundation" as "NAME OF PROGRAM", so that
changes in many programs (not just GDB, but GAS, Emacs, GCC,
etc) can be
contributed with only one piece of legalese pushed through the
bureacracy and filed with the FSF. We can't start merging changes until
this paperwork is received by the FSF (their rules, which we follow
since we maintain it for them).
Technically, the easiest way to receive changes is to receive each
feature as a small context diff or unidiff, suitable for patch.
Each message sent to me should include the changes to C code and
header files for a single feature, plus `ChangeLog' entries for
each directory where files were modified, and diffs for any changes
needed to the manuals (`gdb/doc/gdb.texinfo' or
`gdb/doc/gdbint.texinfo'). If there are a lot of changes for a
single feature, they can be split down into multiple messages.
기술적으로, 변경사항을 받는 가장 쉬운 방법은 patch같이 ,조그만 문맥 diff나 unidiff로써 각 특징을 받는것이다.
나에게 오는 각 메세지는 단일 특징을 위한 C 코드와 헤더 파일들에 대한 변경사항을 포함하여야 하며,
그외 어떤 파일들이 수정되었는지를 위해 `ChangeLog'를, 그리고 매뉴얼에 필요한 변경사항들의
diff를 포함해야 한다.(`gdb/doc/gdb.texinfo' 나 `gdb/doc/gdbint.texinfo')
만일 단일 특징을 위한 많은 변경사항들이 잇다면, 다중 메세지로 나눌수 있다.
In this way, if we read and like the feature, we can add it to the sources with a single patch command, do some testing, and check it in. If you leave out the `ChangeLog', we have to write one. If you leave out the doc, we have to puzzle out what needs documenting. Etc., etc.
이런 방법으로, 만일 우리가 특징을 읽고 좋아한다면 단일 패치 명령어가 있는 소스에 추가할수 있고 테스트를 하고, 검사할수 있다. 만일 여러분이 `ChangeLog'에 남긴다면, 거기에 쓴다. 만일 여러분이 doc을 남긴다면, 우리는 문서화가 필요한 것을 알아야 한다. 등등..
The reason to send each change in a separate message is that we will not install some of the changes. They'll be returned to you with questions or comments. If we're doing our job correctly, the message back to you will say what you have to fix in order to make the change acceptable. The reason to have separate messages for separate features is so that the acceptable changes can be installed while one or more changes are being reworked. If multiple features are sent in a single message, we tend to not put in the effort to sort out the acceptable changes from the unacceptable, so none of the features get installed until all are acceptable.
분리된 메세지에 각 변경사항을 보내는 이유는 우리는 몇몇 변경사항들을 인스톨하지 않기 때문이다. 질문이나 코멘트를 가지고 여러분에게 되돌아 온다. 만일 우리가 정확히 우리일을 한다면, 여러분에게 돌아가는 메세지는 변경 사항을 받아들일수 있도록 만들기 위해 고쳤다는 말이다. 각 특징을 위해 분리된 메세지를 가지는 이유는 받은 변경사항들은 하나나 그 이상의 변경사항들이 다시 작업되는 동안 설치된다. 만일 여러 특징들이 단일 메세지로 보내진다면, 우리는 받아들일수 없는 변경사항들을 받아들이도록 노력하지 않는다. 그래서 특징중 어떤것도 받아들일때까지는 설치되지 않는다.
If this sounds painful or authoritarian, well, it is. But we get a lot of bug reports and a lot of patches, and many of them don't get installed because we don't have the time to finish the job that the bug reporter or the contributor could have done. Patches that arrive complete, working, and well designed, tend to get installed on the day they arrive. The others go into a queue and get installed as time permits, which, since the maintainers have many demands to meet, may not be for quite some time.
만일 이것은 고통스럽거나 권위적인것처럼 들린다면, 그럴지도 모른다. 그러나 많은 버그 리포트와 많은 패치를 원한다. 그리고 그것들 대부분은 우리가 버그 리포트나 기여자가 할수 있는 작업을 끝낼 시간을 가지고 있지 않기 때문에 설치하지 않는다. 완전히 작업하고 잘 디자인된 패치는 도착하자마자 설치를 한다. 다른것들은 큐로 가고 시간이 나면 설치를 한다. 왜냐하면 메인테이너들은 충족시킬 많은 조건을 가지기 때문에, 충분한 시간을 가지지 못할 것이다.
Please send patches directly to the GDB maintainers.
the GDB maintainers에 직접 패치를 보내라.
Fragments of old code in GDB sometimes reference or set the following configuration macros. They should not be used by new code, and old uses should be removed as those parts of the debugger are otherwise touched.
GDB에서 예전 코드 프레그먼트를 참조하거나 다음 설정 매크로를 설정해라. 이것들은 새 코드에서는 사용되어서는 안되며 예전 사용은 디버거의 이 부분들에서 제거되어야 한다.
STACK_END_ADDR
이 매크로는 스택 끝이 나타나는 곳에 정의하기 위해 사용되며 코어파일 자체에 이 주소를 기록하지 않는 코어 파일 형식 해석시 사용된다. 이 형식은 BFD에 설정되며 GDB는 거기서 아마도 정보를 가져온다. GDB 설정 파일내 값들은 BFD 설정 파일(필요하다면)로 이동되어야 하며 GDB의 설정파일 모두에서 제거되어야 한다.
PYRAMID_CONTROL_FRAME_DEBUGGING
PYRAMID_CORE
PYRAMID_PTRACE
REG_STACK_SEGMENT
Go to the first, previous, next, last section, table of contents.