'programming/C_C++'에 해당되는 글 279건

2012.09.14 GDB를 이용한 디버깅

GDB를 이용한 디버깅

programming/C_C++ 2012. 9. 14. 10:43

출처:http://korea.gnu.org/manual/release/gdb/gdb.html

GDB를 이용한 디버깅

GNU 소스-레벨 디버거

Fifth Edition, for GDB version

April 1998

Richard M. Stallman and Roland H. Pesch

초벌 번역 : 정강훈

차례

Published by the Free Software Foundation
59 Temple Place - Suite 330,
Boston, MA 02111-1307 USA
Printed copies are available for $20 each.
ISBN 1-882114-11-6
Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies.

Permission is granted to copy and distribute modified versions of this manual under the conditions for verbatim copying, provided also that the entire resulting derived work is distributed under the terms of a permission notice identical to this one.

Permission is granted to copy and distribute translations of this manual into another language, under the above conditions for modified versions.

GDB 개요

GDB같은 디버거의 목적은 프로그램 실행동안 프로그램 내부에서 진행되고 있는 것이 무엇인지를 여러분이 알도록 하는데에 있다. -- 또는 다른 프로그램이 죽는 순간에 무엇을 했는지.

GDB는 여러분이 버그를 잡도록 도와주는 4 종류의 일들(또 이것들을 지원하는 다른 것들)을 할수 있다.

프로그램을 시작할때 프로그램의 행동에 영향을 줄수 있는 것을 지정할수 있다.
여러분의 프로그램을 지정된 조건에서 멈추도록 만든다.
여러분의 프로그램이 멈추었을때 무엇이 일어났는지를 시험할수 있다.
여러분의 프로그램내의 어떤것을 바꾸어서, 여러분이 버그를 고칠수 있도록 실험을 할수 있게 하고 다른것에 대해 배우도록 한다.

여러분은 C나 C++로 쓰여진 프로그램을 디버깅하기 위해 GDB를 사용할수 있다. 더 많은 정보를 위해서, C 그리고 C++ 섹션을 참조해라.

Modula-2 와 Chill는 부분적으로 지원한다. Modula-2에 관한 정보를 위해서, Modula-2 섹션을 참조해라. Chill에 관한 문서는 아직 없다.

sets, subranges, 파일 변수들 또는 중첩된 함수들을 사용하는 Pascal 프로그램에 대한 디버깅은 현재 작동되지 않는다. GDB는 표현식 들어가기, 값 출력, 또는 Pascal 문법을 사용하는 비슷한 특징들은 지원하지 않는다.

비록 표현식 들어가기, 값 출력, 또는 Fortran 문법에서 사용하는 비슷한 특징들을 아직 지원하지 않아도 GDB는 Fortran으로 짜여진 프로그램을 디버깅하기 위해 사용 될수 있다. 중요 부분을 추적하기 위해 몇몇 변수를 참조하는것이 필요하다.

자유 소프트웨어

GDB는 GNU General Public License(GPL)에 의해 보호되는 자유 소프트웨어 이다. GPL은 라이센스된 프로그램을 복사하거나 사용하는것이 자유스럽다. -- 그러나 복사본을 가진 모든 사람은 또한 그 복사본(소스 코드에 접근할수 있다는 의미)을 수정하기 위한 자유를 가지며 그 복사본을 배포하는것도 자유이다. 전형적인 소프트웨어 회사들은 여러분의 자유를 제한하기 위해 저작권을 사용한다; Free Software Foundation은 이들 자유를 보호하기 위해 GPL을 사용한다.

기본적으로, General Public License는 여러분이 이러한 자유를 가진다는 라이센스이고 여러분은 이러한 자유를 그밖의 다른 사람에게서 제한할수 없다.

GDB 공헌자들

Richard Stallman은 GDB의 원 저자이며 다른 많은 GDB프로그램의 저자이기도 하다. 많은 다른 사람들이 이 개발에 공헌하였다. 이 섹션은 주요 공헌자들을 밝히기 위한 것이다. 자유 소프트웨어의 미덕중 하나는 모든 사람들이 프로그램에 공헌하는것이 자유라는 점이다; 유감스럽게, 우리는 여기서 모든사람들을 알릴수 없다. GDB 배포판에 있는 `ChangeLog'는 사건들에 대해 대체로 정확히 기술하고 있다.

버전 2.0 이전의 많은 변화들은 오랜 시간때문에 잃어버렸다.

변명: 이 섹션에 추가 하는것은 부분적으로 환영한다. 만일 여러분이나 여러분의 친구들(또는 적)이 이 리스트에서 빠져있다면 우리는 여러분의 이름을 추가하길 원한다.

이들은 보답이 없는 오랜 작업을 하였으며, 우리는 주요 릴리즈 버전시에 GDB를 도와준 이들에게 감사한다.: Stan Shebs (release 4.14), Fred Fish (releases 4.13, 4.12, 4.11, 4.10, and 4.9), Stu Grossman and John Gilmore (releases 4.8, 4.7, 4.6, 4.5, and 4.4), John Gilmore (releases 4.3, 4.2, 4.1, 4.0, and 3.9); Jim Kingdon (releases 3.5, 3.4, and 3.3); and Randy Smith (releases 3.2, 3.1, and 3.0). 얼마간의 기간동안 GDB의 주요 메인테이너로써, 각 공헌자들은 구조와 안정성 그리고 전체 디버거의 능력에 대해 공헌했다.

Peter TerMaat, Chris Hanson, 그리고 Richard Mlynarik 가 여러번 도와주었으며 Richard Stallman은 2.8까지 버전을 관리했다.

Michael Tiemann은 중요한 공헌자인 Per Bothner와 함께 GDB에서 GNU C++지원의 대부분의 저자이다. James Clark는 C++ 디맹글러(demangler)를 썼다. 초기 C++ 작동은 Peter TerMatt(3.0 릴리즈시 많은 일반적인 업데이트 작업을 하였다.)에 의해서이다.

GDB 4는 다중 객체-파일 포맷을 검사하기 위해 BFD 서브루틴 라이브러리를 사용하였다; BFD는 David V.Henkel-Wallace, Rich Pixley, Steve Chamberlain, 그리고 John Gilmore의 공동 프로젝트이다.

David Johnson은 원 COFF 지원을 썼다; Pace Willson은 캡슐화된 COFF를 지원했다.

Harris Computer Systems의 Brent Benson은 DWARF2 지원의 공헌자이다.

Adam de Boor와 Bradley Davis는 ISI Optimum V 지원에 공헌했다. Per Bothner, Noboyuki Hikichi, 그리고 Alessandro Forin는 MIPS 지원에 공헌했다. Jean-Daniel Fekete는 Sun 386i 지원에 공헌했다. Chris Hanson 는 HP9000 지원을 개선했다. Noboyuki Hikichi 그리고 Tomoyuki Hasei는 Sony/News OS 3 지원에 공헌했다. David Johnson는 Encore Umax 지원에 공헌했다. Jyrki Kuoppala는 Altos 3068 지원에 공헌했다. Jeff Law는 HP PA 그리고 SOM 지원에 공헌했다. Keith Packard는 NS32K 지원에 공헌했다. Doug Rabson는 Acorn Risc Machine 지원에 공헌했다. Bob Rusk는 Harris Nighthawk CX-UX 지원에 공헌했다. Chris Smith는 Convex 지원(그리고 포트란 디버깅)에 공헌했다. Jonathan Stone는 Pyramid 지원에 공헌했다. Michael Tiemann는 SPARC 지원에 공헌했다. Tim Tucker는 Gould NP1와 Gould Powernode 지원에 공헌했다. Pace Willison는 Intel 386 지원에 공헌했다. Jay Vosburgh는 Symmetry 지원에 공헌했다.

Rich Schaefer 그리고 Peter Schauer는 SunOS 공유 라이브러리 지원을 도와주었다.

Jay Fenlason 그리고 Roland McGrath는 GDB와 GAS가 몇몇 머신 명령어 집합에 일치하도록 확실히 해주었다.

Patrick Duval, Ted Goldstein, Vikram Koka 그리고 Glenn Engel는 원격 디버깅 개발을 도와 주었다. Intel Corporation, Wind River Systems, AMD, 그리고 ARM는 각각 i960, VxWorks, A29K UDI, 그리고 RDI targets를 위한 원격 디버깅 모듈에 공헌했다.

Brian Fox는 명령어 라인 편집과 명령어 히스토리를 제공하는 readline 라이브러리의 저자이다.

SUNY Buffalo의 Andrew Beers는 언어-switch 코드, Modula-2 지원 그리고 이 매뉴얼의 Language chapter에 공헌했다.

Fred Fish는 Unix System Vr4 지원의 대부분을 작업했다. 기리고 C++ 오버로딩 심볼을 지원하기 위해 명령어-완성에 대한 지원을 강화했다.

Hitachi America, Ltd. Hitachi microprocessors를 지원하도록 후원했다.

Kung Hsu, Jeff Law, 그리고 Rick Sladkey는 하드웨어 watchpoints에 대한 지원을 추가했다.

Michael Snyder는 tracepoint 지원을 추가했다.

Stu Grossman는 gdbserver를 썼다.

Jim Kingdon, Peter Schauer, Ian Taylor, 그리고 Stu Grossman는 많은 버그를 고쳤으며 GDB를 깔끔하게 해주었다.

Cygnus Solutions은 1991년 이후 GDB 유지와 개발의 많은것을 지원했다.

간단한 GDB 세션

여러분은 GDB에 관한 것을 읽기 위해 여가시간에 이 매뉴얼을 사용할수 있다. 그러나, 약간의 명령어들로만으로도 디버거 사용을 시작하는데 충분하다. 이 장은 이들 명령어들에 대해 기술한다.

이 예제 세션에서, 우리는 주위 출력과 쉽게 구별하기 위해 다음처럼 사용자 입력을 강조한다:input,

GNU m4(일반 매크로 프로세서)의 초기 버전중 하나는 다음과 같은 버그를 가지고 있다: 가끔 우리가 디폴트에서 인용 문자열을 바꿀때, 이 명령어들은 다른 stop 작업내에 있는 하나의 매크로 정의를 캡쳐하기 위해 사용될수 있다. 다음의 간단한 m4 세션에서, 우리는 0000로 확장되는 매크로 foo를 정의한다; 그리고 같은것으로 bar를 정의 하기 위해 m4 내장 defn를 사용한다. 그러나, 우리가 <QUOTE>로 열린 인용 문자열과 <UNQUOTE>로 닫힌 인용문자열을 바꾼다면, 같은 절차는 새로운 동의어 baz를 정의하는데 실패한다.

$ cd gnu/m4
$ ./m4
define(foo,0000)

foo
0000
define(bar,defn(`foo'))

bar
0000
changequote(<QUOTE>,<UNQUOTE>)

define(baz,defn(<QUOTE>foo<UNQUOTE>))
baz
C-d
m4: End of input: 0: fatal error: EOF in string

무엇이 일어나고 있는지 알아보기 위해 GDB를 사용해보자.

$ gdb m4
GDB is free software and you are welcome to distribute copies
 of it under certain conditions; type "show copying" to see 
 the conditions.
There is absolutely no warranty for GDB; type "show warranty" 
 for details.

GDB , Copyright 1995 Free Software Foundation, Inc...
(gdb)

GDB는 발견하기 위한 곳이 어디인지 알기 위해 필요한 심볼 데이터 만을 읽는다.; 결과적으로, 처음 프롬프트는 매우 빨리 나타난다. 우리는 지금 보통보다 좁은 디스플레이 폭을 사용하도록 GDB에게 말한다. 그래서 이 예제는 이 매뉴얼에 적용시켰다.

(gdb) set width 70

우리는 m4 내장 changequote가 작동하는 방법을 알 필요가 있다. 소스를 보고, 우리는 관련 서브루틴이 m4_changequote이라고 알고 있으므로, GDB break 명령어로 breakpoint를 설정한다.

(gdb) break m4_changequote
Breakpoint 1 at 0x62f4: file builtin.c, line 879.

run명령어를 사용하여, GDB 제어하에 m4를 시작한다; 제어가 m4_changequote에 도착하지 않는한, 프로그램은 보통처럼 작동한다.

(gdb) run
Starting program: /work/Editorial/gdb/gnu/m4/m4
define(foo,0000)

foo
0000

breakpoint를 트리거하기 위해, changequote를 호출한다. GDB는 m4의 실행을 일시 중지하고 멈춘 곳의 문맥에 관한 정보를 출력한다.

changequote(<QUOTE>,<UNQUOTE>)

Breakpoint 1, m4_changequote (argc=3, argv=0x33c70) 
    at builtin.c:879
879         if (bad_argc(TOKEN_DATA_TEXT(argv[0]),argc,1,3))

지금 현재 함수의 다음 라인으로 실행을 나아가기 위해 n(next)명령어를 사용한다.

(gdb) n
882         set_quotes((argc >= 2) ? TOKEN_DATA_TEXT(argv[1])\
 : nil,

set_quotes는 약속된 서브루틴처럼 보인다. 우리는 next 대신에 s (step) 명령어를 사용하여 해당 서브루틴으로 들어간다. step는 any 서브루틴에서 실행되기 위해 다음 라인으로 들어 간다. 그래서 set_quotes 안으로 들어간다.

(gdb) s
set_quotes (lq=0x34c78 "<QUOTE>", rq=0x34c88 "<UNQUOTE>")
    at input.c:530
530         if (lquote != def_lquote)

현재 m4가 일시 중지된 서브루틴을 보여주는 출력을 스택 프레임 디스 플레이라 부른다. 이것은 스택의 개요를 보여준다. 우리는 대체로 스택에 있는곳을 보기 위해 backtrace(철자는 bt)를 사용한다: backtrace명령어는 현재 활성화된 서브루틴을 위해 스택 프레임을 출력한다.

(gdb) bt
#0  set_quotes (lq=0x34c78 "<QUOTE>", rq=0x34c88 "<UNQUOTE>")
    at input.c:530
#1  0x6344 in m4_changequote (argc=3, argv=0x33c70) 
    at builtin.c:882
#2  0x8174 in expand_macro (sym=0x33320) at macro.c:242
#3  0x7a88 in expand_token (obs=0x0, t=209696, td=0xf7fffa30)
    at macro.c:71
#4  0x79dc in expand_input () at macro.c:40
#5  0x2930 in main (argc=0, argv=0xf7fffb20) at m4.c:195

우리는 무엇이 일어났는지를 보기 위해 약간 더 많은 라인을 나아간다. 처음 몇번, 우리는 `s'를 사용한다; 다음 두번, 우리는 xstrdup 서브루틴으로 들어가는것을 피하기 위해 n를 사용한다.

(gdb) s
0x3b5c  532         if (rquote != def_rquote)
(gdb) s
0x3b80  535         lquote = (lq == nil || *lq == '\0') ?  \
def_lquote : xstrdup(lq);
(gdb) n
536         rquote = (rq == nil || *rq == '\0') ? def_rquote\
 : xstrdup(rq);
(gdb) n
538         len_lquote = strlen(rquote);

마지막 라인은 약간 이상하게 보인다; 우리는 그것들이 우리가 지정한 왼쪽 그리고 오른쪽 인용어구인지 아닌지를 보기 위해 lquote 그리고 rquote 를 검사할수 있다. 우리는 변수들을 보기 위해 p(print) 명령어를 사용한다.

(gdb) p lquote
$1 = 0x35d40 "<QUOTE>"
(gdb) p rquote
$2 = 0x35d50 "<UNQUOTE>"

lquote 그리고 rquote는 실제로 새로운 왼쪽, 오른쪽 인용어구이다. 몇몇 문맥을 보기 위해, 우리는 l(list) 명령어를 가지고 현재 라인 주위 소스코드 10라인을 볼수 있다.

(gdb) l
533             xfree(rquote);
534
535         lquote = (lq == nil || *lq == '\0') ? def_lquote\
 : xstrdup (lq);
536         rquote = (rq == nil || *rq == '\0') ? def_rquote\
 : xstrdup (rq);
537
538         len_lquote = strlen(rquote);
539         len_rquote = strlen(lquote);
540     }
541
542     void

len_lquote와 len_rquote를 설정하는 마지막 두 라인으로 가서 이들 변수값을 검사하자.

(gdb) n
539         len_rquote = strlen(lquote);
(gdb) n
540     }
(gdb) p len_lquote
$3 = 9
(gdb) p len_rquote
$4 = 7

len_lquote와 len_rquote가 각각 lquote와 rquote의 길이라고 가정할때 그것은 확실히 이상하게 보인다. 우리는 p 명령어를 사용하여 그것들을 적당한 값으로 설정할수 있다. 왜냐하면 이 명령어는 어떤 표현식의 값을 출력할수 있기 때문이다. -- 그리고 그 표현식은 서브루틴 콜과 대입을 포함할수 있다.

(gdb) p len_lquote=strlen(lquote)
$5 = 7
(gdb) p len_rquote=strlen(rquote)
$6 = 9

m4 내장 defn로 새로운 인용어구 사용 문제를 고치기에 충분한가? 우리는 c(continue)명령어로 실행을 계속하기 위해 m4를 사용할수 있다. 그리고 문제를 야기한 예제를 다시 시도하자.

(gdb) c
Continuing.

define(baz,defn(<QUOTE>foo<UNQUOTE>))

baz
0000

성공! 새로운 인용어구는 지금 기본처럼 작동한다. 문제는 잘못된 길이를 정의한 두 오타 때문인거 같다. 우리는 입력에 EOF를 주어 m4를 종료할수 있다.

C-d
Program exited normally.

메세지 `Program exited normally.'는 GDB에서 나온것이다; 그것은 m4가 실행을 마쳤다는것을 가리킨다. 우리는 GDB quit 명령어를 가지고 GDB 세션을 마칠수 있다.

(gdb) quit

GDB에 들어가고 나가기

이 장은 GDB를 시작하는 방법과 나가는 방법에 대해 토론한다. 필수적인 것들:

GDB를 시작하기 위해 `gdb'를 타이핑해라.
종료하기 위해 quit나 C-d를 타이핑해라.

GDB 실행

프로그램 gdb를 돌려 GDB를 실행해라. 일단 시작하면, GDB는 여러분이 종료(exit)를 할때까지 터미널에서 명령어를 읽는다.

여러분은 또한 시작시 여러분의 디버깅 환경을 지정하기 위해 인자와 옵션을 가지고 gdb를 돌릴수 있다.

여기서 기술한 명령어-라인 옵션들은 여러상황을 처리하도록 고완되었다.; 몇몇 환경에서, 이들 옵션 중 일부는 효과적으로 이용할수 없다.

GDB를 시작하기 위한 가장 일반적인 방법은 실행 프로그램을 지정하는 인자 1개를 가지는 것이다.

gdb program

여러분은 또한 실행 프로그램과 코어(core) 파일을 지정하여 시작할수 있다:

gdb program core

대신에 여러분은 돌아가는 프로그램을 디버깅하길 원한다면 두번째 인자로써 프로세스 ID를 지정해라.

gdb program 1234

프로세스 1234에 GDB를 연결한다.(여러분이 `1234'이라는 이름의 파일을 가지고 있지 않다면; GDB는 우선 코어파일 이름을 체크한다.)

두번째 명령어 라인 옵션을 이용하는것은 꽤 안전한 OS를 요구한다.; 여러분이 bare 보드에 연결된 디버거로써 GDB를 사용할때, 거기에는 "프로세스"에 대한 개념이 없을 것이다. 그리고 코어 덤프를 가지기 위한 방법도 없다.

여러분은 -silent를 지정하여 GDB의 앞부분을 출력하지 않고 gdb를 돌릴수 있다.

gdb -silent

여러분은 명령어-라인 옵션을 사용하여 GDB를 시작하는 방법을 제어할수 있다. GDB는 그것 자체로 사용할수 있는 옵션들을 알려줄수 있다.

이용할수 있는 모든 옵션들과 사용에 대해 간단한 기술을 보고자 하면

gdb -help

를 타이핑해라.(`gdb -h'와 동일하다.)

여러분이 준 모든 옵션과 명령어 라인 인자들은 순차적으로 처리된다. `-x' 옵션을 사용하면 순서가 달라진다.

파일들 선택하기

GDB가 시작할때, GDB는 실행파일과 코어 파일(또는 프로세스 ID)을 지정하는 것처럼 옵션이외의 다른 인자들을 읽는다. 이것은 인자들을 각각 `-se'과 `-c'로 지정한것과 같다. (GDB는 `-se'옵션 다음에 따르는 인자와 같기 때문에 관련된 옵션 플래그를 가지고 있지 않는 첫번재 인자를 읽는다; 그리고 `-c' 옵션 다음의 인자와 같기 때문에 관련된 옵션 플래그를 가지지 않는 두번째 인자를 읽는다.)

많은 옵션들은 long과 short형태를 가지고 있다; 두개는 다음리스트에서 보여진다. GDB는 또한 옵션이 모호하지 않는한 여러분이 줄여도 긴형태로 인식할수도 있다. (여러분이 원한다면, 여러분은 우리가 더 일반적인 변환을 설명하더라도 `-'보다 `--'로 옵션 인자를 플래그화 할수 있다.)

-symbols file
-s file: 파일 file에서 심볼 테이블을 읽는다.
-exec file
-e file: 실행 파일로써 그리고 코어 덤프와 결합된 순 데이터를 검사하기 위해 파일 file를 사용해라.
-se file: 파일 file에서 심볼 테이블을 읽고 실행파일로써 이것을 사용해라.
-core file
-c file: 검사하기 위한 코어 덤프로써 파일 file를 사용해라.
-c number: attach 명령어처럼 프로세스 ID number를 연결해라. (만일 number 이름의 코어-덤프 포맷 파일이 없다면, 이것은 `-c'에서 읽기 위한 코어 덤프로써 파일을 지정한 경우처럼)
-command file
-x file: 파일 file에서 GDB 명령어를 실행한다. 명령어 파일들 섹션을 참조해라.
-directory directory
-d directory: 소스 파일을 탐색하기 위해 패스에 directory를 추가해라.
-m
-mapped: 경고: OS 기능에 의존하는 이 옵션은 모든 시스템에서 지원되지 않는다.
만일 메모리-대응(memory-map)파일들이 mmap를 통해 시스템에서 이용할 수 있다면, 여러분은 현재 디렉토리에서 여러분의 프로그램을 다시 재사용할수 있는 파일에 심볼들을 쓸수 있는 옵션을 사용할수 있다. 만일 여러분이 디버깅하는 프로그램이 `/tmp/fred'라 불린다면, 대응된 심볼 파일은 `./fred.syms'이다. 앞으로 GDB 디버깅 세션들은 이 파일의 존재를 확인하며 실행 프로그램에서 심볼 파일을 읽기보다 이 파일에서 심볼 정보를 빠르게 대응시킨다. `.syms'파일은 GDB가 돌아가고 있는 호스트 머신에 의존한다. 이것은 내부 GDB 심볼 테이블의 정확한 이미지를 가진다. 이것은 크로스 다중 호스트 플랫폼에서 공유 될수 없다.
-r
-readnow: 필요할때 조금씩 읽는것보다 즉시 심볼 파일의 전체 심볼 테이블을 읽는다. 이것은 시작을 느리게 만들지만 앞으로의 작동은 더 빠르게 만든다.

-mapped와 -readnow 옵션은 전형적으로 완전한 심볼 정보를 포함하는 `.syms' 파일을 만들기 위해 결합된다. (정보를 위해서 파일을 지정하기 위한 명령어들를 참조해라.)

앞으로의 사용을 위해 파일 `.syms'는:

	gdb -batch -nx -mapped -readnow programname

모드 선택하기

여러분은 다양한 선택 모드에서 GDB를 돌릴수 있다--예를 들어, 배치모드나 조용한 모드

-nx

-n

초기화 파일들(보통 `.gdbinit'라 불린다)에서 명령어를 실행하지 마라. 보통, 이 파일들에 있는 명령어들은 모든 명령어 옵션과 인자들이 처리된 다음에 실행된다. 명령어 파일들 섹션을 참조해라.

-quiet

-q

"침묵". 소개와 저작권 메세지는 출력하지 마라. 이 메세지들은 배치 모드에서 작동되지 않는다.

-batch

배치모드로 돌려라. `-x'(그리고 `-n'로 저지되지 않은 초기화 파일에서 모든 명령어들)로 지정된 모든 명령파일들을 처리한후 0 상태로 종료된다. 만일 에러가 명령어 파일안에 있는 GDB명령어를 실행하는 동안 일어난다면 0이 아닌 상태로 종료된다. 배치 모드는 다운로드나 다른 컴퓨터에서 프로그램을 돌리기 위한 필터로써 GDB를 돌리는데 유용하다.; 더 유용하게 만들기 위해서 메세지가 배치모드에서 돌아갈때는 나타나지 않는다. (보통 GDB제어하에서 돌아가는 프로그램이 끝날때 나타난다.)

Program exited normally.

-cd directory

GDB는 현재 디렉토리 대신에 작업디렉토리로써 directory를 사용하여 작동한다.

-fullname

-f

GNU Emacs는 하위 프로세서로써 GDB를 돌릴때 이 옵션을 설정한다. 그것은 스택 프레임이 출력될때(프로그램이 멈춘 시간을 포함하여) 파일 이름과 라인 넘버를 출력하도록 GDB에게 말한다. 이것은 두개의 `\032' 문자들 처럼 보이는 포맷을 허용하며, 파일 이름, 라인 넘버, 콜론과 뉴라인에 의해 분리되는 문자가 뒤따라온다. Emacs-to-GDB 인터페이스 프로그램은 프레엠에서 소스 코드를 보여주기 위한 신호로써 두개의 `\032' 문자를 사용한다.

-b bps

원격 디버깅에서 GDB가 사용한 시리얼 인터페이스의 라인 스피드(baud rate 나 bits per second)를 설정한다.

-tty device

프로그램의 표준 입력과 출려을 위해 device를 사용하여 작동한다.

GDB 종료하기

quit: GDB를 종료하기 위해, quit(간단히 q)를 사용해라. 또는 EOF 문자(보통 C-d)를 타이핑해라. 만일 여러분이 expression를 제공하지 않는다면, GDB는 정상적으로 종료될 것이다; 그렇지 않으면 에러 코드로써 expression의 결과를 사용하고 종료할 것이다.

인터럽트(자주 C-c)는 GDB에서 나가지 않지만 처리중인 GDB명령 작동을 끝내며 GDB 명령어 레벨로 돌아온다. 어떤때든지 인터럽트 문자를 타이핑하는것은 보장된다. 왜냐하면 GDB는 안전한 시간이 될때까지 효과를 가지도록 허용하지 않기 때문이다.

만일 여러분이 연결된 프로세스나 디바이스를 제어하기 위해 GDB를 사용한다면, 여러분은 detach명령어를 가지고 놓아주어야 한다. (이미 돌고 있는 프로세스 디버깅하기섹션을 참조해라.)

Shell 명령어들

만일 여러분이 디버깅 세션동안 경우에 따라 shell 명령어를 실행할 필요가 있다면, GDB를 나가거나 일시중지할 필요가 없다; 여러분은 단지 shell 명령어를 사용할수 있다.

shell command string: command string를 실행하기 위해 표준 shell을 기동한다. 만일 shell이 존재한다면, 환경변수 SHELL는 기동될 shell을 결정한다. 그렇지 않으면 GDB는 /bin/sh를 사용한다.

make는 개발 환경에서 자주 필요하다. 여러분은 GDB에서 이 목적을 위해 shell명령어를 사용할 필요가 없다:

make make-args: 지정된 인자를 가지고 make 프로그램을 실행해라. 이것은 `shell make make-args'와 같다.

GDB 명령어들

여러분은 축약형이 모호하지 않다면 명령어 이름의 처음 몇자로 GDB 명령어를 축약할수 있다; 그리고 여러분은 단지 RET를 타이핑하여 GDB 명령어를 반복할수 있다. 여러분은 또한 GDB 명령어 단어의 나머지를 채우기 위해 TAB을 사용할수 있다.(또는 만일 거기에 1개 이상의 단어가 있다면, 여러분이 선택적으로 이용할수 있도록 보여준다.)

명령어 구문

GDB 명령어는 단일 라인 입력이다. 길이에 대한 제한은 없다. 명령어 이름과 함께 시작하며 명령어 이름에 의존하는 의미가 있는 인자가 뒤따라 온다. 예를 들어, step명령어는 `step 5'처럼 스텝을 위한 갯수를 받는다. 여러분은 또한 인자 없이 step를 사용할수 있다. 몇몇 명령어 이름들은 어떤 인자도 허용하지 않는다.

GDB는 축약형이 모호하지 않다면 항상 명령어이름을 축약한다. 다른 가능한 명령어 축약형들은 문서안에 나열 되어 있다. 몇몇 경우에는, 모호한 축약형조차 혀용된다.; 예를 들어, s는 비록 s로 시작하는 다른 명령어들이 있다할지라도 step와 같은 것으로써 특별히 정의되어 있다. 여러분은 help 명령어에 인자로써 이것들을 사용하여 축약형을 테스트할수 있다.

GDB에 입력으로써 빈 라인(단지 RET를 타이핑하는것)은 전 명령어의 반복을 의미한다. 어떠한 명령어(예를 들어, run)는 이 방법으로 반복되지 않는다; 이들 명령어는 문제를 야기할수 있고 반복을 원하지 않는 명령어들이다.

list와 x명령어는 여러분이 RET로 반복할때, 타이핑처럼 정확히 반복하는것 이외에 새로운 인자를 만든다. 이것은 소스나 메모리를 쉽게 스케닝하는것을 허용한다.

GDB는 또한 다른 방법으로 RET를 사용할수 있다: more와 비슷한 방법으로 출력 길이를 분할하기 위해 사용할수 있다.(Screen 크기섹션을 참조해라.) 이것은 이 상황에서 너무 많이 RET를 누르기 쉽기 때문에, GDB는 디스플레이의 범위를 만드는 명령어후 명령어 반복을 불가능하게 한다.

#에서 라인끝까지의 텍스트는 주석이다; 아무것도 아니라는 것이다. 이것은 명령어 파일들에서 매우 유용하다.(명령어 파일들섹션을 참조해라.)

명령어 완성

GDB는 만일 한가지의 가능성만 있다면 여러분을 위해 명령어 단어의 나머지를 채워준다.; 또한 어떤때든지 명령어에서 다음 단어를 위한 가능한 모든 경우를 여러분에게 보여준다. 이것은 GDB명령어, GDB 하위 명령어, 그리고 여러분의 프로그램에서 심볼들의 이름에서 작동한다.

여러분은 단어의 나머지를 채우길 원할때마다 TAB키를 눌러라. 만일 한가지의 가능성만 있다면, GDB는 단어를 채우고 명령어를 끝마치길 기다린다. (또는 RET를 눌러라.) 예를 들어 여러분이 다음을 한다면,

(gdb) info bre TAB

GDB는 `breakpoints' 단어의 나머지를 채운다. 왜냐하면 `bre'로 시작하는 info의 하위 명령어는 이것뿐이기 때문이다.

(gdb) info breakpoints

여러분은 여기서 info breakpoints 명령어를 돌리기 위해 RET를 누르거나, 만일 여러분이 예상한 단어가 아니라면 backspace나 그밖의 다른 것을 눌러라. (만일 여러분이 info breakpoints를 원하는게 확실하다면, 여러분은 명령어 완성 대신 명령어 축약형을 이용하기 위해 단지 `info bre'후에 즉시 RET를 해도 된다.)

만일 여러분이 TAB을 누를때 다음 단어의 가능성이 한가지 이상이라면 GDB는 벨소리를 울린다. 여러분은 더 많은 단어를 제공하고 다시 시도하거나 단지 2번 TAB키를 누를수 있다.; GDB는 모든 가능한 완성형을 보여준다. 예를 들어, 여러분은 `make_'로 시작하는 이름의 서브루틴에 breakpoint를 설정하기 원할지 모른다. 그러나 여러분이 b make_TAB 를 한다면 GDB는 단지 벨소리만을 낸다.TAB을 다시 타이핑하면 이 문자들로 시작하는 모든 함수 이름을 보여준다. 예를 들어:

(gdb) b make_ TAB
GDB sounds bell; press TAB again, to see:
make_a_section_from_file     make_environ               
make_abs_section             make_function_type         
make_blockvector             make_pointer_type          
make_cleanup                 make_reference_type        
make_command                 make_symbol_completion_list
(gdb) b make_

가능한 모든 경우를 출력한후, GDB는 여러분의 부분적인 입력(예에서 `b make_')을 복사하고 명령어를 마칠수 있다.

여러분이 처음 위치에서 선택 리스트들을 보길 원한다면, 여러분은 TAB를 두번 누르기보다 M-?를 누를수 있다. M-?는 META ?를 의미한다. 여러분은 키보드에서 META shift 같은것으로 디자인 된 키를 누르고 ?를 타이핑 하거나 ESC 다음에 ?를 눌러 할수 있다.

보통 단어라고 하는 여러분이 필요한 문자열은 중괄호나 단어 개념에서 제외된 다른 단어를 포함할지도 모른다. 이런 경우 단어의 완성형을 이루기 위해서는, 여러분은 GDB 명령어들중에서 '(단일 인용 부호)안에 단어를 닫아야 한다.

여러분이 필요로 하는 대부분의 상황은 C++ 함수 이름을 쓸 경우이다. 왜냐하면 C++은 함수 오버로딩을 허용하기 때문이다.(인자 타입에 의해 구별되는 같은 함수의 다중 정의) 예를 들어, 여러분이 breakpoint를 설정하길 원한다면, 여러분은 int 인자를 가지는 name(int) 버전인지, 또는 float 인자를 가지는 name(float) 버전인지를 구별해야 한다. 단어-완성형기능을 사용하기 위해, 함수 이름 시작시 '를 타이핑해라. 이것은 여러분이 TAB를 누르거나 원하는 단어 완성형을 위해 M-?를 누를때 보통보다 더 많은 정보를 고혀할 필요가 있다는 것을 GDB에게 알려 주는 것이다.

(gdb) b 'bubble( M-?
bubble(double,double)    bubble(int,int)
(gdb) b 'bubble(

몇몇 경우에, GDB는 완성된 이름이 인용구 사용을 필요로 한다는 것을 알려 줄수 있다. 이런 경우, GDB는 만일 처음 위치에 인용구를 타이핑하지 않는다면 여러분을 위해 인용구를 넣는다.:

(gdb) b bub TAB
GDB는 여러분의 입력라인을 다음처럼 수정하고 벨을 울린다.
(gdb) b 'bubble(

일반적으로, 만일 여러분이 오버로딩된 심볼의 완성형을 요구할때 인자 리스트를 타이핑하지 않았다면, GDB는 인용구가 필요하다는걸 말해 줄수 있다.

도움말 얻기

여러분은 help 명령어를 사용하여 명령어에 대한 정보를 GDB에게 요구할수 있다.

help

h

여러분은 명령어 클래스들의 이름들을 보기 위해 인자 없이 help( 간단히 h)를 사용할수 있다.

(gdb) help
List of classes of commands:

running -- Running the program
stack -- Examining the stack
data -- Examining data
breakpoints -- Making program stop at certain points
files -- Specifying and examining files
status -- Status inquiries
support -- Support facilities
user-defined -- User-defined commands
aliases -- Aliases of other commands
obscure -- Obscure features

Type "help" followed by a class name for a list of 
commands in that class.
Type "help" followed by command name for full 
documentation.
Command name abbreviations are allowed if unambiguous.
(gdb)

help class

인자처럼 help 클래스들 중 하나를 사용하여, 여러분은 그 클래스내 각 명령어 리스트를 볼수 있다. 예를 들어, 여기에 status 클래스를 위한 도움말 출력이 있다.

(gdb) help status
Status inquiries.

List of commands:

show -- Generic command for showing things set
 with "set"
info -- Generic command for printing status

Type "help" followed by command name for full 
documentation.
Command name abbreviations are allowed if unambiguous.
(gdb)

help command

help 인자에 명령어 이름을 붙이면, GDB는 그 명령어 사용 방법에 대한 간단한 단락을 출력한다.

complete args

complete args 명령어는 명령어 시작을 위해 가능한 완성형들 모두를 나열한다. 여러분이 완성하길 원하는 명령어의 시작을 지정하기 위해 args를 사용해라. 예를 들어:

complete i

결과는:

info
inspect
ignore

이것은 GNU Emacs 사용을 위한 것이다.

help에 추가하여, 여러분은 프로그램의 상태나 GDB 자체의 상태를 보기 위해 GDB 명령어 info와 show를 사용할수 있다. 각 명령어는 질의를 위해 많은 것을 제공한다; 이 매뉴얼은 적당한 문맥에서 각 명령어들을 소개한다. 색인에서 info와 show아래에 있는 리스트들은 모든 하위 명령어들을 가리킨다. 색인 섹션을 참조해라.

info: 이 명령어(간단히 i)는 프로그램의 상태를 기술한다. 예를 들어, 여러분은 info args로 프로그램에 주어진 인자들을 볼수 있고, info registers를 사용하여 현재의 모든 레지스터들을 나열할수 있으며, info breakpoints으로 설정한 breakpoint들을 볼수 있다. 여러분은 help info로 info 하위 명령어의 모든 리스트를 볼수 있다.
set: 여러분은 set을 가지고 환경변수에 표현식의 결과를 대입할수 있다. 예를 들어, 여러분은 GDB 프롬프트를 set prompt $를 가지고 $-sign으로 설정할수 있다.
show: info와 대조적으로, show는 GDB 자체의 상태를 기술한다. 여러분은 여러분이 show 할수 있는 것들의 대부분을 set 명령어를 사용하여 바꿀수 있다; 예를 들어, 여러분은 몇개의 시스템이 set radix로 출력을 위해 사용되었는지, 또는 show radix로 현재 사용된 시스템 갯수를 조사할수 있다. 모든 설정 가능한 인자들과 현재 값들을 보여주기 위해, 여러분은 인자 없이 show를 사용할수 있다; 여러분은 또한 info set도 사용할수 있다. 두개의 명령어들은 같은 출력을 보여준다.

여기에 set 명령어외에 3개의 나머지 show 하위 명령어들이 있다.

show version: 돌아가고 있는 GDB 버전을 보여준다. 여러분은 GDB 버그-리포트에 이 정보를 포함해야 한다. 만일 GDB의 여러 버전을 여러분의 시스템에서 사용하고 있다면, 여러분은 돌아가고 있는 GDB의 버전을 결정하길 원할 것이다.; GDB가 업그레이드 될때마다 새로운 명령어가 소개되고 예전 것들은 없어질지 모른다. 버전은 여러분이 GDB를 시작할때마다 소개된다.
show copying: GDB 배포 허가권에 관한 정보를 보여준다.
show warranty: GNU "NO WARRANTY" 문장을 보여준다.

GDB에서 프로그램 실행시키기

여러분이 GDB에서 프로그램을 돌릴때, 우선 여러분은 소스를 컴파일할때 디버깅 정보를 만들어야 한다. 여러분은 선택한 환경 하에서 인자를 가지고 GDB를 시작할수 있다. 여러분은 프로그램의 입력과 출력을 리다이렉션할수도 있고, 이미 돌아가고 있는 프로세스를 디버깅할수도 있고, 자식 프로세스를 죽일수도 있다.

디버깅을 위한 컴파일

프로그램을 효율적으로 디버깅하기 위해, 여러분은 소스를 컴파일할때 디버깅 정보를 만들어야 한다. 이 디버깅 정보는 오브젝트 파일에 저장된다; 그것은 각 변수의 데이타 타입이나 함수를 기술한다. 그리고 소스 라인 수와 실행 코드내에서의 주소사이를 대응시킨다.

디버깅 정보를 위해, 여러분은 컴파일러를 돌릴때 `-g' 옵션을 지정해야 한다.

많은 C 컴파일러는 `-g' 와 `-O' 옵션을 같이 처리할수 없다. 이들 컴파일러를 사용할때, 여러분은 디버깅 정보를 포함하는 최적화된 실행 화일을 만들수 없다.

GNU C Compiler인 GCC는 최적화된 코드를 디버깅하는것이 가능하도록 만들기 위해 `-g'에 `-O'를 가지거나 가지지 않은것을 지원한다. 우리는 여러분이 프로그램을 컴파일 할때마다 `-g'옵션을 사용하길 추천한다. 여러분은 프로그램이 정확하다고 생각할수 있지만, 알수 없는 문제가 있을수 있다.

여러분이 `-g -O'를 가지고 컴파일된 프로그램을 디버깅할때, 옵티마이저(optimizer)는 여러분의 코드를 재배열한다.; 디버거는 여러분에게 무엇이 있는지를 보여준다. 실행 경로가 정확히 여러분의 소스 파일과 일치되지 않는다고 너무 놀라지 마라! 극단적인 예로: 만일 여러분이 변수를 정의하였지만 결코 그것을 사용하지 않았다면, GDB는 결코 그 변수를 보지 못한다.--왜냐하면 컴파일러는 그 변수를 존재 하지 않는것으로 최적화 하기 때문이다.

몇몇 경우에 특히 명령어 스케줄링을 하는 머신에서, `-g -O'는 `-g'만큼 잘 작동하지 않는다. 만일 의심스럽다면, `-g'만 가지고 재 컴파일 해라. 그리고 이것이 문제를 해결한다면, 버그(테스트 경우를 포함하여!)를 우리에게 리포팅해라.

GNU C 컴파일러의 예전 버전은 디버깅 정보를 위한 다양한 옵션 `-gg' 를 허용한다. GDB는 더이상 이 형식을 지원하지 않는다; 만일 여러분의 GNU C 컴파일러가 이 옵션을 가진다면, 더이상 사용하지 마라.

프로그램 시작하기

run
r: GDB에서 프로그램을 시작하기 위해서 run 명령어를 사용해라. 여러분은 우선 프로그램 이름(VxWorks를 제외하고)을 지정하거나 file 나 exec-file 명령어를 사용해서 지정해야 한다.(파일을 지정하기 위한 명령어들 섹션을 참조해라.)

만일 여러분이 프로세스를 지원하는 실행 환경하에서 프로그램을 돌린다면, run은 하위 프로세스를 만들고, 그 프로세스가 여러분의 프로그램하에서 돌아가도록 만든다. (프로세스가 없는 환경에서, run은 프로그램을 시작하기 위해 이동한다.)

프로그램의 실행은 상위 프로세스에서 받은 정보에 의해 영향을 받는다. GDB는 이 정보를 제공하기 위한 방법을 제공하며, 여러분은 프로그램을 시작하기 전에 해야 한다.(여러분은 프로그램을 시작한 후 바꿀수 있지만, 그런 변화는 프로그램을 시작하는 다음 번부터 영향을 준다.) 이 정보는 4개의 범주로 나누어 진다.

인자들.: run 명령어의 인자로써 프로그램에 주기 위한 인자를 지정한다. 만일 shell을 여러분의 타겟에서 이용할수 있다면, shell은 인자를 전달하기 위해 사용되며 여러분은 인자를 기술할때 편하게(wildcard 확장이나 변수 치환) 사용할수 있다. Unix 시스템에서, 여러분은 SHELL 환경 변수에서 사용된 shell을 제어할수 있다. 프로그램 인자들 섹션을 참조해라.
환경 변수.: 여러분의 프로그램은 GDB에서 환경을 상속받지만, 여러분은 프로그램에 영향을 주는 환경의 일부분을 변경 위해 GDB 명령어 set environment 와 unset environment를 사용할수 있다. 프로그램 환경섹션을 참조해라.
작업 디렉토리.: 여러분의 프로그램은 GDB에서 작업 디렉토리를 상속받는다. 여러분은 GDB에서 cd명령어를 사용하여 GDB 작업 디렉토리를 설정할수 있다. 프로그램의 작업 디렉토리섹션을 참조해라.
표준 입력과 출력.: 여러분의 프로그램은 GDB에서 사용할때 처럼 표준 입력과 출력을 위해 같은 장치를 사용한다. 여러분은 run 명령어 라인에서 표준 입력과 출력을 리다이렉션 할수 있으며 여러분은 프로그램에 다른 장치를 설정하기 위해 tty를 사용할수 있다. 프로그램의 입력과 출력섹션을 참조해라. 경고: 입력과 출력 리다이렉션이 작동하는 동안, 여러분은 다른 프로그램을 디버깅하는 프로그램의 출력을 전달하기 위해 파이프를 사용할수 없다.; 만일 여러분이 이것을 시도한다면, GDB는 프로그램을 잘못 디버깅 하는것이 된다.

여러분이 run명령어를 사용하면, 여러분의 프로그램은 즉시 실행된다. 프로그램을 멈추기 위해 재배열하는 방법에 대해 토론하고자 하면, 중지와 계속 섹션을 참조해라. 일단 여러분의 프로그램이 중지한다면, 여러분은 print나 call명령어를 사용하여 프로그램내 함수를 호출할수 있다. 데이타 검사 섹션을 참조해라.

GDB가 심볼을 읽은 마지막 시간이후 심볼 파일의 수정 시간이 바뀐다면, GDB는 그 심볼 테이블 버리고 다시 읽어들인다. 심볼을 다시 읽을때, GDB는 현재 breakpoint를 유지할려고 한다.

프로그램 인자들

여러분의 프로그램 인자들은 run 명령어의 인자에 의해 지정 된다. 인자들은 shell로 전달되고, wildcard 문자들로 확장되고 I/O의 리다이렉션을 이행하며 프로그램에 전달된다. 여러분의 SHELL 환경 변수(만일 존재한다면)는 GDB가 무슨 shell을 사용하는지를 지정한다. 만일 여러분이 SHELL을 정의하지 않았다면, GDB는 /bin/sh을 사용한다.

인자가 없는 run은 전의 run에 의해 사용된 같은 인자나 set args 명령어에 의해 설정된 인자를 사용한다.

set args: 여러분의 프로그램이 돌아가는 다음 번에 사용하기 위한 인자들을 지정한다. 만일 set args가 인자가 없다면, run은 인자 없이 프로그램을 실행시킨다. 일단 여러분이 인자를 가지고 프로그램을 돌릴때 다음번 run하기전에 set args을 사용하는것은 인자 없이 다시 돌리기 위한 유일한 방법이다.
show args: GDB가 실행됐을때 프로그램에 준 인자들을 보여준다.

프로그램 환경

environment는 환경 변수들하고 값들로 이루어진다. 환경 변수들은 여러분의 사용자 이름, 홈 디렉토리, 터미널 타입 그리고 돌리는 프로그램의 탐색 경로등을 기록한다. 보통 여러분은 shell에서 환경 변수를 설정한다. 그리고 여러분이 돌리는 다른 프로그램 모두에 의해 상속된다. 디버깅때, 다시 GDB를 시작 하는것 없이 수정된 환경 변수로 여러분의 프로그램을 돌리는데 유용하다.

path directory

GDB와 프로그램 양쪽 모두를 위해 PATH 환경 변수(실행을 위한 탐색 경로)앞에 directory를 추가한다. 여러분은 `:'나 whitespace로 분리되는 몇몇 디렉토리 이름을 지정해야 한다. 만일 directory가 경로에 이미 있다면, 앞으로 이동시키고 빨리 찾게 된다. 여러분은 GDB가 경로를 탐색할때 현재 작업 디렉토리가 무엇인지를 참조하기 위해 `$cwd'를 사용할수 있다. 만일 여러분이 `.'를 사용한다면, 그것은 여러분이 path 명령어를 실행하는 디렉토리를 가리킨다. GDB는 탐색 경로에 directory를 추가하기 전에 directory 인자(현재 경로를 가지고 있는)에 있는 `.'를 바꾼다.

show paths

실행을 위한 탐색 경로 리스트를 보여준다.(PATH 환경 변수)

show environment [varname]

시작할때 프로그램에 준 환경변수 varname의 값을 출력한다. 만일 여러분이 varname를 지정하지 않는다면, 여러분의 프로그램에 주어진 모든 환경변수들의 이름과 값들을 출력한다. 여러분은 env로써 environment를 축약할수 있다.

set environment varname [=] value

환경 변수 varname를 value로 설정한다. 이 값은 GDB 자체가 아닌 여러분의 프로그램에서만 바뀐다. value는 어떤 문자열이다; 환경 변수의 값은 단지 문자열이며 해석은 여러분의 프로그램 자체에 의해서 제공된다. value인자는 선택적이다; 만일 없다면, 변수는 null값으로 설정된다. 예를 들어, 이 명령어는:

set env USER = foo

Unix 프로그램에게 사용자의 이름은 `foo'이라고 말하는 것이다. (`='근처의 스페이스는 여기서 명확히 사용되었다; 그들은 실제로 요구되지는 않는다.)

unset environment varname

환경 변수에서 여러분의 프로그램에 전달된 변수 varname를 제거한다. 이것은 `set env varname ='와는 다르다; unset environment는 빈 값으로 대입하기보다는 환경변수에서 변수를 제거한다.

경고: 만일 shell이 존재한다면(또는 없다면 /bin/sh) GDB는 SHELL 환경 변수가 가리키는 shell을 사용하여 여러분의 프로그램을 돌린다. 여러분의 SHELL 변수는 초기화 파일에서 돌리는 shell이라면--C-shell 에서 `.cshrc', BASH에서 `.bashrc'--여러분은 프로그램에 영향을 주는 그 파일에 변수를 설정할수 있다. 여러분은 환경변수의 설정을 `.login'나 `.profile'과 같이 로그인할때 돌아가는 파일로 옮길수 있다.

프로그램 작업 디렉토리

여러분이 run로 프로그램을 시작할때마다, GDB의 현재 작업디렉토리에서 작업 디렉토리를 상속받는다. GDB 작업 디렉토리는 부모 프로세스에서 상속되는 것이 무엇이든지 초기화 하지만, 여러분은 cd 명령어로 GDB내에서 새로운 작업 디렉토리를 지정할수 있다.

GDB 작업 디렉토리 또한 작업을 위해 GDB에서 파일을 지정하는 명령어를 기본적으로 제공된다. 파일을 지정하는 명령어들 섹션을 참조해라.

cd directory: GDB 작업 디렉토리를 directory으로 설정한다.
pwd: GDB 작업 디렉토리를 출력한다.

프로그램의 입력과 출력

기본적으로, GDB에서 여러분이 돌리는 프로그램은 GDB가 사용하는 같은 터미널에 입력과 출력을 한다. GDB는 터미널을 여러분과 대화하기 위한 모드로 바꾼다. 그러나 GDB는 프로그램이 사용하는 터미널 모드를 기록한뒤 여러분이 프로그램을 다시 돌릴때 다시 바꾼다.

info terminal: 프로그램이 돌아가는 터미널 모드에 대해 GDB에 의해 기록된 정보를 보여준다.

여러분은 run 명령어시 가지는 shell 리다이렉션을 사용하여 프로그램의 입력과 추력을 리다이렉션 할수 있다. 예를 들어,

run > outfile

프로그램을 시작하면, 출력을 `outfile'으로 돌린다.

프로그램의 입력과 출력을 지정하기 위한 또 다른 방법은 tty 명령어이다. 이 명령어는 인자로 파일 이름을 가지며 다음 run 명령어시 기본적으로 이 파일을 사용한다. 또한 이것은 다음 run 명령어를 위해, 자식 프로세스를 위한 터미널 제어를 리셋한다. 예를 들어,

tty /dev/ttyb

연속적인 run 명령어를 가지고 시작하는 프로세스들은 터미널 `/dev/ttyb'에 입력과 출력을 하며 제어 단말기로써 이것을 사용한다.

run에서의 명백한 리다이렉션은 tty 명령어를 무효화 시키고 입출격 장치에서 효과을 가진다. 그러나 제어 단말기에서난 효과가 없다.

여러분이 tty명령어나 run명령어에서 입력을 리다이렉션 시킬때, 여러분의 프로그램를 위한 입력만이 영향을 받는다. GDB에서의 입력은 여전히 단말기에서 나온다.

이미 돌고 있는 프로세스 디버깅하기

attach process-id: 이 명령어는 작동중인 프로세스를 연결시킨다--GDB 밖에서 시작된 프로세스. (info files는 여러분의 엑티브된 타겟을 보여준다.) 명령어는 프로세스 ID를 인자로 가진다. Unix 프로세스 중 프로세스 ID를 찾기 위한 일반적인 방법은 ps 를 이용하거나 `jobs -l' shell 명령어를 가지고 한다. 만일 여러분이 명령어 실행후 2번 RET를 누른다면 attach 는 반복하지 않는다.

attach를 사용하기 위해, 여러분의 프로그램은 프로세스를 지원하는 환경하에서 돌아가야 한다.; 예를 들어, attach는 OS가 없는 bare-보드 타겟의 프로그램에서는 작동하지 않는다. 여러분은 또한 신호를 보내기 위한 허가권이 있어야 한다.

attach를 사용할때, 여러분은 프로세스에서 돌아가는 프로그램을 지정하기 위해 file 명령어를 우선 사용해야 한다. 그리고 심볼 테이블을 로드해야 한다. 파일을 지정하기 위한 명령어 섹션을 참조해라.

지정된 프로세스를 디버깅하기 위해 재배열후 GDB가 해야할 첫번째 일은 프로세스를 멈추는 것이다. 여러분은 run으로 프로세스를 돌릴때 GDB의 모든 명령어를 가지고 부착된 프로세스를 검사하고 수정할수 있다. 여러분은 breakpoint를 설정할수 있다; 여러분은 step과 continue를 할수 있다; 여러분은 스토리지를 수정 할수 있다. 만일 여러분이 프로세스가 계속 돌아가도록 할려면, 프로세스를 GDB에 부착시킨후 continue 명령어를 사용해야 한다.

detach: 여러분이 부착된 프로세스 디버깅을 마쳤을때, GDB 제어에서 프로세스를 놓아줄려면 detach 명령어를 사용해야 한다. 프로세스를 떼어내도 실행은 계속된다. detach 명령어 후, 프로세스와 GDB는 완전히 독립적이되며 여러분은 다른 프로세스를 attach 시키거나 run로 프로세스를 시작할수 있다. 여러분이 명령어 실행후 다시 RET를 누른다면 detach는 반복되지 않는다.

여러분이 GDB를 나가거나 부착시킨 프로세스를 가지고 있는 동안 run 명령어를 사용하면, 여러분은 그 프로세스를 죽여야 한다. 기본적으로, GDB는 여러분이 이것들 중 하나를 했는지를 확신하기 위해 질의한다.; 여러분은 set confirm명령어를 사용하여 확실히 할 필요가 있는지 없는지를 제어할수 있다.(경고 옵션들과 메세지들 섹션을 참조해라.)

자식 프로세스 죽이기

kill: GDB에서 돌아가는 자식 프로세스를 죽인다.

만일 여러분이 돌아가고 있는 프로그램 대신 코어 덤프를 디버깅하려고 한다면 이 명령어는 유용하다. GDB는 프로그램이 돌아가고 있는 동안 코어 덤프 파일을 무시한다.

몇몇 OS에서, 여러분이 GDB내에서 프로그램에 breakpoint를 걸어둔 경우 GDB외에서 이 프로그램을 실행할수 없다. 여러분은 이런 상황에서 디버거 밖에서 이 프로그램을 돌릴수 있도록 하기 위해 kill명령어를 사용할수 있다.

만일 여러분이 프로그램을 재 컴파일하고 다시 링크한다고 해도 kill명령어는 유용하다. 왜냐하면 많은 시스템에서 프로세스가 돌아가는 동안 실행 파일을 수정하는것이 불가능하기 때문이다. 이런 경우 다음 번 run에서, GDB는 파일이 바뀌었다는 것을 인식하며 심볼 테이블을 다시 읽는다. (여러분의 현재의 breakpoint 설정값을 보존할려고 시도하는 동안)

추가적인 프로세스 정보

몇몇 OS는 파일 시스템 서브루틴을 사용하는 작동중인 프로세스의 이미지를 검사하기 위해 사용될수 있는 `/proc'이라 불리는 기능을 제공한다. 만일 GDB가 이 기능을 가진 OS에서 작동중이라면, info proc명령어는 프로그램이 돌아가는 프로세스에 관한 몇가지 정보를 보고 하기 위해 이용될수 있다. info proc는 procfs를 지원하는 SVR4 시스템에서만 작동한다.

info proc: 프로세스에 관한 이용가능한 정보를 요약한다.
info proc mappings: 프로그램에서 접근할수 있는 주소를 각 범위의 읽기,쓰기,실행인지 아닌지에 관한 정보와 함께 보여준다.
info proc times: 프로그램과 자식을 위한 사용자 CPU 시간, 시스템 CPU 시간을 시작한다.
info proc id: 프로그램과 관련된 프로세스 ID를 보고한다; 자신의 프로세스 ID, 부모의 프로세스 ID, 프로세스의 그룹 ID 그리고 세션 ID.
info proc status: 프로세스의 상태에 관한 일반적 정보를 보여준다. 만일 프로세스가 중지중이라면, 이 보고는 멈춘 이유와 받은 신호를 포함한다.
info proc all: 프로세스에 관한 모든 정보를 보여준다.

다중 쓰레드인 프로그램 디버깅하기

몇몇 OS에서, 단일 프로그램은 실행시 하나이상의 쓰레드를 가질지도 모른다. 쓰레드의 정확한 의미는 OS마다 다르지만, 일반적으로 단일 프로그램에서 쓰레드는 다중 프로세스와 비슷하다.-- 하나의 주소 공간을 공유하는것을 제외하고(즉, 그들은 같은 변수를 검사하고 수정한다.) 다른 한편으로, 각 쓰레드는 자신의 레지스터와 실행스택 그리고 각자의 메모리를 가진다.

GDB는 다중 쓰레드 프로그램을 디버깅할수 있는 기능을 제공한다.

새 쓰레드에 대한 자동 알림
쓰레드를 바꿀수 있는 명령어 `thread threadno'
현재 쓰레드에 관해 질의할수 있는 명령어 `info threads'
`thread apply [threadno] [all] args' 쓰레드 리스트에 명령어를 적용할수 있는 명령어
thread별 breakpoints

경고: 이 기능은 쓰레드를 지원하는 OS하의 모든 GDB 설정에서 이용할수 있는것은 아니다. 만일 여러분의 GDB가 쓰레드를 지원하지 않는다면, 이들 명령어는 효과가 없다. 예를 들어, 쓰레드 지원을 하지 않는 시스템은 `info threads'시 정보를 보여주지 않으며 다음과 같이 thread 명령시 이를 거절한다.:
(gdb) info threads
(gdb) thread 1
Thread ID 1 not known.  Use the "info threads" command to
see the IDs of currently known threads.

GDB의 쓰레드 디버깅 기능은 프로그램을 돌리는 동안 모든 쓰레드를 관찰할수 있도록 해준다. --그러나 GDB가 제어를 가지고 있을때는 언제나, 특별히 하나의 쓰레드가 디버깅의 중심이다. 이 쓰레드는 current thread라 불린다. 디버깅 명령어는 현재 쓰레드의 관점에서 프로그램 정보를 보여준다.

GDB가 프로그램에서 새로운 쓰레드를 발견할때마다, `[New systag]' 형태로 쓰레드에 대한 타겟 시스템 식별자를 보여준다. systag는 쓰레드 식별자이며 형태는 시스템에 의존한다. 예를 들어, LynxOS에서 여러분은 다음을 볼것이다;

[New process 35 thread 27]

GDB가 새로운 쓰레드를 발견할때 볼수 있다. 대조적으로, SGI 시스템에서 systag는 단순히 `process 368'와 같다.

디버깅 목적으로, GDB는 자신의 쓰레드 수--항상 단일 정수--를 가지고 있다.

info threads

프로그램에 있는 현재 모든 쓰레드의 요약을 출력한다. GDB는 다음 순서로 각 쓰레드를 출력한다.:

GDB에 의해 대입된 쓰레드 넘버
타겟 시스템의 쓰레드 식별자(systag)
그 쓰레드를 위한 현재 스택 프레임 요약

GDB 쓰레드 넘버 왼쪽의 `*'는 현재 쓰레드를 가리킨다. 예를 들어,

(gdb) info threads
  3 process 35 thread 27  0x34e5 in sigpause ()
  2 process 35 thread 23  0x34e5 in sigpause ()
* 1 process 35 thread 13  main (argc=1, argv=0x7ffffff8)
    at threadtest.c:68

thread threadno

쓰레드 넘버 threadno를 현재 쓰레드로 만들어라. 이 명령어 인자 threadno는 `info threads' 출력의 처음 필드에서 보여준 것 처럼 내부 GDB 쓰레드 넘버이다. GDB는 여러분이 선택한 쓰레드의 시스템 식별자와 현재 스택 프레임 요약을 출력함으로써 응답한다;

(gdb) thread 2
[Switching to process 35 thread 23]
0x34e5 in sigpause ()

`[New ...]'메세지에서 처럼, `Switching to'다음의 텍스트의 형태는 쓰레드 식별을 위한 시스템 편리성에 의존한다.

thread apply [threadno] [all] args

thread apply명령어는 여러분이 하나나 그 이상의 쓰레드 명령어를 적용할수 있도록 허용한다. 여러분은 명령어 인자 threadno로 영향 받기를 원하는 쓰레드의 수를 지정해라. threadno는 `info threads' 출력의 처음 필드에서 보여준것처럼 내부 쓰레드 수이다. 모든 쓰레드에 명령어를 적용하기 위해, thread apply all args를 사용해라.

GDB가 breakpoint, signal 때문에 프로그램을 중지시킬때마다, GDB는 자동적으로 breakpoint나 signal이 일어난 쓰레드를 선택한다. GDB는 쓰레드를 식별하기 위해 `[Switching to systag]' 형태의 메세지를 가지고 문맥 교환을 하도록 해준다.

여러분이 다중 쓰레드 프로그램을 멈추고 시작할때 GDB가 행동하는 방법에 대하여 더 많은 정보를 원한다면, 다중 쓰레드 프로그램에서 중지와 시작 섹션을 참조해라.

다중 쓰레드 프로그램에서 watchpoint에 관한 정보를 원한다면 watchpoints 설정 섹션을 참조해라.

다중 프로세스를 가진 프로그램 디버깅하기

GDB는 fork함수를 사용하여 추가적인 프로세스를 만드는 프로그램을 디버깅 하기 위한 특별한 지원을 하지 않는다. 프로그램이 fork되었을때, GDB는 부모 프로세스 디버깅을 계속하며 자식 프로세스는 포함하여 돌아가지 않는다. 여러분이 자식이 실행하는 코드부분에 breakpoint를 설정했다면, 자식은 종료를 야기시키는(신호를 잡지 않는다면) SIGTRAP신호를 갖는다.

그러나, 만일 여러분이 자식 프로세스를 디버깅하기를 원한다면, 그렇게 힘들지는 않다. fork후에 자식 프로세스 코드 부분에 sleep를 호출하여 놓아라. 어떤 환경변수가 설정되었거나 어떤 파일이 존재한다면 sleep시키는 것은 유용하다. 자식이 sleep하는 동안, 프로세스 ID를 가지기 위해 ps를 사용해라. 그리고 GDB(만일 여러분이 부모 프로세스를 디버깅 중이라면 새로운 GDB를 실행)에게 자식 프로세스(이미 돌고 있는 프로세스 디버깅하기 섹션을 참조해라.)를 연결하라고 말해라. 이 시점에서, 여러분은 여러분이 연결한 다른 프로세스같이 자식 프로세스를 디버깅 할수 있다.

중지와 계속

디버거를 사용하는 원래의 목적은 여러분의 프로그램이 종료하기 전에 멈추게 할수 있다는 점이다.; 또 여러분의 프로그램에 문제가 있을 경우, 왜 그런지 조사하고 발결할수 있다.

GDB내에서, 프로그램은 signal, breakpoint 또는 step같은 GDB 명령어 후 뉴 라인에 도착했을때와 같은 몇몇 이유로 멈출수 있다. 그리고 여러분은 변수를 검사하고 바꾸거나 새로운 breakpoint를 설정하거나 예전것을 없애고 실행을 계속할수 있다. 보통, GDB가 보여주는 메세지는 프로그램 상태에 대한 충분한 설명을 보여준다.--그러나 여러분은 또한 어떤때든지 이 정보를 명백히 요구할수 있다.

info program: 프로그램의 상태에 관한 정보를 출력한다.:프로그램이 돌아가거나 아니거나, 돌아가는 프로세스가 무엇이거나와 왜 멈추었는지.

Breakpoints, watchpoints, 그리고 예외들

breakpoint는 프로그램내 어떤 위치에 도착할때마다 멈추게 한다. 각 breakpoint를 위해 여러분은 프로그램이 어디서 멈출지를 제어하기 위한 조건들을 추가할수 있다. 여러분은 break명령어와 변수(breakpoints 설정섹션을 참조해라.)로 breakpoint를 설정할수 있다. 그리고 라인 넘버와 함수 이름 또는 정확한 주소로 프로그램이 멈출수 있는 위치를 지정할수 있다. 예외 처리를 하는 언어(GNU C++처럼)에서, 여러분은 또한 예외가 일어날 곳에(Breakpoints 그리고 예외들섹션을 참조해라.) breakpoint를 설정할수 있다.

SunOS 4.x, SVR4 그리고 Alpha OSF/1 설정에서, 여러분은 실행이 되기 전에 공유 라이브러리에 breakpoint를 설정할수 있다.

watchpoint는 표현식 값이 바뀔때 여러분의 프로그램을 멈추게 하는 특별한 breakpoint이다. 여러분은 watchpoint(watchpoints 설정섹션을 참조해라.)를 설정하기 위한 다른 명령어를 사용 해야 한다. 그러나 그것외에 여러분은 다른 breakpoint같이 watchpoint를 관리 할수 있다: 여러분은 같은 명령어를 사용하여 breakpoint와 watchpoint를 가능하게, 불가능하게 그리고 제거할수 있다.

여러분은 GDB가 breakpoint에서 멈출때마다 자동적으로 출력된 값들을 배열할수 있다. 자동 디스플레이섹션을 참조해라.

GDB는 여러분이 만들때마다 breakpoint나 watchpoint에 숫자를 대입한다; 이들 넘버는 1부터 시작하는 연속적인 정수이다. breakpoint의 다양한 특징을 제어하기 위한 많은 명령어에서, 여러분은 변경을 원하는 breakpoint에 말하기 위해 breakpoint 번호를 사용한다. 각 breakpoint는 enabled되거나 disabled된다.;만일 diabled 된다면, breakpoint는 그게 다시 가능하게 될때까지 프로그램에 영향을 주지 않는다.

breakpoints 설정

Breakpoint는 break 명령어(간단히 b)로 설정한다. 디버거 편리 변수 `$bpnum'는 여러분이 가장 최근 설정한 breakpoint의 수를 기록한다; 여러분이 편리변수 가지고 할수 있는 것이 무엇인지를 토론하길 원한다면 편리 변수 섹션을 참조해라.

여러분은 breakpoint가 어디인지를 말하기 위해 여러가지 방법을 사용할수 있다.

break function

function 함수 function의 엔트리에 breakpoint를 설정한다. C++ 같은 심볼의 오버로딩을 허용하는 소스 언어를 사용할때, function은 break를 위해 한개 이상을 가질수 있다. 그런 상황을 위해서, Breakpoint 메뉴섹션을 참조해라.

break +offset

break -offset

현재 선택된 프레임에서 멈춘 실행 위치의 앞, 뒤 라인 수로 breakpoint를 설정한다.

break linenum

현재 소스 파일의 라인 linenum에 breakpoint를 설정한다. 이 파일은 소스 파일이 출력된 마지막 파일이다. 이 breakpoint는 그 라인 코드 실행전에 프로그램을 멈춘다.

break filename:linenum

소스 파일 filename의 라인 linenum에 breakpoint를 설정한다.

break filename:function

파일 filename에 있는 function 함수 엔트리에 breakpoint를 설정한다. 함수이름뿐만 아니라 파일이름 지정하는것은 여러 파일들이 같은 함수이름을 가지고 있을때를 제외하고는 불 필요하다.

break *address

address주소에 breakpoint를 설정한다. 여러분은 디버깅 정보나 소스 파일을 가지고 있지 않는 프로그램의 일부분에 breakpoint를 설정하기 위해 사용 할수 있다.

break

아무 인자 없이 호출될때, break는 선택된 스택 프레임에서 실행되고 있는 다음 명령어에 breakpoint를 설정한다.(스택 검사하기 섹션을 참조해라.) 선택된 프레임에서, 이것은 제어가 그 프레임으로 돌아오자 마자 프로그램을 멈추도록 만든다. 이것은 선택된 프레임 내 프레임에서 finish 명령어에 의한 결과와 비슷하다.--이 finish는 breakpoint를 활성화 시켜 놓지 않는다는것을 제외하고. 만일 여러분이 가장 내부 프레임에 인자 없이 break를 사용한다면, GDB는 현재 위치에 도달하는 다음번에 멈춘다; 이것은 루프내에서 유용하다. GDB는 보통 실행을 계속할때 적어도 한개의 명령어가 실행될때까지 breakpoint를 무시한다. 만일 이것을 하지 않는다면, 여러분은 breakpoint를 disable 시키는것 없이 brekapoint를 빠르게 처리할수 없다. 이 규칙은 프로그램이 멈출때 breakpoint가 이미 존재하든지 안하든지 적용된다.

break ... if cond

조건 cond로 breakpoint를 설정한다.; breakpoint에 도착할때마다 표현식 cond를 평가하고, 만일 값이 0이 아니라면 멈춘다.--즉, cond가 참으로 평가된다면. `...'는 위에 기술한 가능한 인자중 하나를 나타낸다. breakpoint 조건에 관한 더 많은 정보를 위해 Break 조건들 섹션을 참조해라.

tbreak args

한번만 멈추도록 breakpoint를 설정한다. Set a breakpoint enabled only for one stop. args는 break 명령어와 같으며, breakpoint는 같은 방법으로 설정된다. 그러나 breakpoint는 자동적으로 프로그램이 한번 멈춘 다음에 지워진다. breakpoints disable하기 섹션을 참조해라.

hbreak args

하드웨어-지원 breakpoint를 설정한다. args는 break 명령어와 같으며 breakpoint는 같은 방법으로 설정된다. 그러나 breakpoint는 하드웨어 지원을 요구하며 몇몇 하드웨어 타겟은 이러한 지원을 하지 않는다. 이 명령어의 주요 목적은 EPROM/ROM 코드 디버깅이며, 여러분은 명령어를 바꾸는것 없이 명령어에 breakpoint를 설정할수 있다. 이 명령어는 SPARClite DSU가 제공하는 새로운 trap-발생시 사용될수 있다. DSU는 프로그램이 몇몇 데이터나 레지스터를 디버깅하기 위해 할당된 명령어 주소를 접근할때 trap을 발생한다. 그러나 하드웨어 breakpoint 레지스터는 두개의 데이터 breakpoint를 가지며 GDB는 두개 이상이 사용된다면 이 명령어를 거절한다. 새로운 것으로 설정하기 전에 사용되지 않는 하드웨어 breakpoint를 delete 하거나 disable 한다. Break conditions 섹션을 참조해라.

thbreak args

한번 멈추는것이 가능하도록 하드웨어-지원 breakpoint를 설정한다. args는 hbreak 명령어와 같으며 breakpoint는 같은 방법으로 설정된다. 그러나, tbreak 명령어처럼, breakpoint는 자동적으로 프로그램이 처음 멈춘다음에 지워진다. 또한, hbreak 처럼, breakpoint는 하드웨어 지원을 요구하며 몇몇 타겟 하드웨어는 이러한 지원을 하지 않는다. breakpoints disable하기 섹션을 참조해라. 또한, Break 조건들 섹션을 참조해라.

rbreak regex

정규식 표현식 regex와 매치되는 모든 함수에 breakpoint를 설정한다. 이 명령어는 아무 조건없이 일치하는 모든것에 breakpoint를 설정하며 설정된 모든 breakpoint 리스트를 출력한다. 일단 이들 breakpoint가 설정되면, 그것들은 break 명령어로 설정된 breakpoint처럼 처리된다. 여러분이 그것을 지우고, disable하거나 다른 breakpoint처럼 조건적인 같은 방법으로 만들수 있다. C++ 프로그램을 디버깅할때, rbreak는 어떤 특정 클래스의 멤버가 아닌 오버로딩된 함수에 breakpoint를 설정할때 유용하다.

info breakpoints [n]

info break [n]

info watchpoints [n]

Print a table of all breakpoints and watchpoints set and not deleted, with the following columns for each breakpoint:

Breakpoint Numbers
Type: breakpoint나 watchpoint.
Disposition: 발견되었을때 breakpoint가 disable되었는지 deleted되었는지.
Enabled or Disabled: enable된 breakpoint를 `y'로 표시한다. `n' 는 enable되지 않은 breakpoint를 나타낸다.
Address: 메모리 조수처럼 프로그램내 breakpoint가 어디에 있는지.
What: 파일과 라인 넘버처럼 프로그램 소스에서 breakpoint가 어디에 있는지.

만일 breakpoint가 조건적이라면, info break는 다음에 영향 받는 breakpoint의 조건을 보여준다.; 어떤것이 있다면, breakpoint 명령어는 그것 다음에 나열된다. 인자로 breakpoint 넘버 number n 을 가지는 info break는 그 breakpoint에서만 나열된다. 편리 변수 $_과 x 명령어를 위한 기본 검사-주소는 나열된 마지막 breakpoint의 주소로 설정한다. (메모리 검사하기. 섹션을 참조해라.) info break 는 breakpoint가 히트된 수를 출력한다. 이것은 특히 ignore명령어와 연결되어 사용될때 유용하다. 여러분은 breakpoint 히트 수를 무시할수 있으며, breakpoint가 얼마나 많이 히트되었는지 보기 위해 breakpoint info를 볼수 있으며 그 수보다 작은것은 무시하고 다시 돌릴수 있다. 이것은 여러분이 그 breakpoitn의 마지막 히트를 빠르게 가지게 한다.

GDB는 프로그램내 같은 곳에 여러개의 breakpoint를 설정하는걸 허용한다. 이것이 어리석거나 의미없는것은 아니다. breakpoint들이 추가될때, 이것은 유용하다. (Break 조건들 섹션을 참조해라.).

GDB는 가끔 longjmp(C 프로그램에서)의 처리 같은 특별한 목적을 위해 프로그램에 breakpoint를 설정한다. 이들 내부 breakpoint들은 -1로 시작하여 음수 넘버를 할당받는다.; `info breakpoints'는 그것들을 출력하지 않는다.

여러분은 GDB 유지 명령어 `maint info breakpoints'로 이들 breakpoint들을 볼수 있다.

maint info breakpoints

Using the same format as `info breakpoints'와 같은 형식을 사용하여, 여러분이 명확히 설정한 breakpoint 두개를 출력한다. 그리고 GDB는 이것들을 내부 목적으로 사용한다. 내부 breakpoint들은 음수의 breakpoint 수처럼 보인다. 타입 컬럼은 breakpoint의 종류가 무엇인지를 보여주는것을 식별한다.:

breakpoint: 보통, 명확히 breakpoint를 설정한다.
watchpoint: 보통, 명확히 watchpoint를 설정한다. Normal, explicitly set watchpoint.
longjmp: longjmp 호출을 통해 정확한 stepping을 처리하기 위해 사용된 내부 breakpoint
longjmp resume: longjmp의 타겟에 내부 breakpoint
until: GDB until 명령어에 의해 사용되는 임시 내부 breakpoint.
finish: GDB finish 명령어에 의해 사용되는 임시 내부 breakpoint.

watchpoints 설정

여러분이 변화가 일어날곳을 예상하는것 없이 표현식 값이 바뀔때마다 실행을 멈추고자 하면 watchpoint를 사용할수 있다.

Watchpoint는 현재 다른 breakpoint보다 더 천천히 2배의 규모로 실행된다. 그러나 이것은 프로그램의 어느 부분이 잘못되었는지 실마리를 잡지 못할때 에러를 잡기 위한 충분한 가치가 있다.

watch expr: 표현식을 위해 watchpoint를 설정한다. GDB는 expr이 프로그램에 쓰여지고 그 값을 바꿀때 break된다. 이것은 SPARC lite DSU에 의해 제공되는 새로운 trap-발생시 사용된다. DSU는 프로그램이 몇몇 데이터나 레지스터를 디버깅하기 위해 할당되는 명령어 주소에 접근할때 trap을 발생한다. 그러나 하드웨어 breakpoint register들은 두개의 데이터 watchpoint를 가진다. 그리고 두개의 watchpoint는 같은 종류이어야 한다. 예를 들어, 여러분은 watch 명령어로, rwatch 명령어로, 또는 awatch 명령어로 두개의 watchpoint를 설정할수 있다. 그러나 여러분은 한 명령어아 다른 이름으로 다른 명령어로 한개의 watchpoint를 설정할수 없다. 만일 여러분이 watchpoint를 섞는다면 명령어는 거절될 것이다. 새로운 것으로 설정하기전에 사용되지 않은 watchpoint 명령어를 지우거나 disable해라.
rwatch expr: args가 프로그램에 의해 읽혀졌을때 break될 watchpoint를 설정한다. 만일 여러분이 두개의 watchpoint를 사용한다면, 두개는 rwatch 명령어로 설정되어야 한다.
awatch expr: args를 읽고 프로그램에 의해 쓰여질때 break될 watchpoint를 설정한다. 만일 여러분이 두개의 watchpoint를 사용한다면, 두개는 awatch 명령어로 설정되어야 한다.
info watchpoints: 이 명령어는 watchpoint와 breakpoint의 리스트를 출력한다.; info break와 같다.

경고: 멀티-쓰레드 프로그램에서, watchpoint는 그 유용성이 제한된다. 현재 watchpiont 수행에서, GDB는 단일 쓰레드의 표현식 값만을 볼수 있다. 만일 여러분이 표현식이 현재 쓰레드의 활성화(그리고 만일 여러분이 어떤 다른 쓰레드도 현재 쓰레드가 될수 없다고 확신한다면)때문에 바뀐다고 확신한다면, 여러분은 보통때처럼 watchpoint를 쓸수 있다. 그러나, GDB는 현재 쓰레드가 아닌 쓰레드의 활성화가 표현식을 바꿀 때 인식하지 못한다.

Breakpoints 그리고 예외들

GNU C++같은 몇몇 언어에서 예외 처리를 다룬다. 여러분은 프로그램에서 예외가 일어난 원인과 주어진 시점에서 프로그램이 처리를 준비해야할 예외들의 리스트를 검사하기 위해 GDB를 사용할수 있다.

catch exceptions: 여러분은 catch 명령어를 사용하여 실제 예외 처리기에 breakpoint를 설정할수 있다. exceptions는 잡아야할 예외들의 이름 리스트들이다.

여러분은 활동적인 예외 핸들러으 리스트를 위해 info catch를 사용할수 있다. 프레임에 관한 정보 섹션을 참조해라.

GDB내에 예외 처리를 위해 몇몇 제한들이 있다.:

여러분이 함수를 호출한다면, GDB는 보통 함수가 실행을 마쳤을때 제어를 반환한다. 그러나 만일 호출시 예외가 발생한다면, 호출은 프로그램이 breakpoint나 여러분에게 제어를 반환하는 매카니즘을 그냥 지나친다. 그리고 프로그램이 breakpoint나 GDB가 기다리거나 종료시 신호를 받을때까지 실행을 계속하도록 프로그램을 야기시키는 메카니즘을 그냥 지나친다.
여러분은 예외를 일으킬수 없다.
여러분은 예외 처리기를 설치할수 없다.

가끔 catch는 예외 처리기를 디버깅하기 위한 최선의 방법이 아니다: 만일 여러분이 정확히 예외가 일어난 곳이 어디인지를 알고자 한다면, 예외 처리기가 호출되기 before에 멈추게 하는것이 좋다. 왜냐하면 그 방법으로 여러분은 의도하지 않은 일이 일어나기 전의 스택을 볼수 있기 때문이다. 만일 여러분이 예외 핸들기 대신에 breakpoint를 설정한다면, 예외가 일어난 곳을 발견하기가 쉽지 않다.

예외 핸들기가 호출되기 전에 멈추기 위해, 여러분은 약간의 지식이 필요하다. GNU C++의 경우에, 예외는 다음과 같은 ANSI C 인터페이스를 가지고 있는 __raise_exception라는 이름의 라이브러리 함수 호출에 의해 발생한다.

    /* addr is where the exception identifier is stored.
       ID is the exception identifier.  */
    void __raise_exception (void **addr, void *id);

의도하지 않은 일이 일어나기 전에 모든 예외들을 디버거하도록 만들기 위해, __raise_exception에 breakpoint를 설정해라. (Breakpoints, watchpoints, 그리고 예외들섹션을 참조해라.)

id값에 의존하는 조건적 breakpoint(Break conditions섹션을 참조해라>)를 가지고, 여러분은 특정 예외가 일어날때 프로그램을 멈출수 있다. 여러분은 예외 넘버중 하나가 일어났을때 프로그램을 멈추기 위해 다중 조건 breakpoint를 사용할수 있다.

breakpoints 설정 지우기

breakpoint나 watchpoint가 작업을 마치고 더이상 거기에서 멈추길 원하지 않는다면 삭제하는것이 가끔 필요하다. 이것을 breakpoint 지우기라고 한다. 삭제된 breakpoint는 더이상 존재하지 않는다; 잊혀진다.

clear명령어로 여러분은 프로그램에 있는곳에 따라 breakpoint를 지울수 있다. delete명령어로 여러분은 breakpoint넘버를 지정하여 개개의 breakpoint나 watchpoint를 지울수 있다.

예전것을 위해 brekapoint를 지울 필요는 없다. GDB는 여러분이 실행 주소를 바꾸지 않고 실행을 계속할 경우 실행의 처음 명령어에 있는 breakpoint를 자동적으로 무시한다.

clear: 선택된 스택 프레임에서 실행되기 위해 다음 명령어의 breakpoint를 지운다. (프레임 선택하기 섹션을 참조해라.) 가장 내부의 프레임이 선택되었을때, 여러분의 프로그램이 멈춘 곳의 breakpoint를 지우는것은 좋은 방법이다.
clear function
clear filename:function: 함수 function의 엔트리에 설정된 breakpoint를 지운다.
clear linenum
clear filename:linenum: 지정된 라인의 코드나 코드내에 있는 breakpoint를 지운다.
delete [breakpoints] [bnums...]: 인자로 지정된 수의 breakpoint나 watchpoint를 지운다. 만일 인자가 지정되지 않는다면, 모든 breakpoint를 지운다.(만일 여러분이 set confirm off를 설정하지 않았다면 GDB는 확인을 요구한다.) 여러분은 d로 명령어를 축약할수 있다.

breakpoints Disable 시키기

breakpoint나 watchpoint를 지우기 보다, 여러분은 그것들을 disable 시키는 것이 더 좋다. 이것은 마치 지워진것처럼 breakpoint가 작동하지 않도록 만든다. 그러나 breakpoint에 대한 정보를 기억한다. 그래서 여러분은 나중에 다시 그것을 enable 시킬수 있다.

여러분은 옵션으로 인자로 하나나 그 이상의 breakpoint를 지정하여, enable, disable 명령어로 breakpoint와 watchpoint를 disable, enable 시킬수 있다. 만일 여러분이 사용하고 있는 넘버를 알지 못한다면, breakpoint나 watchpoint의 리스트를 보기 위해 info break나 info watch를 사용해라.

breakpoint나 watchpoint는 4가지의 다른 가능 상태를 가지고 있다.

Enabled. breakpoint는 프로그램을 멈춘다. break로 설정한 breakpoint 는 이상태로 시작한다.
Diabled. breakpoint가 프로그램에서 영향이 없다.
Enabled once. breakpoint는 프로그램을 일시중지시킨다. 그러나 그다음 disable 시킨다. tbreak를 가지고 설정된 breakpoint는 이 상태로 시작한다.
Enabled for deletion. breakpoint는 프로그램을 일시중지시키지만, 그렇게 한후 영구히 제거된다.

여러분은 breakpoint와 watchpoint를 enable, disable 시키기 위해 다음 명령어를 사용할수 있다:

disable [breakpoints] [bnums...]: 지정된 breakpoint를 Disable 시킨다--만일 어떤것도 리스트되지 않았다면, 모든 breakpoit가 해당된다. disabled breakpoint는 효과는 없지만 잊혀지지는 않는다. ignore-count, condition과 같은 옵션과 명령어들은 breakpoint가 enable될때 다시 기억된다. 여러분은 dis로 disable를 축약할수 있다.
enable [breakpoints] [bnums...]: 지정된 breakpoint를(또는 모든 정의된 breakpoint) Enable 시킨다. 그것들은 프로그램을 중지할때 한번만 효과가 있다.
enable [breakpoints] once bnums...: 지정된 breakpoint를 임시적으로 Enable 시킨다. GDB는 프로그램을 멈춘후 즉시 이들 breakpoint를 disable 시킨다.
enable [breakpoints] delete bnums...: 한번 작동시키기 위해 지정된 breakpoint를 enable 시키고 죽는다. GDB는 프로그램이 멈추자 마자 이들 breakpoint들을 지운다.

tbreak(Setting breakpoints섹션을 참조해라.)로 설정된 breakpoint를 제외하고, 여러분이 설정한 breakpoint는 enable 된다; 연속적으로, 이것들은 여러분이 위의 명령어중 하나를 사용할때 disable되거나 enable 된다.(명령어 until는 자신의 breakpoint를 설정하고 지운다. 그러나 다른 breakpoint의 상태는 바꾸지 않는다; 계속과 중지 섹션을 참조해라.)

중지 조건들

breakpoint의 간단한 성질은 프로그램이 지정된 위치에 도달할때마다 중지한다는 점이다. 여러분은 breakpoint를 위해 condition를 지정할수 있다. 조건은 프로그램 언어에서 Boolean 표현이다.(표현식섹션을 참조해라.) 조건을 가지고 있는 breakpoint는 프로그램이 그곳에 도착할때마다 표현식을 평가한다. 그리고 프로그램은 조건이 true일경우 멈춘다.

이것은 프로그램 유효성을 위한 것이다; 그 상황에서, 여러분은 주장하는것이 위반일 경우 멈춘다. -- 즉, 조건이 거짓일때이다. C에서, 만일 여러분이 조건 assert으로 해당 조건을 테스트하길 원한다면, 여러분은 적당한 breakpoint에 `! assert'조건을 설정해야 한다.

조건들은 watchpoint를 받아들인다.; watchpoint는 어쨋든 표현식의 값을 조사하기 때문에 여러분들은 그것들이 필요하지 않다.--그러나 변수이름에 watchpoint를 설정하는것은 간단하다. 그리고 새로운 값이 흥미로운 값인지를 검사하기 위한 조건들을 지정한다.

중지 조건들은 역효과를 가질수 있다. 그리고 여러분의 프로그램내 함수 호출때조차도 가질수 있다. 예를 들어, 프로그램 진행이나 특별한 데이타 구조형태로 함수를 출력하길 원할때 함수를 활성화하는데 유용하다. 같은 주소에 다른 enable된 breakpoint만 없다면 효과는 예상하는 대로이다.(그 경우, GDB는 우선 다른 breakpoint를 보고 해당 조건을 검사하지 않고 프로그램을 멈춘다.) breakpoint명령어는 보통 breakpoint가 도착할때 역효과 이행 목적에 더 편리하고 유동적이다.

중지 조건들은 break명령어에 인자로 `if'를 사용하여, breakpoint가 설정될때 지정할수 있다. breakpoints 설정하기 섹션을 참조해라. 그것들은 condition명령어를 가지고 어떤때든지 바꿀수 있다. watch명령어는 if 키워드를 인식하지 못한다; condition는 watchpoint에서 조건을 부여하기 위한 유일한 방법이다.

condition bnum expression: breakpoint나 watchpoint 넘버 bnum를 위한 break 조건으로써 expression를 지정한다. 여러분이 조건을 설정한후, 만일 expression 값이 참(C에서 0이 아닌 경우)이라면 breakpoint bnum는 프로그램을 멈춘다. 여러분이 condition을 사용할때, GDB는 즉시 문법이 맞는지를 위해 expression를 검사한다. 그리고 심볼들이 여러분의 breakpoint의 문맥에 참조를 가지고 있는지를 결정한다. GDB는 실제 condition명령어가 주어질때마다 expression을 평가하지 않는다. Expressions 섹션을 참조해라.
condition bnum: breakpoint 넘버 bnum에서 조건을 제거한다. 보통 그것은 절대적인 breakpoint가 된다.

breakpoint 조건의 특별한 경우는 breakpoint가 어떤 넘버의 카운트에 도착할때만 멈추는 경우이다. 이것은 매우 유용해서 breakpoint의 ignore count를 사용하여 그것을 할수 있다. 모든 breakpoint는 정수로써 ignore count를 가지고 있다. 경우의 대두분에서, ignore count는 0이고 그래서 효과가 없다. 그러나 여러분의 프로그램이 ignore count가 양수인 breakpoint에 도착한다면, 프로그램은 멈추는 대신 ignore count를 하나 줄이고 계속한다. 결과적으로 ignore count 값이 n이라면, breakpoint는 여러분의 프로그램이 도착할 다음번 n에서는 멈추지 않는다.

ignore bnum count: ignore count의 breakpoint 넘버 bnum를 count로 설정한다. 다음 count번째 breakpoint에 도달했을때, 프로그램의 실행은 멈추지 않는다; ignore count를 줄이는것이외 GDB는 어떤 행동도 하지 않는다. breakpoint가 도착하는 다음번에 멈추도록 하기 위해, count를 0으로 해라. 여러분이 breakpoint에서 프로그램 시작을 다시 하기 위해 continue를 사용할때, 여러분은 ignore사용대신 continue에 인자로써 직접 ignore count를 지정 할수 있다. 계속과 단계(stepping)섹션을 참조해라. 만일 breakpoint가 양수의 ignore count와 조건들 가진다면, 조건은 검사되지 않는다. 일단 ignore count가 0에 도달하면, GDB는 조건 검사를 다시 시작한다. 여러분은 매번 감소하는 편리변수를 사용하여 `$foo-- <= 0' 같은 조건을 가지고 ignore count의 효과를 볼수 있다. 편리 변수들섹션을 참조해라.

Breakpoint 명령어 리스트

breakpoint 때문에 프로그램의 실행을 멈출때 breakpoint(또는 watchpoint) 명령어들을 사용할수 있다. 예를 들어, 여러분은 어떤 표현식이나 활성화된 다른 breakpoint의 값을 출력하길 원할지 모른다.

commands [bnum]
... command-list ...
end: breakpoint 넘버 bnum를 위한 명령어 리스트를 지정한다. 명령어들은 다음 라인에 나타난다. 명령어를 마치기 위해서는 단지 end를 라인에 포함시키면 된다. breakpoint에서 명령어들을 제거하기 위해, commands를 타입핑하고 바로 end를 타이핑하면 된다.; 즉, 명령어를 주지 않으면 된다. bnum인자가 없다면, commands는 마지막 breakpoint나 watchpoint설정을 참조한다.(가장 최근에 만난 breakpoint가 아니다)

마지막 GDB 명령어를 반복하는 수단으로써 RET를 누르는것은 command-list에서 disable된다.

여러분은 프로그램을 다시 시작할때 breakpoint명령어를 사용할수 있다. 단순히 continue 명령어나 step 또는 실행을 다시 시작 시키는 다른 명령어를 사용해라.

실행을 시작하는 명령어후, 명령어 리스트내 다른 명령어들은 무시된다. 이것은 여러분이 실행을 다시 시작하는 때(단순히 next나 step일때조차)에, 여러분이 다른 breakpoint를 만날지도 모르기 때문이다.--모호성을 야기할수 있는 자신의 명령어 리스트를 가질수 있다.

명령어 리스트에 지정한 첫 명령어가 silent이라면, breakpoint시 중지에 관한 일반적 메세지는 출력되지 않는다. 특별한 메세지를 출력하는 breakpoint와 continue를 위해서는 바람직하다. 남아 있는 명령어들이 어떤것도 출력하지 않는다면, 여러분은 breakpoint가 도착한 표시를 알수 없다. silent는 breakpoint 명령어 리스트의 시작시에만 의미를 갖는다.

명령어 echo, output, 그리고 printf는 여러분이 정밀하게 출력을 제어하도록 허용한다. 그리고 자주 조용한 breakpoint에서 유용하다. 출력 제어를 위한 명령어들섹션을 참조해라.

예를 들어, 여기에서 여러분은 x가 양수일때는 언제나 foo를 위한 엔트리에서 x의 값을 출력하기 위해 breakpoint 명령어를 사용할수 있다.

break foo if x>0
commands
silent
printf "x is %d\n",x
cont
end

breakpoint 명령어를 위한 응용프로그램은 버그 하나를 잡는다. 그래서 여러분이 다른것을 테스트할수 있다. 코드에서 잘못된 라인 다음에 breakpoint를 설정해라. 그리고 몇몇 에러가 나온 다음에 발견하기 위한 조건을 주고 적당한 값을 대입하기 위한 명령어를 준다. continue 명령어로 끝내면 프로그램은 멈추지 않으며 silent 명령어로 시작하면 어떤 출력도 나타나지 않는다. 여기에 예가 있다:

break 403
commands
silent
set x = y + 4
cont
end

Breakpoint 메뉴

몇몇 프로그래밍 언어(주로 C++)는 다른 문맥에서 응용프로그램을 위해, 여러번 정의된 단일 함수 이름을 허용한다. 이것은 보통 overloading이라 불린다. 함수 이름이 오버로딩됐을때, `break function'는 여러분이 breakpoint를 원하는 곳을 GDB에게 말하기에 충분하지 않다. 만일 이것이 문제인걸 안다면, 여러분은 원하는 함수의 특별한 버전을 지정하기 위해 `break function(types)' 같은 것을 사용할수 있다. 그렇지 않으면, GDB는 여러분이 가능한 breakpoint 선택을 위해 여러개의 메뉴를 제공한다. 그리고 프롬프트 `>'와 함께 선택을 기다린다. 처음 두 옵션은 항상 `[0] cancel'와 `[1] all'이다. 1을 타이핑하는것은 각 function의 정의마다 breakpoint를 설정하는 것이고 0을 타이핑하는것은 새로운 breakpoint를 설정하는것 없이 break 명령어를 떠난는 것이다.

예를 들어, 다음 세션의 발췌내용은 오버로딩된 심볼 String::after에 breakpoint를 설정하는것을 보여준다. 우리는 함수 이름의 3개의 특정 정의를 선택했다.:

(gdb) b String::after
[0] cancel
[1] all
[2] file:String.cc; line number:867
[3] file:String.cc; line number:860
[4] file:String.cc; line number:875
[5] file:String.cc; line number:853
[6] file:String.cc; line number:846
[7] file:String.cc; line number:735
> 2 4 6
Breakpoint 1 at 0xb26c: file String.cc, line 867.
Breakpoint 2 at 0xb344: file String.cc, line 875.
Breakpoint 3 at 0xafcc: file String.cc, line 846.
Multiple breakpoints were set.
Use the "delete" command to delete unwanted
 breakpoints.
(gdb)

계속과 단계

Continuing는 프로그램이 정상적으로 마칠때까지 프로그램 실행을 다시 시작한다는 의미이다. 반대로, stepping는 단지 프로그램에서 한번 더 "step"을 실행한다는 의미이다. 여기서 "step"은 소스 코드의 한 라인이거나 단일 기계 명령어(여러분이 사용하는 명령어에 의존한다.)중 하나를 의미한다. 계속이나 단계중일때, 프로그램은 breakpoint나 신호때문에 곧 멈출지도 모른다. (만일 신호때문이라면, 여러분은 handle이나 실행을 다시 시작하기 위해 `signal 0'을 사용하길 원할지 모른다. 신호들섹션을 참조해라.)

continue [ignore-count]
c [ignore-count]
fg [ignore-count]: 프로그램이 마지막으로 멈춘 주소에서 프로그램을 다시 시작한다; 그 주소에 설정된 breakpoint는 그냥 지나간다. 옵션 인자 ignore-count는 여러분이 이 위치에서 breakpoint를 무시하기 위해 더 많은 횟수를 지정할수 있도록 허용한다; 이것은 ignore와 같다.(Break 조건들 섹션을 참조해라.) 인자 ignore-count는 프로그램이 breakpoint 때문에 중지할때만 의미가 있다. 다른때, continue를 위한 인자들은 무시된다. c와 fg는 편위를 위해서만 제공되며 continue와 정확히 같은 행동을 한다.

다른 위치에서 실행을 다시 시작하기 위해, 여러분은 호출 함수로 다시 가기 위해 return(함수에서 리턴 섹션을 참조해라.)을 사용할수 있다.; 또는 프로그램의 임의의 위치로 가기 위해 jump(다른 주소에서 계속하기섹션을 참조해라.)를 사용해라.

stepping을 사용하는 전형적인 기술은 함수의 시작이나 문제가 있는 프로그램 섹션에 breakpoint(Breakpoints, watchpoints, 그리고 exceptions 섹션을 참조해라.)를 설정하는 것이다. 그리고 breakpoint에서 멈출때까지 프로그램을 돌리고 의심스러운 위치에서 step을 밝아가고 프로그램에 문제가 발생할때까지 흥미가 있는 변수를 검사하는 것이다.

step

제어가 다른 소스 라인에 도착할때까지 프로그램 실행을 계속한다. 그리고 멈추고 제어를 다시 GDB에게 돌린다. 이 명령어는 간단히 s이다.

경고: 만일 여러분이 디버깅 정보 없이 컴파일된 함수내에 제어가 있는 동안에 step 명령어를 사용한다면, 실행은 제어가 디버깅 정보를 가지고 있는 함수에 도착할때까지 계속된다. 게다가, 디버깅 정보 없이 컴파일 된 함수내로는 step되지 않는다. 디버깅 정보 없는 함수내로 step하기 위해서는 stepi를 사용해라.

step 명령어는 소스 라인의 첫 명령어에서만 멈춘다. 이것은 루트등 switch문에서 일어날수 있는 여러번 정지를 막는다. step는 디버깅 정보를 가지고 있는 함수가 라인내에서 불려진다면 중지를 위해 계속한다. 또한, step는 서브루틴을 위한 라인넘버 정보가 있다면 서브루틴으로 들어간다. 그렇지 않으면 이 명령어는 next처럼 행동한다. 이것은 MIPS 머신에서 cc -gl를 사용할때의 문제들을 피할수 있다. 전에, step는 루틴에 관한 디버깅 정보가 있다면 서브루틴으로 들어간다.

step count

step에서 처럼 계속 실행되지만, count번 만큼 한다. 만일 breakpoint가 도달하거나 step과 관련없는 신호가 count번 전에 발생한다면, steppint은 바로 멈춘다.

next [count]

현재(가장 안쪽) 스택 프레임에서 다음 소스라인으로 계속해라. 이것은 step과 비슷하지만, 함수 코스의 라인안에 나타나는 함수 호출은 중지없이 실행된다. 실행은 제어가 원래 스택 레벨에서 코드의 다른 라인에 도착 할때 멈추며 여러분이 next 명령어를 사용할때 실행한다. 이 명령어는 n으로 축약할수 있다. 인자 count는 step처럼 반복 횟수이다. next명령어는 소스라인의 첫 명령어에서 멈춘다. 이것은 루프 등 switch 문에서 발생하는 다중 정지를 막는다.

finish

선택된 스택 프레임에 있는 함수가 반환할때까지 실행을 계속한다. 리턴값을 출력한다. return 명령어와 이것은 대조적이다.(함수에서 반환 섹션을 참조해라.)

u

until

현재 스택 프레임에서 소스 라인이 현재 라인에 도착할때까지 실행을 계속한다. 이 명령어는 한번 이상 루프를 통해 단일 stepping을 피하기 위해 사용된다. 이 명령어는 until이 분기를 만날때를 제외하고 next 명령어와 같으며 자동적으로 프로그램 카운터가 분기 주소보다 클때까지 실행을 계속한다. 이것은 여러분이 단일 stepping이 이곳을 통과한후 루프의 끝에 도착할때를 의미하며, until은 루프를 종료할때까지 프로그램 실행을 계속하도록 만든다. 대조적으로, 루프의 끝에서 next명령어는 루프의 시작으로 다시 나아가 며 여러분은 다음 반복을 통해 강제적으로 나아갈수 있다. until은 항상 현재 스택 프레임을 종료한다면 프로그램을 멈춘다. until는 기계 코드의 순서가 소스 라인의 순서와 맞지 않다면 다소 반직관적인 결과를 낳는다. 예를 들어, 디버깅 세션에서의 다음 발취에서, f(frame) 명령어는 실행이 라인 206에서 멈추었다는것을 보여준다; 우리가 until을 사용할때, 195을 갖는다.

(gdb) f
#0  main (argc=4, argv=0xf7fffae8) at m4.c:206
206                 expand_input();
(gdb) until
195             for ( ; argc > 0; NEXTARG) {

이것은 실행 효율성때문에 컴파일러가 시작보다 루프의 끝에서 루프를 닫도록 코드를 만들기 때문이다.--C for-루프에서의 테스트는 루프의 본체전에 쓰여졌다. until명령어는 이 표현식으로 나아갈때 루프의 시작으로 다시 나아갈때 나타난다.; 그러나 초기 문장으로 가지는 않는다--실제 기계 코드 의 구간에서가 아니라. 인자가 없는 until는 단일 명령어 stepping의 수단으로 작동한다. 그래서 인자가 있는 until보다 느리다.

until location

u location

지정된 위치에 도착하든지 현재 스택 프레임이 반환될때까지 프로그램 실행을 계속한다. location는 break에서 받아들일수 있는 인자 형태이다.(Setting breakpoints 섹션을 참조해라.) 명령어 형태는 breakpoint를 사용한다. 그래서 인자가 없을경우 until 빠르다.

stepi

si

한개의 기계 명령어를 실행한다. 그리고 멈추고 디버거로 리턴한다. 기계 명령어에 의해 stepping할때 `display/i $pc'을 하는것은 자주 유용하다. 이것은 프로그램이 멈출때마다 GDB가 자동적으로 실행해야할 다음 명령어를 보여준다. 자동 디스플레이 섹션을 참조해라. 인자는 step처럼 반복 횟수이다.

nexti

ni

한개의 기계 명령어를 실행한다. 그러나 만일 함수 호출이라면 함수가 반환할때까지 한다. 인자는 next처럼 반복수이다.

신호들

신호는 프로그램내 발생하는 비동기적 사건이다. OS는 가능한 종류의 신호를 정의하며 각 종류의 이름과 숫자를 준다. 예를 들어, Unix에서 SIGINT는 여러분이 인터럽트를 타이핑(C-c)할때 프로그램이 갖는 신호이다.; SIGSEGV는 사용할수 있는 메모리 영역 이외의 장소를 참조할때 프로그램이 갖는 신호이다.; SIGALRM는 alarm 클럭 타이머가 꺼질때 생긴다. (만일 여러분의 프로그램이 알람을 가진경우에만)

SIGALRM을 포함한 몇몇 신호들은 프로그램 함수들중 일부분이다. SIGSEGV 처럼, 다른것들은 에러를 가리킨다.; 이들 신호는 미리 이들 신호를 처리하는 다른 방법을 지정하지 않았다면 치명적(프로그램은 즉시 죽는다)이다. SIGINT는 프로그램에서 에러를 가리키는것은 아니지만 보통 치명적이어서 프로그램을 죽이기 위한 인터럽트의 목적으로 실행한다.

GDB는 프로그램내 신호의 발생을 발견할 능력이 있다. 여러분은 신호의 종류 마다 해야할것을 미리 GDB에게 말할수 있다.

보통, GDB는 에러신호가 발생할때마다 즉시 프로그램을 멈추게 하기 위해서 SIGALRM과 같은 에러가 아닌 신호들은 무시하도록 설정한다. (프로그램의 함수내 역할을 방해하지 않는 한) 여러분은 handle명령어를 가지고 이들 설정을 바꿀수 있다.

info signals: 신호의 종류와 각 신호마다 GDB가 처리해야할 방법에 대한 테이블을 모두 보여준다. 여러분은 정의된 신호 타입의 신호 넘버를 모두 보기 위해 이 명령어를 사용할수 있다. info handle는 info signals에 대한 별명이다.
handle signal keywords...: GDB가 신호 signal를 처리하는 방법을 바꾼다. signal는 신호의 숫자나 이름(시작시 `SIG'를 가지든 가지지 않든)일수 있다. keywords는 만들기 위해 바꾸어야할것이 무엇 인지를 말한다.

handle 명령어에 의해 허용되는 키워드는 줄일수 있다. 완전한 이름은:

nostop: GDB는 신호가 발생할때 프로그램을 멈추지 않는다. 여전히 신호가 왔을때 여러분에게 말할 메세지를 출력한다.
stop: GDB는 신호가 발생할때 프로그램을 멈춘다. 이것은 역시 print 키워드 를 암시한다.
print: GDB는 신호가 발생할때 메세지를 출력한다.
noprint: GDB는 신호의 발생에 대해 언급하지 않는다. 이것은 역시 nostop 키워드 를 암시한다.
pass: GDB는 이들 신호를 볼수 있도록 프로그램을 허용한다; 프로그램은 이 신호를 처리하거나 그렇지 않으면 신호가 치명적이고 처리되지 않는다면 종료된다.
nopass: GDB는 이 신호를 보도록 프로그램에게 허용하지 않는다.

신호가 프로그램을 멈출때, 신호는 여러분이 continue할때까지 볼수 없다. 만일 pass가 그때 신호의 영향하에 있다면 프로그램은 신호를 볼수 있다. 즉, GDB가 신호를 보고한후 여러분이 continue할때 프로그램이 신호를 볼수 있는지 없는지를 제어하기 위해 pass나 nopass 명령어와 함께 handle을 사용할수 있다.

여러분은 또한 프로그램이 신호를 보는걸 막기 위해서나 볼수 없는 신호를 보도록 하거나 어떤때든지 신호을 주도록 하기 위해 signal 명령어를 사용할수 있다. 예를 들어, 프로그램이 메모리 참조 에러때문에 멈춘다면, 여러분은 더 실행 되길 원해서 정확한 값을 에러 변수에 넣고 continue할수 있다.;그러나 프로그램은 아마 신호를 보자 마자 치명적 신호의 결과처럼 즉시 죽을 것이다. 이것을 막기 위해, 여러분은 `signal 0'을 가지고 계속해야 한다. 프로그램에 신호 주기 섹션을 참조해라.

다중 쓰레드 프로그램의 중지와 시작

여러분이 다중 쓰레드를 가질때(다중 쓰레드 프로그램 디버깅하기 섹션을 참조해라.), 여러분은 모든 쓰레드나 특정 쓰레드에 breakpoint를 설정할지 안할지를 선택할수 있다.

break linespec thread threadno

break linespec thread threadno if ...

linespec는 소스 라인을 지정한다.; 그것들을 쓰는 몇가지 방법이 있지만 효과는 몇몇 소스 라인을 항상 지정하는 것이다. 여러분은 특정 쓰레드가 이 breakpoint에 도착할때 프로그램이 멈추길 원하면 breakpoint 명령어와 함께 `thread threadno'를 사용해라. threadno는 `info threads' 출력의 처음 칼럼에서 보여진 것처럼 GDB에 의해 대입된 쓰레드 식별자중 하나이다. 만일 여러분이 breakpoint를 설정할때 `thread threadno'를 지정하지 않는다면, breakpoint는 프로그램의 모든 쓰레드에 적용된다. 여러분은 역시 조건적 breakpoint에서 thread 식별자를 사용할수 있다. ; 이런 경우, 다음처럼 breakpoint 조건 전에 `thread threadno'를 놓아라.

(gdb) break frik.c:13 thread 28 if bartab > lim

프로그램이 어떤 이유때문에 GDB하에서 멈추었다면, 현재 쓰레드만이 아니라 실행중인 모든 쓰레드는 멈춘다. 이것은 여러분이 변경될것들에 대해 걱정없이 쓰레드를 바꾸는걸 포함하여 프로그램의 전체적인 상태를 검사하도록 허용한다.

거꾸로, 여러분이 프로그램을 다시 시작할때 모든 쓰레드는 실행을 시작한다. 이것은 step이나 next같은 명령어를 가지고 단일 stepping을 할때도 사실이다.

특별히, GDB는 융통성 없이 모든 쓰레드에 단일 stepping을 할수 없다. 쓰레드 스케줄링을 하는 것은 디버깅하는 타겟 OS(GDB에 의해 제어되지 않는다.)이기 때문에, 다른 쓰레드들은 현재 쓰레드가 단일 step을 완성하는 동안 한 문장 더 실행한다. 게다가, 일반적으로 다른 쓰레드는 프로그램이 멈출때 문장 경계를 청소하기 보다는 문장 중간에 멈춘다.

여러분은 continue나 단일-stepping후 다른 쓰레드에서 멈춘 프로그램을 발견할수 있다. 이것은 처음 쓰레드가 여러분의 요구를 마치기 전에 몇몇 다른 쓰레드가 breakpoint, 신호 또는 예외시에 돌아갈때 일어난다.

스택 검사하기

프로그램이 멈추었을때, 여러분이 알아야할 첫번째는 프로그램이 멈춘곳이 어디이고 거기를 갖는 방법이다.

프로그램이 함수 호출을 할때마다 호출에 관한 정보가 만들어진다. 그 정보는 여러분의 프로그램에서 호출의 위치와 호출 인자 그리고 호출된 함수의 지역 변수들을 포함한다. 정보는 스택 프레임 이라 불리는 데이터 블럭에 저장된다. 스택 프레임은 콜 스택 이라 불리는 메모리 영역에 대입된다.

프로그램이 멈추었을때, 스택을 검사하는 GDB 명령어들은 여러분이 이 정보 모두를 볼수 있도록 허용한다.

스택 프레임중 하나가 GDB에 의해 selected 되고 많은 GDB 명령어들이 선택된 프레임을 가리킨다. 특별히, 여러분이 여러분의 프로그램에 있는 변수의 값을 GDB 에 물어볼때마다 그 값은 선택된 프레임에서 발견된다. 여기에는 여러분이 흥미로워하는 프레임을 선택할수 있는 특별한 GDB 명령어들이 있다. 프레임 선택하기 섹션을 참조해라.

프로그램이 멈추었을때, GDB는 자동적으로 현재 실행되는 프레임을 선택하며 frame 명령어와 비슷하게 간단히 기술한다. (프레임에 관한 정보 섹션을 참조해라.)

스택 프레임

콜 스택은 stack frames 또는 간단히 frames 라 불리는 연속적인 조각으로 나누어진다.; 각 프레임은 하나의 함수에 하나의 호출이 관련된 데이터이다. 프레임은 함수에 주어지는 인자와 함수의 지역 변수들 그리고 함수가 실행하는 주소를 포함한다.

여러분의 프로그램이 시작할때, 스택은 단지 main 함수 하나의 프레임만 가지고 있다. 이것은 initial 프레임이나 outermost 프레임이라 불린다. 함수가 호출될때마다, 새로운 프레임은 만들어진다. 함수가 반환될때마다, 함수 호출을 위한 프레임은 제거된다. 함수가 재귀적이라면, 같은 함수를 위한 많은 프레임이 있을수 있다. 실제로 실행시 발생하는 함수를 위한 프레임은 innermost 프레임이라 불린다. 이것은 여전히 존재하는 모든 스택 프레임에서 가장 최근에 생성된 것이다.

프로그램 내에서, 스택 프레임은 주소에 의해 식별된다. 스택 프레임은 많은 바이트들로 구성되어 있으며 각각은 자신의 주소를 가지고 있다; 컴퓨터 각 종류는 프레임 주소로써 제공되는 주소 한 바이트를 선택할수 있다. 보통 이 주소는 실행이 그 프레임내에 있는 동안 frame pointer register 이라 불리는 레지스터에서 유지된다.

GDB는 innermost 프레임을 위해 0으로 시작하여, 호출되는 프레임을 위해 1로 그리고 상위로 등등으로 존재하는 스택 프레임 모두를 위해 숫자를 대입한다. 이들 수는 여러분의 프로그램에서 실제로 존재하지는 않는다; 이들 수는 GDB 명령어 내에서 스택 프레임을 고안한 방법을 여러분에게 주도록 GDB에 의해 할당된다.

몇몇 컴파일러는 스택 프레임 없이 작동하도록 함수를 컴파일하기 위한 방법을 제공한다.(예를 들어, gcc 옵션 `-fomit-frame-pointer' 는 프레임 없는 함수를 만든다.) 이것은 프레임 설정 시간을 줄이기 위해 무거운 라이브러리 함수를 사용할때 사용한다. GDB는 이들 함수 호출을 다루기 위한 제한된 기능을 가지고 있다. innermost 함수 호출이 스택 프레임을 가지고 있지 않음에도 불구하고, GDB는 그것이 분리된 프레임을 가지고 있는 것처럼 간주한다. 이것은 함수 호출 체인시 적당한 추적을 허용하기 위해 보통 0으로 된다. 그러나, GDB는 그밖의 스택에서 프레임 없는 함수를 제공하지 않는다.

frame args: frame 명령어는 한 스택 프레임에서 다른 스택 프레임으로 이동하도록 여러분을 허용하며 여러분이 선택한 스택 프레임을 출력한다. args 은 프레임 주소나 스택 프레임 수중 하나이다. 인자가 없다면, frame 현재 스택 프레임을 출력한다.
select-frame: select-frame 명령어는 프레임 출력없이 한 스택 프레임에서 다른 스택 프레임으로 이동하도록 허용한다. 이것은 조용한 frame 버전 이다.

Backtraces

backtrace는 여러분의 프로그램이 어떻게 돌아간는지에 대한 요약이다. 현재 실행되는 프레임(프레임 0)에서 시작하여 호출자(프레임 1)가 뒤따라오고 그리고 스택위에 있는 많은 프레임을 위해 프레임당 한라인을 보여준다.

backtrace
bt: 전체 스택에 대한 backtrace를 보여준다: 스택에 있는 모든 프레임을 위해 프레임당 한 라인. 여러분은 시스템 인터럽트 문자인 C-c를 타입핑하여 어느때든지 backtrace 를 멈출수 있다.
backtrace n
bt n: 비슷하지만, 단지 innermost n 프레임만을 출력한다.
backtrace -n
bt -n: 비슷하지만, 단지 outermost n 프레임만을 출력한다.

이름 where과 info stack(축약된 infos) 은 backtrace 를 위한 추가적인 별칭이다.

backtrace에서 각 라인은 프레임 수와 함수이름을 보여준다. 프로그램 카운터 값 또한 보여진다.--만일 여러분이 set print address off 를 사용하지 않았다면. backtrace는 또한 마치 함수의 인자 처럼 소스 파일 이름과 라인 넘버도 보여준다. 프로그램 카운터 값은 만일 그 라인 넘버에서 코드가 시작된다면 생략된다.

여기에 backtrace의 예제가 있다. 이것은 가장 안쪽의 3개의 프레임을 보여주는 `bt 3' 명령어이다.

#0  m4_traceon (obs=0x24eb0, argc=1, argv=0x2b8c8) 
    at builtin.c:993
#1  0x6e38 in expand_macro (sym=0x2b600) at macro.c:242
#2  0x6840 in expand_token (obs=0x0, t=177664, td=0xf7fffb08)
    at macro.c:71
(More stack frames follow...)

프레임 0 출력은 프로그램 카운터값으로 시작하지 않았으며, 여러분의 프로그램이 builtin.c 의 993 라인에서 멈추었다는 것을 가리킨다.

프레임 선택하기

여러분의 프로그램에서 스택이나 다른 데이터를 검사하는 대부분의 명령어들은 그순간에 선택된 스택 프레임에서 작동한다. 여기에 선택된 스택 프레임이 있다.; 그것들 모두는 단지 선택된 스택 프레임의 간단한 설명을 출력하고 종료된다.

frame n
f n: 프레임 넘버 n를 선택한다. 프레임 0은 현재 실행되는 가장 안쪽 프레임이라 하고, 프레임 1은 가장 안쪽 1을 호출한 프레임 등등이라 가정하자. 가장 높은 수의 프레임은 main 이다.
frame addr
f addr: 프레임 주소 addr 를 선택한다. 이것은 만일 스택 프레임 사슬이 버그로 손상되거나 모든 프레임에 적당한 수 대입이 불가능하게 되었을때 주로 유용하다. 추가적으로, 이것은 여러분의 프로그램이 다중 스택과 그것들 사이를 이용할때 유용하다. SPARC 아키텍쳐에서, frame 는 임의의 프레임을 선택하기 위해 2개의 주소가 필요하다.; 프레임 포인터와 스택 포인터. MIPS와 Alpha 아키텍쳐에서도 2개의 주소가 필요하다: 스택 포인터와 프로그램 카운터. 29k 아키텍쳐에서는 3개의 주소가 필요하다: 레지스터 스택 포인터, 프로그램 카운터, 그리고 메모리 스택 포인터.
up n: 스택위 n 프레임으로 이동하라. 양수 n에서, 이것은 바깥 프레임쪽으로, 큰 프레임 수로, 더 오래 있었던 프레임쪽으로 나아간다. n 는 1이 기본이다.
down n: 스택 아래 n 으로 이동하라. 양수 n에서, 이것은 안쪽 프레임쪽으로, 낮은 프레임 수쪽으로 , 가장 최근에 만들어진 프레임쪽으로 나아간다. 여러분은 down을 do 로 간단히 할수 있다.

이들 명령어들 모두는 프레임을 설명하는 2라인을 출력하고 마친다. 첫 라인은 프레임 수, 함수 이름, 인자, 그리고 소스 파일 그 프레임에서 실행 라인 넘버를 보여준다. 두번째 라인은 소스 라인의 텍스트를 보여준다.

예:

(gdb) up
#1  0x22f0 in main (argc=1, argv=0xf7fffbf4, env=0xf7fffbfc)
    at env.c:10
10              read_input_file (argv[i]);

출력후, 인자 없는 list 명령어는 프레임 실행시점 가운데 10 라인을 출력하다. 소스 라인 출력하기 섹션을 참조해라.

up-silently n
down-silently n: 이들 두 명령어는 up과 down의 변종이다.; 그들은 새 프레임을 출력하지 않고 조용히 작업하는것이 다르다. 이들 명령어는 출력이 필요 없고 혼란스럽게 출력되는 때에 사용하기 위한 것이다.

프레임에 관한 정보

선택된 스택 프레임에 관한 정보를 출력하기 위한 다른 명령어들이 있다.

frame

f

인자 없이 사용될때, 이 명령어는 선택된 프레임을 바꾸지 않고 현재 선택된 스택 프레임에 관한 간단한 설명을 출력한다. 간단히 f 이다. 인자가 있다면, 이 명령어는 스택 프레임을 선택하기 위해 사용된다. 프레임 선택하기 섹션을 참조해라.

info frame

info f

이 명령어는 선택된 스택 프레임의 자세한 설명을 출력한다.:

프레임의 주소
다음 프레임의 주소(이 프레임에 의해 호출된)
다음 프레임의 주소(이 프레임의 호출자)
이 프레임에 상응하는 소스 코드가 쓰여진 언어
프레임 인자의 주소
저장된 프로그램 카운터(호출 프레임에서의 실행 주소)
프레임에 저장된 레지스터들

자세한 설명은 어떤것이 스택 포맷을 잘못되게 했을때 유용하다.

info frame addr

info f addr

프레임 선택없이, 주소 addr 에 있는 프레임에 관한 자세한 설명을 출력한다. 이 선택된 프레임은 이 명령어에 의해 바꾸지 않고 남아 있는다. 이것은 여러분이 frame 명령어에서 기술한 같은 종류의 주소를 요구한다.(몇몇 아키텍쳐를 위해 1개 이상). 프레임 선택하기. 섹션을 참조해라.

info args

각 라인에 선택된 프레임의 인자를 출력한다.

info locals

각 라인에 선택된 프레임의 지역 변수를 출력한다. 이들은 선택된 프레임 실행 시점에서 접근할수 있는 모든 변수(정적 또는 자동으로 선언된)이다.

info catch

현재 실행 시점에 있는 현재 스택 프레임에서 활동하는 모든 예외 핸들러의 리스트를 출력한다. 예외 핸들러를 보기 위해, 관련 프레임을 방문해라.(up, down frame 명령어들); 그리고 info catch 를 타입핑해라. Breakpoints 와 예외 섹션을 참조해라.

MIPS 머신과 함수 스택

MIP 기반 컴퓨터는 특이한 스택 프레임을 사용한다. 이것은 가끔 함수 시작을 발견하기 위해 객체 코드에서 뒤로 찾도록 GDB 를 요구한다.

응답 시간(특히 GDB가 탐색을 위해 탐색 라인을 느리게 제한하는 내장형 응용프로그램에서)을 향상시키기 위해, 여러분은 다음 명령어들중 하나를 사용하여 탐색의 크기를 제한하길 원할지도 모른다.:

set heuristic-fence-post limit: 함수의 시작을 위해 탐색시 limit 바이트까지 검사하도록 GDB를 제한 한다. 0 값은 제한이 없음을 의미한다. 그러나, 0을 제외하고 제한값보다 더 큰 바이트 heuristic-fence-post 는 탐색되어야 한다. 그리고 돌리는데 더 오래 걸린다.
show heuristic-fence-post: 현재 시간을 출력한다.

이들 명령어들은 GDB가 MIP 프로세서에서 프로그램을 디버깅하도록 설정되었을 때만 이용할수 있다.

소스 파일 검사하기

GDB는 프로그램 소스의 일부를 출력할수 있다. 왜냐하면 프로그램에 저장된 디버깅 정보는 소스 파일이 컴파일될때 사용된것이 무엇인지를 말하기 때문이다. 프로그램이 멈출때, GDB는 멈춘 라인을 출력한다. 마찬 가지로 스택 프레임을 선택할때, GDB는 프레내에서 멈춘 실행 라인을 출력한다. (프레임 선택하기 섹션을 참조해라.) 여러분은 명백한 명령어로 소스 파일의 다른 부분을 출력할수 있다.

여러분이 GNU Emacs 인터페이스를 통해 GDB를 사용한다면, 여러분은 소스를 보기 위해 Emacs 기능을 사용하는것이 더 좋을지도 모른다.; GNU Emacs에서 GDB 사용하기 섹션을 참조해라.

소스 라인 출력하기

소스 파일에서 라인을 출력하기 위해 list 명령어를 사용해라. (간단히 l). 기본적으로, 10 라인이 출력된다. 여러분이 출력하길 원하는 파일의 일부를 지정하기 위한 여러가지 방법이 있다.

여기에 일반적으로 사용되는 list 명령어의 형태가 있다.:

list linenum: 현재 소스 파일에서 라인 넘버 linenum 를 가운데로 라인을 출력한다.
list function: 함수 function 시작근처를 가운데로 라인을 출력한다.
list: 라인들을 더 출력한다. 만일 출력된 마지막 라인이 list 명령어와 함께 출력되었다면, 출력된 마지막 라인다음에 라인들을 출력한다.; 그러나, 출력된 마지막 라인이 스택 프레임(스택 검사하기 섹션을 참조해라.)의 일부로써 출력된 라인이라면, 이것은 그 라인을 중심으로 몇라인을 출력한다.
list -: 마지막으로 출력된 라인전 몇 라인을 출력한다.

기본적으로, GDB는 list명령어와 10개의 소스 라인을 출력한다. 여러분은 set listsize을 사용하여 이것을 바꿀수 있다.

set listsize count: list명령어는 count 소스 라인을 출력한다.(만일 list 인자가 다른 수를 지정하지 않았다면)
show listsize: list가 출력하는 라인 넘버를 출력한다.

RET로 list 명령어를 반복하는 것은 해당 인자를 무시하는것이 된다. 그래서 list와 동일하다. 이것은 같은 라인을 계속 보길 원할때 유용하다. 예외는 `-' 인자의 경우이다; 그 인자는 반복시 보존되어 매 반복시 소스 파일을 이동한다.

일반적으로, list 명령어는 여러분이 0, 1 또는 2 linespecs를제공했다고 예상한다. linespec은 소스 라인을 가리킨다; 소스 라인을 쓰기위한 몇가지 방법이 있지만, 결과는 몇몇 소스 라인을 지정하는 것이다. 여기에 list를 위한 가능한 인자들 모두를 기술한다:

list linespec: linespec가 가리키는 라인근처를 중심으로 라인을 출력한다.
list first,last: first에서 last까지의 라인을 출력한다. 두 인자들은 linespecs이다.
list ,last: last로 끝나는 라인을 출력한다.
list first,: first로 시작하는 라인을 출력한다.
list +: 마지막으로 출력된 라인다음의 라인들을 출력한다.
list -: 마지막으로 출력된 라인전의 라인들을 출력한다.
list: 앞에서 기술한것과 같다.

여기에 단일 소스 라인을 지정하는 방법이 있다--모든 종류의 linespec

number: 소스 파일의 라인 number를 지정한다. number 명령어가 두 linespec을 가질때, 이것은 처음 linespec처럼 같은 소스 파일을 가리킨다.
+offset: 마지막 라인이 출력된후 line을 offset 라인으로 지정한다. list 명령어에서 두번째 linespecs처럼 사용될때, 이것은 처음 linespec에서 아래쪽으로 offset 라인을 지정한다.
-offset: 마지막 라인이 출력되기 전에 line을 offset 라인으로 지정한다.
filename:number: 소스 파일 filename내 라인 number를 지정한다.
function: 함수 function body의 시작인 라인을 가리킨다. 예를 들어: C에서, 이것은 open brace를 가지고 있는 라인이다.
filename:function: 파일 filename내 함수 function body를 시작하는 open-brace 라인을 지정한다. 여러분은 다른 소스 파일내 같은 이름의 함수가 있을때, 모호함을 피하기 위해 함수 이름과 파일이름이 필요하다.
*address: 프로그램 주소 address를 포함하는 라인을 지정한다. address는 어떤 표현식이다.

소스 파일 찾기

정규식 표현식을 위해 현재 소스 파일 탐색을 위해 두개의 명령어가 있다.

forward-search regexp
search regexp: 명령어 `forward-search regexp'는 regexp과의 매치를 위해, 나열된 마지막 라인 다음으로 시작하는 각 라인을 검사한다. 발견되는 라인을 나열한다. 여러분은 동의어 `search regexp'나 fo로 명령어 이름을 줄일수 있다.
reverse-search regexp: `reverse-search regexp'는 regexp과의 매치를 위해, 나열된 마지막 라인전에 시작하고 뒤로 가는 각 라인을 검사한다. 발견되는 라인을 나열한다. 여러분은 rev로 명령어 이름을 줄일수 있다.

소스 디렉토리 지정하기

실행 프로그램은 가끔 컴파일된 디렉토리에서 소스 파일의 디렉토리를 기록하지 않는다. 컴파일될때, 디렉토리들은 컴파일과 디버깅 세션 사이에 이동될수 있다. GDB는 소스 파일을 찾기 위한 디렉토리 리스트를 가지고 있다.; 이것은 source path이라 불린다. GDB가 소스 파일을 원할때마다, GDB는 원하는 이름을 가진 파일을 발견할때까지 리스트내 모든 디렉토리를 찾는다. 실행 탐색 경로는 이러한 목적을 위해 사용되지는 않는다. 소스 경로에서 일어나지 않는다면, 현재 작업 디렉토리도 마찬가지다.

만일 GDB가 소스 경로와 객체 프로그램을 기록한 디렉토리에서 소스 파일을 발견하지 못했다면, GDB는 그 디렉토리도 시도한다. 만일 소스 경로가 비어 있고, 컴파일 디렉토리에 대한 기록이 없다면, GDB는 마지막으로 현재 디렉토리에서 찾는다.

여러분이 소스 경로를 다시 설정하거나 재 배열할때는 언제나, GDB는 소스 파일들이 발견 되는 곳과 각 라인이 소스 파일 어디에 있는지에 관해 캐시된 모든 정보를 지운다.

여러분이 GDB를 시작할때, 소스 경로는 비어 있다. 다른 디렉토리를 추가하기 위해, directory 명령어를 사용해라.

directory dirname ...
dir dirname ...: 디렉토리 dirname를 소스 경로의 앞에 추가해라. 몇몇 디렉토리 이름들은 `:'나 whitespace로 분리해서 이 명령어에 줄수 있다. 여러분은 소스 경로에 이미 있는 디렉토리를 지정할수 있다.; 이것은 앞으로 이동된다. 그래서 GDB는 곧 찾게 된다. 여러분은 컴파일 디렉토리를 가리키기 위해 문자열 `$cdir'를 사용할수 있다. 그리고 `$cwd'는 현재 작업 디렉토리를 가리킨다. `$cwd'는 `.'와 같다. -- 전자는 GDB 세션동안 바뀐다면 현재 작업 디렉토리를 쫒아간다. 반면에 후자는 여러분이 소스 경로에 엔트리를 추가할때마다 현재 디렉토리를 확장한다.
directory: 소스 경로를 비게 한다. 이것은 확인을 요구한다.
show directories: 소스 경로를 출력한다: 어떤 디렉토리들이 그것을 포함하는지를 보여준다.

여러분의 소스 경로가 더이상 흥미가 없는 디렉토리를 포함하고 있다면, GDB는 가끔 잘못된 버전의 소스를 발견하여 혼란을 야기할수도 있다. 여러분은 다음처럼 상황을 바로 잡을수 있다:

소스 경로를 깨끗하게 하기 위해 인자 없이 directory를 사용해라.
여러분이 원하는 소스 경로에 디렉토리를 다시 인스톨하기 위해 적당한 인자를 주어 directory를 사용해라.

소스와 기계어 코드

여러분은 소스 라인들을 프로그램 주소(그리고 반대로) 대응하기 위해 명령어 info line를 사용할수 있다. 그리고 기계어 명령어로써 주소 범위를 보여주기 위해 명령어 disassemble를 사용할수 있다. GNU Emacs 모드에서 돌아갈때, info line 명령어는 지정된 라인을 가리키기 위해 화살을 사용한다. 또한, info line 명령어는 헥사로 심볼링 형태의 주소를 출력한다.

info line linespec: 소스 라인 linespec를 위해 컴파일된 코드의 시작과 끝 주소를 출력한다. 여러분은 list 명령어(소스 라인 출력하기 섹션을 참조해라.)에 의해 이해될수 있는 방법으로 소스 라인들을 지정할수 있다.

예를 들어, 우리는 함수 m4_changequote의 처음 라인을 위한 객체 코드의 위치를 발견하기 위해 info line를 사용할수 있다.:

(gdb) info line m4_changecom
Line 895 of "builtin.c" starts at pc 0x634c and ends at 0x6350.

우리는 소스 라인이 특정 주소를 커버하는 것이 무엇인지를 조사(linespec을 위한 형태로써 *addr을 사용하여)할수 있다:

(gdb) info line *0x63ff
Line 926 of "builtin.c" starts at pc 0x63e4 and ends at 0x6404.

info line후에, x 명령어를 위한 기본 주소는 라인의 시작 주소를 바꾸는 것이다. 그래서 `x/i'는 기계어 코드(메모리 검사하기 섹션을 참조해라.)를 검사하기에 충분 하다. 또한, 이 주소는 편리 변수 $_(편리 변수 섹션을 참조해라.)의 값으로써 저장된다.

disassemble: 지정된 명령어는 기계어 명령어로써 메모리 영역을 덤프한다. 기본 메모리 영역은 선택된 프레임의 프로그램 카운터를 둘러싸고 있는 함수이다. 이 명령어에 대한 단일 인자는 프로그램 카운터 변수이다; GDB는 이 변수 주위의 함수를 덤프한다. 두개의 인자를 덤프하기 위해 주소 범위(처음은 포함하고, 두번째는 제외하고)를 지정한다.

우리는 마지막 info line예제(그 예는 SPARC 기계어 명령어를 보여준다.)에서 보여준 객체 코드 범위를 검사하기 위해 disassemble를 사용할수 있다.:

(gdb) disas 0x63e4 0x6404
Dump of assembler code from 0x63e4 to 0x6404:
0x63e4 <builtin_init+5340>:     ble 0x63f8 <builtin_init+5360>
0x63e8 <builtin_init+5344>:     sethi %hi(0x4c00), %o0
0x63ec <builtin_init+5348>:     ld [%i1+4], %o0
0x63f0 <builtin_init+5352>:     b 0x63fc <builtin_init+5364>
0x63f4 <builtin_init+5356>:     ld [%o0+4], %o0
0x63f8 <builtin_init+5360>:     or %o0, 0x1a4, %o0
0x63fc <builtin_init+5364>:     call 0x9288 <path_search>
0x6400 <builtin_init+5368>:     nop
End of assembler dump.

set assembly-language instruction-set: 이 명령어는 disassemble나 x/i 명령어를 통해 프로그램을 역어셈블할때 사용하기 위한 명령어를 선택한다. 이 명령어는 한개 이상의 네이티브 명령어 집합을 가지고 있는 아키텍쳐에서 유용하다. 현재 Intel x86 패밀리를 위해서만 정의되어 있다. 여러분은 i386나 i8086로 instruction-set를 설정할수 있다. 기본은 i386이다.

데이터 검사하기

프로그램에서 데이터를 검사하기 위한 일반적인 방법은 print 명령어나 (간단히 p) 동의어인 inspect 이다. 그것은 프로그램에 쓰여진 언어의 표현값을 평가하고 출력한다. (다른 언어에서 GDB 사용하기 섹션을 참조 해라).

print exp
print /f exp: exp 는 표현식이다(소스 언어에서). 기본적으로 exp 값은 데이터 타입에 맞는 포맷으로 출력한다.; 여러분은 `/f' 를 지정하여 다른 언어를 선택할수 있다. f 는 포맷을 지정하는 문자이다.;출력 형식 섹션을 참조해라.
print
print /f: 여러분이 exp 를 생략한다면, GDB 는 마지막 값을 다시 출력한다. (value history 값에서; Value history 섹션을 참조해라). 이것은 여러분이 선택한 포맷에서 편리하게 값을 조사하게 허용한다.

데이터를 검사하기 위한 더 low-level 방법은 x 명령어를 이용 하는 것이다. 그것은 지정된 메모리 주소에 있는 데이터를 시험하고 지정된 포맷으로 출력한다. 메모리 검사하기 섹션을 참조해라.

여러분이 타입에 관한 정보에 흥미가 있거나 구조체나 클래스 필드가 선언되는 방법에 흥미가 있다면 print 보다는 ptype exp 명령어를 사용해라. 심볼 테이블 검사하기섹션을 참조해라.

표현식

print 와 많은 다른 GDB 명령어들은 표현식을 받아들이며 그 값을 계산한다. 여러분이 사용하는 프로그램밍 언어에 의해 정의된 상수, 변수 또는 연산자는 GDB의 표현식에서 유효하다. 이것은 추가적인 표현식, 함수 호출, 캐스팅 그리고 문자열 상수를 포함한다. 전처리기 #define 명령어들에 의해 정의된 심볼들은 포함되지 않는다.

GDB는 현재 사용자의 입력 표현식에서 배열 상수를 지원한다. 문법은 {element, element...} 이다. 예를 들어, 여러분은 타겟 프로그램에서 malloc된 메모리내 배열을 위해 print {1, 2, 3}명령어를 사용할수 있다.

C가 매우 넓게 퍼졌기 때문에 이 매뉴얼에 예제에서 보여준 대부분의 표현식은 C 에 해당된다. 다른 언어에서 표현식을 사용하는 밥법을 위해서 다른 언어에서 GDB 사용하기 섹션을 참조해라.

이 섹션에서, 우리는 여러분의 프로그래밍 언어에 관계 없이 GDB 표현식에서 사용할수 있는 연산자들을 애기할 것이다.

형변환은 C뿐만 아니라 모든 언에서 지원된다. 왜냐하면 메모리 주소에 있는 구조체를 시험하기 위해서 숫자를 포인터로 형변환하는것은 매우 유용하기 때문이다.

GDB는 프로그램밍 언어에서 일반적인것들 외에 다음 연산자들을 지원한다.:

@: `@' 는 배열로써 메모리의 일부를 다루기 위한 이진 연산자이다. 더 많은 정보를 위해서 인공 배열 섹션을 참조해라.
::: `::' 는 이것이 정의된 파일이나 함수내 변수를 지정하도록 허용한다. 프로그램 변수들 섹션을 참조해라.
{type} addr: 메모리에 있는 주소 addr 에 저장되어 있는 객체 타입 type 를 가리킨다. addr 는 값이 정수나 포인터인 어떤 표현이다. (그러나 중괄호는 형변환처럼 이진 연산자에 필요하다.). 이 생성자는 어떤 종류의 데이터가 addr 주위에 있는지에 상관없이 허용된다.

프로그램 변수들

사용시 가장 일반적인 표현은 대부분의 프로그램에서 변수이름이다.

표현식에서 변수들은 선택된 스택 프레임에서 이해된다. (프레임 선택하기 섹션을 참조해라.); 그들은 둘중 하나이어야 한다.:

global (or static)

또는

프레임내 실행 시점에서 프로그램의 영역 규칙에 따라 보여진다.

이것은 함수내에서 의미가 있다.

foo (a)
     int a;
{
  bar (a);
  {
    int b = test ();
    bar (b);
  }
}

여러분은 프로그램이 이미 함수 foo 내에서 실행될때는 언제나 변수 a 를 시험하고 사용할수 있다. 그러나 여러분은 프로그램이 b 가 선언된 블럭내에서 실행되는 동안 b 만을 사용하고 검사할수 있다.

여기에는 예외가 있다: 여러분은 비록 현재 실행시점이 이 파일이 아니라 할지라도 영역이 단일 소스 파일내의 변수나 함수를 참조할수 있다. 그러나 같은 이름을(다른 소스 파일들에 있는) 가지고 있는 변수나 함수가 1개 이상 존재할수도 있다. 그런 경우가 발생한다면, 그 이름을 참조하는 것은 예상할수 없다. 여러분이 원하면, 콜론-콜론 표기를 사용해 특정 함수나 파일내 정적 변수를 기술할수 있다.

file::variable
function::variable

여기서 file 이나 function 은 정적 variable 를 위한 문맥 이름이다. 파일 이름의 경우에, 여러분은 GDB가 단일 워드로서 파일 이름을 파싱하는걸 확실히 하기 위해 인용을 사용할수 있다. -- 예를 들어, `f2.c'에 정의된 x 의 전역 값을 출력하기 위해:

(gdb) p 'f2.c'::x

`::' 의 사용은 C++에서 같은 표기의 비슷한 사용으로 충돌될수 있다. GDB는 GDB 표현식에서 C++의 범위 해석 연산자의 사용을 지원한다.

경고: 가끔, 지역 변수는 함수내 어떤 지점에서 잘못된 값을 가진것으로 나타 날수 있다. -- 단지 새로운 영역으로 들어간후 종료 되기전에

여러분은 기계 명령어들을 단계적으로 진행할때 이 문제를 볼지도 모른다. 대부분의 머신에서, 이것은 스택 프레임 설정을 위해 1개 이상의 명령어를 가지기 때문이다. (지역 변수 정의를 포함하여); 여러분이 머신 명령어들을 단계별로 진행할때 변수 들은 스택 프레임이 완전히 만들어질때까지 잘못된 값들을 가진 것으로 나타날수 있다. 종료시, 그것은 보통 스택 프레임을 파괴하기 위해 1개 이상의 머신 명령어들을 가진다; 여러분이 명령어 그룹을 통해 단계별로 진행한후 지역 변수 정의들은 사라진다.

인공 배열

이것은 메모리내 같은 타입의 연속적인 객체들을 출력하는데 유용하다.; 배열의 섹션 또는 프로그램내에 존재하는 포인터를 위해 동적으로 결정된 배열의 크기

여러분은 이진 연산자 `@'를 사용하여 artificial array로써 메모리의 연속적 구간을 참조함으로써 이것을 할수 있다. operand of `@' 의 왼쪽 피연산자는 배열과 각 객체의 첫번째 원소이어야 하며 오른쪽 연산자는 배열의 원하는 길이이다. 결과는 왼쪽 인자 타입 모두의 배열 값이다. 첫번째 원소는 실제로 왼쪽 인자이다; 두번째 원소는 첫번째 원소가 가지고 있는것들 다음의 메모리 바이트들이다. 여기에 예제가 있다. 프로그램이 다음과 같다면,

int *array = (int *) malloc (len * sizeof (int));

여러분은 array 의 내용을 출력할수 있다.

p *array@len

`@' 의 왼쪽 피연산자는 메모리에 남아 있다. 이 방법으로 `@' 하고 같이 만든 배열 값들은 밑에 쓴 다른 배열들 처럼 행동한다. 그리고 표현식에서 사용될때 표인터를 마음대로 할수 있다. 대부분의 인공 배열은 하나를 출력한후 값 히스토리 (Value history 섹션을 참조해라) 를 통해서 표현식에서 자주 나타난다.

인공 배열을 만들기 위한 다른 방법은 형변환를 사용하는 것이다. 이것은 배열처럼 값을 다시 해석한다. 그 값은 메모리에 있을 필요가 없다.:

(gdb) p/x (short[2])0x12345678
$1 = {0x1234, 0x5678}

편하게, 여러분이 배열의 길이를 뺀다면 (`(type)[])value') GDB는 그 값을 채우기 위해 크기를 계산한다. (`sizeof(value)/sizeof(type)':

(gdb) p/x (short[])0x12345678
$2 = {0x1234, 0x5678}

가끔 인공 배열 메카니즘은 쾌 충분하지 않다; 복잡한 데이터 구조체에서 흥미로운 원소들은 근접해 있지 않을수 있다. -- 예를 들어, 여러분이 배열내 포인터들의 값에 흥미가 있다면. 이러한 상황에서 유용한 작업은 처음 흥미로운 값을 출력하는 표현식에서 카운터로써 편리 변수 (편리 변수(Convenience variables) 섹션을 참조해라.) 를 사용하는 것이다. 그리고 RET 를 통해서 표현식을 반복하는 것이다. 예를 들어, 구조체에 대한 포인터 배열 dtab를 가지고 있고 fv 필드의 값에 흥미가 있다고 가정하자. 여기에 있는 것은 여러분이 타이핑해야 할 예제이다:

set $i = 0
p dtab[$i++]->fv
RET
RET
...

출력 형식

기본적으로, GDB는 데이터 타입에 따라서 값을 출력한다. 가끔 이것은 여러분이 원하는 결과가 아닐수 있다. 예를 들어, 여러분은 16진수로 숫자나 10진수로 포인터를 출력하기 원할수 있다. 또는 여러분은 문자열이나 명령어로써 어떤 주소의 메모리에 있는 데이터를 보기를 원할지 모른다. 이것을 하기 위해 여러분은 값을 출력할때 출력 형식 을 지정해야 한다.

출력 형식의 가장 간단한 사용은 이미 계산된 값을 출력하는 방법이다. 이것은 print 명령어와 슬래쉬(/) 그리고 형식문자들로 행해진다. 지원되는 출력문자는 다음과 같다:

x

정수로써 값을 간주한다. 그리고 16진수로 정수를 출력한다.

d

부호화된 10진수 정수로 출력한다.

u

부호화되지 않은 10진수 정수로 출력한다.

o

8진수 정수를 출력한다.

t

이진수로 정수를 출력한다. 문자 `t' 는 "two" 를 나타낸다. (1)

a

16진수로 주소와 그리고 가장 가까운 전 심볼에서 오프셋을 출력한다. 여러분은 알지 못하는 주소(함수에서)가 위치해 있는 곳을 발견하기 위해 사용된 이 형식을 사용할수 있다.

(gdb) p/a 0x54320
$3 = 0x54320 <_initialize_vx+396>

c

정수로 간주하고 문자 상수로써 출력한다.

f

부동 소수점 수로 값을 간주하고 전형적인 부동 소수점 문접을 사용하여 출력한다.

예를 들어, 16진수로 프로그램 카운터(PC)를 출력하기 위해 다음을 타입해라. (Registers 섹션을 참조해라)

p/x $pc

슬랙쉬(/)전에 어떤 공간도 있어서는 안된다.: 이것은 GDB의 명령어 이름들이 슬래쉬(/)를 포함하지 않기 때문이다.

다른 형식으로 값 히스토리에 있는 마지막 값을 다시 출력하기 위해, 여러분은 단지 형식을 가지고 그리고 표현식은 가지지 않고 print 명령어를 사용할수 있다. 예를 들어, `p/x' 는 16진수로 마지막 값을 출력한다.

메모리 검사하기

여러분은 프로그램의 데이터 타입에 의존하지 않고 여러 형식으로 메모리를 검사하기 위해 x 명령어를 사용할수 있다.

x/nfu addr
x addr
x: 메모리를 검사하기 위해 x 명령어를 사용해라.

n, f, 그리고 u 는 얼마나 많은 메모리를 나타내야 하는지와 그것을 형식화 하는 방법을 지정하는 옵션 인자들이다. ; addr 는 여러분이 나타낼 메모리의 시작 주소를 주는 표현식이다. 여러분은 기본값으로 nfu를 사용한다면, 여러분은 `/' 를 타입할 필요가 없다. addr 를 위한 편리한 기본 값을 위한 여러개의 명령어집합이 있다.

n, 반복 수

반복 수는 10진 정수이다; 기본값은 1이다. 이것은 나타낼 메모리 (u 으로 세어짐)가 얼마나 많은지를 지정한다.

f, 출력 형식

출력 형식은 print `s' (널로 끝난 문자열), 또는 `i' (기계 명령어)가 사용한 형식중 하나이며, 기본은 `x' (16진수) 이다. 기본 값은 여러분이 x 나 print를 사용할때마다 바뀐다.

u, 단위 크기

단위 크기는 다음과 같다.

b: 바이트.
h: halfword(2바이트)
w: 워드(4바이트). 이것이 기본값이다.
g: Giant-word(8바이트)

여러분이 x로 단위 크기를 지정할때마다, 그 크기가 여러분이 x 를 사용하는 다음번 기본 단위가 된다. (`s' 그리고 `i' 형식을 위해, 단위 크기는 무시되며 정상적으로 쓰여지지 않는다.)

addr, 시작 출력 주소

addr 는 여러분이 메모리 출력을 시작하도록 GDB에게 원한 주소이다. 표현식은 포인터 값을 가질 필요가 없다; 그것은 항상 메모리 바이트의 정수 주소값으로 해석된다. 표현식에 관한 더 많은 정보를 원한다면 표현식 섹션을 참조해라. addr 을 위한 기본 값은 검사된 마지막 주소값 다음이다. - 그러나 몇몇 다른 명령어들도 또한 기본 주소를 설정한다: info breakpoints (마지막 breakpoint 리스트의 주소를 위해), info line (라인의 시작 주소를 위해), 그리고 print (만일 여러분이 메모리에서 그 값을 사용한다면).

예를 들어, `x/3uh 0x54320' 는 부호화되지 않은 10진 정수 (`u') 와 시작 주소 0x54320 로 형식화된 메모리의 3 halfwords (h) 를 출력하기를 요구하는 것이다. `x/4xw $sp' 는 16진수로 (여기서, `$sp' ;Registers 섹션을 참조해라.) 스택 포인터의 4 워드 메모리를 (`w') 출력한다.

단위 크기를 가리키는 문자들과 출력 형식을 가리키는 문자들과는 모두 구별되기 때문에, 여러분은 처음에 오는 것이 단위 크기나 형식인지를 기억할 필요가 없다. 출력 표기 `4xw' 그리고 `4wx' 는 정확히 같은 것이다. (그러나, 카운트 n 는 처음에 와야 한다; `wx4' 는 작동하지 않는다.)

비록 단위 크기 u 가 형식 `s' 그리고 `i' 에서 무시된다 할지라도, 여러분은 여전히 카운트 n 를 사용하길 원할지 모른다.; 예를 들어, `3i' 는 여러분이 어떤 연산자를 포함하여 3개의 기계어를 보길 원한다는것을 가리킨다. 명령어 disassemble 은 기계어를 검사하는 선택적 방법을 제공한다. 소스와 기계 코드 섹션을 참조해라.

x 를 위한 인자들의 기본값은 여러분이 x 를 사용할 때마다 최소한의 검사로 메모리 스캐닝을 쉽게 할수 있도록 디자인 되었다.. 예를 들어, 여러분이 `x/3i addr' 로 세개의 기계 명령어를 검사한다면, 여러분은 단지 `x/7' 로 다음 7개를 검사할수 있다. 만일 여러분이 x 명령어를 사용하기 위해 RET 를 사용한다면, 반복 수 n 는 다시 사용된다; x 의 연속적인 사용을 위해 다른 인자들은 기본값을 갖는다.

x 명령어로 출력되는 주소와 내용은 너무 자주 사용되고 일반적 방법으로 가질수 있기 때문에 값 히스토리에 저장되지 않는다. 대신에, GDB는 편리 변수 $_ and $__ 의 값으로서 표현식에서 이어지는 사용을 위해 이 값들을 사용할수 있다. x 명령어 후, 검사된 마지막 주소는 편리변수 $_ 으로 표현식에서 사용할수 있다. 주소의 내용은 편리 변수 $__ 으로 이용될수 있다.

만일 x 명령어가 반복 수를 가지고 있다면, 저장된 주소와 내용들은 마지막 메모리 단위에서 출력된다; 이것은 만일 몇몇 단위들이 출력의 마지막 라인에 출력된다면 출력될 마지막 주소와 같지 않다.

자동 디스플레이

만일 여러분이 표현식 값을 자주 출력하길 원한다면(바뀌는 방법을 알기 위해), GDB가 프로그램을 멈출때마다 해당 값을 출력하도록 하기 위해 표현식을 automatic display list 에 추가하길 원할지도 모른다. 리스트에 추가된 각 표현식은 구별하기 위해 숫자가 주어진다; 리스트에서 표현식을 제거하할려면 여러분은 숫자를 지정하면 된다. 자동 디스플레이는 아래처럼 보인다:

2: foo = 38
3: bar[5] = (struct hack *) 0x3804

이 디스플레이는 항목 수, 표현식 그리고 현재 값을 보여준다. 여러분이 x 나 print 을 사용하여 여러 요구를 디스플레이 하듯이, 여러분은 여러분이 원하는 출력 형식을 지정 할수 있다. ; 사실, display 는 여러분의 형식 지정에 따라서 print 나 x 를 사용할지를 결정한다. -- 여러분이 단위 크기를 지정하거나 x 가 지원하는 두 형식 (`i' and `s') 중 하나라면 GDB는 x 를 사용한다.; 그렇지 않으면 GDB는 print 를 사용한다.

display exp: 여러분의 프로그램이 멈출때마다 출력하기 위해 표현식 리스트에 표현식 exp 를 추가한다.표현식 섹션을 참조해라. 만일 여러분이 display를 사용한후 다시 RET을 누른다면 display 는 반복되지 않는다.
display/fmt exp: fmt로 출력 포맷만을 지정하고 크기와 카운트는 지정하지 않기 위해, 표현식 exp를 자동 디스플레이 리스트에 추가한다. 그러나 지정된 포맷 fmt으로 매번 출력하기 위해 재배열 한다. 출력 형식 섹션을 참조해라.
display/fmt addr: fmt `i'나 `s', 또는 단일 크기나 유닛의 수를 포함하기 위해, 프로그램이 멈출때마다 검사하기 위한 메모리 주소로써 표현식 addr를 추가해라. 검사는 `x/fmt addr'을 의미한다. 메모리 검사하기 섹션을 참조해라.

예를 들어, `display/i $pc'는 실행이 멈출때마다 실행되는 기계 명령어를 보기 위해 유용하다. (`$pc' 는 프로그램 카운터의 일반적 이름이다; Registers 섹션을 참조해라.).

undisplay dnums...
delete display dnums...: 디스플레이를 위해 표현식 리스트에서 항목 수 dnums 를 제거한다. 만일 여러분이 사용후 RET 를 누르지 않는다면 undisplay 는 반복되지 않는다. (그렇지 않으면 여러분은 `No display number ...' 에러를 갖는다.)
disable display dnums...: 항목 수 dnums 의 디스플레이를 불가능하게 설정한다. 디스플레이가 불가능하게 된 항목은 자동적으로 출력되지 않지만 잊혀지지는 않는다. 나중에 다시 가능하게 된다.
enable display dnums...: 항목 수 dnums 의 디스플레이를 가능하게 한다. 여러분이 지정할때가지 표현식의 디스플레이를 자동으로 다시 하는것은 효과적이다.
display: 리스트에 있는 표현식의 현재 값을 출력하며, 그것은 프로그램이 멈출때마다 행해진다.
info display: 항목 수와 해당 값은 보여주지 않고 자동적으로 출력하기 위해 전에 설정한 표현식 리스트를 출력한다. 이것은 disable된 표현식을 포함한다. 이것은 또한 지금 바로 디스플레이되지 않는 표현식을 출력한다. 왜냐하면 그들은 현재 이용할수 없는 자동 변수를 가리키기 때문이다.

디스플레이 표현식이 지역 변수를 가리킨다면, 변수가 설정된 문맥외에서는 표현식은 이해가 되지 않는다. 그런 표현식은 실행이 변수들중 하나가 정의되어 있지 않은 문맥안에 들어갈때 disable된다. 예를 들어, 여러분이 인자 last_char 를 가지는 함수내에 있는 동안, 명령어 display last_char 를 준다면, GDB는 프로그램이 그 함수내에서 멈추기 위해 계속하는 동안 이 인자를 디스플레이한다. 그것이 그밖의 곳에서 멈춘다면 --- (여기에는 변수 last_char 가 없다) --- 디스플레이는 자동으로 disable 된다. 프로그램이 last_char 가 의미있는 곳에서 멈추는 다음번에 여러분은 다시 디스플레이 표현식을 가능하게 할수 있다.

Print 설정하기

GDB는 배열, 구조체 그리고 심볼들을 출력하는 방법을 제어하기 위해 다음 방법을 제공한다.

이들 설정은 어떤 언어에서든지 프로그램 디버깅을 위해 유용하다:

set print address

set print address on

GDB는 스택 발자취, 구조체 값, 포인터 값, breakpoints 등등의 주소를 나태낼때 조차 이들의 위치를 보여주는 메모리 주소를 출력한다. 기본값은 on 이다. 예를 들어, 이것은 스택 프레임이 set print address on처럼 보이도록 한 것이다:

(gdb) f
#0  set_quotes (lq=0x34c78 "<<", rq=0x34c88 ">>")
    at input.c:530
530         if (lquote != def_lquote)

set print address off

내용들을 출력할때 주소를 출력하지 마라. 예를 들어, 이것은 set print address off 로 출력된 같은 스택 프레임이다.:

(gdb) set print addr off
(gdb) f
#0  set_quotes (lq="<<", rq=">>") at input.c:530
530         if (lquote != def_lquote)

여러분은 GDB 인터페이스에서의 모든 기계 의존적인 디스플레이를 줄이기 위해 `set print address off' 를 사용할수 있다. 예를 들어, print address off으로 여러분은 모든 머신의 backtrace를 위해 같은 텍스트를 가질수있다. -- 그들이 포인터 인자와 관계가 있든지 없든지

show print address

주소를 출력할지 안할지를 보여준다.

GDB가 상징 주소를 출력할때, 그것은 보통 가장 가까운 심볼 더하기 오프셋을 출력한다. 만일 그 심볼이 주소를 구별하지 못한다면(예를 들어, 이것은 영역이 단일 소스인 이름이다), 여러분은 명확히 할 필요가 있다. 이것을 하기 위한 한가지 방법은 info line이며, 예로는 `info line *0x4537'이다. 선택적으로, 여러분은 심볼릭 주소를 출력할때 소스 파일과 라인 수를 출력하기 위해 GDB를 설정할수 있다.

set print symbol-filename on: 소스 파일 이름과 주소의 상징 형태에 있는 상징의 라인 수를 출력하도록 GDB에게 말해라.
set print symbol-filename off: 소스 파일 이름과 상지의 라인 수를 출력하지 마라. 이것은 기본값이다.
show print symbol-filename: GDB가 소스 파일 이름과 주소의 상징 형태에 있는 상징의 라인 수를 출력할지 안할지를 보여준다.

상징 파일 이름과 라인 수를 보여주는데 유용한 다른 상황은 코드를 역 어셈블할 때이다.; GDB는 여러분에게 각 명령어에 상응하는 라인 수와 소스 파일을 보여준다.

또한, 만일 출력되는 주소가 가장 가까운 초기 심볼과 상당히 가깝다면 여러분은 상징적 형태를 보길 원할지도 모른다.

set print max-symbolic-offset max-offset: 만일 가장 가까운 초기 심볼과 주소 사이의 오프셋이 max-offset 보다 적다면 주소의 상징적 형태를 출력하도록 GDB에게 말한다. 기본 값은 0이며 이것은 어떤 심볼이 그것에 우선한다면 주소의 상징적 형태를 출력하도록 GDB에게 말한다.
show print max-symbolic-offset: GDB가 상징적 주소에서 출력되는 최대 오프셋이 얼마나 큰지 물어본다.

여러분이 포인터를 가지고 있고 그것이 가리키는 곳이 확실하지 않다면, `set print symbol-filename on' 를 시도해라. 그러면 여러분은 `p/a pointer' 를 사용하여 그것이 가리키는 곳의 이름과 변수의 소스 파일 위치를 결정할수 있다. 이것은 상징적 형태에 있는 주소를 해석한다. 예를 들어, GDB는 `hi2.c' 에 정의된 변수 ptt 가 다른 변수 t 를 가리키고 있는 것을 보여준다.:

(gdb) set print symbol-filename on
(gdb) p/a ptt
$4 = 0xe008 <t in hi2.c>

경고: 지역 변수를 가리키는 포인터때문에, `p/a' 는 비록 적당한 set print 옵션이 켜져 있다하더라도 참조되는 심볼 이름과 파일이름을 보여주지 않는다.

다른 설정들은 다른 종류의 객체들이 출력되는 방법을 제어한다.

set print array

set print array on

보기좋은 배열로 출력한다. 이형태는 읽기가 매우 편하지만 더 많은 공간을 사용한다. 기본값은 꺼져있다.

set print array off

압축된 형식의 배열로 바꾼다. Return to compressed format for arrays.

show print array

배열을 나타내기 위해 선택된 것이 압축된 포맷인지 보기좋게 나열된 포맷인지 보여 준다.

set print elements number-of-elements

GDB 가 배열 원소를 얼마나 많이 출력할지 그 제한 값을 설정한다. 만일 GDB가 많은 배열을 출력한다면, GDB는 set print elements 명령어 로 설정된 원소의 수를 출력한후 출력을 멈춘다. 이 제한값은 또한 문자열 출력에도 적용된다. number-of-elements 를 0으로 설정하는 것은 출력이 무제한이라는 의미이다.

show print elements

GDB 가 출력할 배열 원소의 수를 보여준다. 숫자가 0이라면, 출력은 무제한이다.

set print null-stop

첫음 NULL을 만났을때 배열의 문자들 출력을 멈추도록 GDB를 설정한다. 이것은 커다란 배열이 짧은 문자열만을 포함할때 유용하다.

set print pretty on

아래와 같이 라인당 하나의 멤버를 가진 오목한 형태의 구조체를 출력하도록 GDB를 설정한다.:

$1 = {
  next = 0x0,
  flags = {
    sweet = 1,
    sour = 1
  },
  meat = 0x54 "Pork"
}

set print pretty off

다래와 같이 간결한 형태로 구조체를 출력하도록 GDB를 설정한다:

$1 = {next = 0x0, flags = {sweet = 1, sour = 1}, \
meat = 0x54 "Pork"}

이것이 기본 형식이다.

show print pretty

구조체 출력을 위해 GDB가 사용하는 형식이 무엇인지 보여준다.

set print sevenbit-strings on

단지 7-비트 문자들 사용을 출력한다; 이 옵션이 켜져 있다면, GDB 는 표기 \nnn를 사용하는 9-비트 문자(문자열이나 문자 값)들을 보여준다. 만일 여러분이 영어로(ASCII) 작업한다면 그리고 여러분이 제조자로써나 "meta" 비트로써 문자들의 최상위 비트를 사용한다면 이 설정은 최상이다.

set print sevenbit-strings off

8 비트 문자를 출력한다. 이것은 더 많은 국제 문자 집합들의 사용을 허용하며 기본 값이다.

show print sevenbit-strings

7-비트 문자열만을 GDB 가 출력할지 안할지를 보여준다.

set print union on

구조체 안에 포함된 유니온을 출력하도록 GDB를 설정한다. 이것은 기본 설정이다.

set print union off

구조체 안에 포함된 유니온을 출력하지 않도록 GDB를 설정한다.

show print union

구조체 안에 포함된 유니온을 출력할지 안할지를 GDB에게 물어본다. 예를 들어, 주어진 선언은

typedef enum {Tree, Bug} Species;
typedef enum {Big_tree, Acorn, Seedling} Tree_forms;
typedef enum {Caterpillar, Cocoon, Butterfly} 
              Bug_forms;

struct thing {
  Species it;
  union {
    Tree_forms tree;
    Bug_forms bug;
  } form;
};

struct thing foo = {Tree, {Acorn}};

이다. set print union on 설정시 `p foo' 은 다음을 출력한다.

$1 = {it = Tree, form = {tree = Acorn, bug = Cocoon}}

그리고 set print union off 설정시 다음을 출력한다.

$1 = {it = Tree, form = {...}}

이들 설정은 C++ 프로그램을 디버깅할때 흥미롭다.

set print demangle

set print demangle on

어셈블러와 type-safe linage를 위한 링커에 전달되는 인코드("mangled") 형태보다 소스 형태의 C++ 이름을 출력한다. 기본 값은 `on' 이다.

show print demangle

C++ 이름을 mangle이나 demangle 형태로 출력할지 안할지를 보여준다.

set print asm-demangle

set print asm-demangle on

어셈블러 코드가 명령어 역어셈블로 출력될때조차, mangle 형식보다는 소스 형태에 있는 C++ 이름을 출력한다. 기본값은 off이다.

show print asm-demangle

어셈블리 리스트내 C++이름을 mangle로 할지 demangle 형태로 출력할지를 보여준다.

set demangle-style style

C++ 이름을 나태내기 위해 여러 종류의 컴파일러에 의해 사용되는 인코딩 구조를 선택한다. style은 다음과 같다:

auto: 프로그램을 조사하기 위해 GDB가 인코딩 스타일을 선택하도록 허용한다.
gnu: GNU C++ 컴파일러(g++) 인코딩 알고리즘기반으로 디코딩한다. 이것이 기본이다.
lucid: Lucid C++ 컴파일러(lcc) 인코딩 알고리즘기반으로 디코딩한다.
arm: C++ Annotated Reference Manual에서 사용되는 알고리즘으로 디코딩한다. 경고:이 설정은 cfront로 생성된 실행파일을 디버깅하기에 충분하지 않다. GDB는 그것을 허용하기 위해 더 높은 향상을 요구한다.
foo: 형식 리스트를 보여준다.

show demangle-style

디코딩 C++ 심볼들을 위해 현재 디코딩된 스타일을 출력한다.

set print object

set print object on

객체에 대한 포인터를 출력할때, 가상 함수 테이블을 사용하는 declared 타입보다는 actual 타입의 객체를 식별한다.

set print object off

가상 함수 테이블에 대한 참조 없이, 선언된 타입의 객체만을 출력한다. 이 옵션은 기본적으로 셋팅된다.

show print object

현재 또는 선언된 객체 타입을 출력할지를 보여준다.

set print static-members

set print static-members on

C++ 객체를 보여줄때 정적 멤버를 출력한다. 기본은 on 이다.

set print static-members off

C++ 객체를 보여줄때 정적 멤버들을 출력하지 않는다.

show print static-members

C++ 정적 멤버들을 출력할지 안할지를 보여준다.

set print vtbl

set print vtbl on

C++ 가상 함수 테이블을 출력한다. 기본은 off이다.

set print vtbl off

C++ 가상 함수 테이블을 출력하지 않는다.

show print vtbl

C++ 가상함수 테이블을 출력할지 안할지를 보여준다.

값 히스토리

print 명령어가 출력한 값들은 GDB 값 히스토리에 저장된다. 이것은 다른 표현식에서 이 값들을 사용하길 허용한다. 값들은 심볼 테이블이 다시 읽혀지거나 버려질때까지 유지된다.(예로 file나 symbol-file 명령어.) 심볼 테이블이 변할때, 값 히스토리는 버려진다. 왜냐하면 값들은 심볼 테이블에 정의된 타입에 대한 포인터를 포함하기 때문이다.

출력된 값들은 여러분이 참조할수 있는 히스토리 수를 준다. 이들 히스토리 수는 1 부터 시작하는 연속된 정수들이다. print는 값 앞에 `$num = '를 출력하여 값에 할당된 히스토리 수를 보여준다.;여기서 num는 히스토리 수이다.

전 값을 참조하기 위해, `$' 다음에 값 히스토리 수를 사용해라. $는 히스토리내 가장 최근 값을 참조한다. 그리고 $$는 그 전 값을 참조한다. $$n는 끝에서 n 번째 값을 참조한다.; $$2는 $$에 우선하는 값이며, $$1는 $$과 같고 $$0는 $과 같다.

예를 들어, 여러분이 구조체에 대한 포인터를 출력한다고 하자. 그리고 구조체의 내용을 보길 원한다고 하자.

p *$

만일 여러분이 next가 다음 구조체에 대한 포인터를 가리키는 구조체 체인을 가지고 있다면, 여러분은 다음과 같이하여 다음것의 내용을 출력할수 있다:

p *$.next

여러분은 이 명령어를 반복하여 체인내 연속적인 링크들을 출력할수 있다.--여러분은 단지 RET만 타이핑하면 된다.

히스토리는 표현식이 아니라 값을 저장한다는 것에 주의해라. x의 값은 4이고 여러분은 이들 명령어를 타이핑할수 있다:

print x
set x=5

그리고 비록 x의 값이 바뀐다 할지라도, print 명령어에 의해 값 히스토리에 저장된 값은 4로 남는다.

show values: item 넘버와 함께 값 히스토리에 있는 마지막 10개의 값을 출력한다. show values는 값을 바꾼다는것을 제외하고, 이것은 `p $$9'를 10번 반복하는것과 같다.
show values n: 히스토리 item 수 n를 중심으로 10 히스토리 값을 출력한다.
show values +: 마지막으로 출력된 값들 다음의 10개의 히스토리 값들을 출력한다. 만일 더 많은 값들을 이용할수 없다면, show values +는 출력을 보여주지 않는다.

show values n를 반복하기 위해 RET를 누르는 것은 정확히 `show values +'과 같은 효과를 가진다.

편리 변수

GDB는 여러분이 값을 가지고 나중에 참조할수 있도록 GDB내에서 사용할수 있는 편리 변수를 제공한다. 이들 변수들은 GDB내에 전역적으로 존재한다;이들 변수는 프로그램의 일부분이 아니며 설정된 편리 변수들은 프로그램의 실행에 직접적인 영향을 주지 않는다. 이것이 여러분이 편리변수를 자유스럽게 사용할수 있는 이유이다.

편리 변수는 접두사로 `$'를 가진다. 만일 편리변수가 미리 정의된 기계-의존적 레지스터 이름( 레지스터 섹션을 참조해라.)중 하나가 아니라면, `$'다음의 이름들은 편리 변수로 사용된다. (대조적으로, 값 히스토리 참조들은 `$' 다음에 numbers이다. 값 히스토리 섹션을 참조해라.)

여러분은 프로그램내 변수를 설정하는 것처럼, 표현식을 할당하여 값을 편리변수에 저장할수 있다. 예를 들어:

set $foo = *object_ptr

이것은 object_ptr가 가리키는 객체에 포함된 값을 $foo에 저장한다.

처음에 편리 변수를 사용할려면 변수를 만들어라. 그러나 그 값은 여러분이 새로운 값을 할당할때까지 void이어야 한다. 여러분은 나중에 어떤때든지 다른 할당으로 값을 수정할수 있다.

편리 변수들은 고정된 타입이 없다. 여러분은 비록 그 변수가 이미 다른 타입의 값을 가지고 있다 할지라도, 구조체, 배열을 포함하여 어떤 타입이든지 편리 변수를 할당할수 있다. 표현식 처럼 사용될때, 편리 변수는 현재 값의 타입을 가지고 있다.

show convenience: 지금까지 사용된 편리 변수의 리스트와 그 값들을 보여준다. 간단히 show con로 할수 있다.

편리 변수를 사용하기 위한 방법중 하나는 증가하는 카운터나 나아가는 포인터로써이다. 예를 들어, 구조체 배열의 연속적인 요소에서 필드들을 출력하기 위해:

set $i = 0
print bar[$i++]->contents

RET로 그 명령어를 반복해라.

몇몇 편리 변수들은 자동적으로 GDB가 만들며 사용할수 있도록 값들을 준다.

$_: 변수 $_는 검사된 마지막 주소(메모리 검사하기 섹션을 참조해라.)에 대한 x 명령어에 의해 자동적으로 설정된다. 검사하기 위해 x를 위해 기본 주소 값들을 제공하는 다른 명령어들은 그 주소에 $_를 설정한다.: 이들 명령어는 info line와 info breakpoint 를 포함한다. $_ 타입은 $__ 타입을 가리키는 경우에 x 명령어에 의해 설정될때를 제외하고, void *이다.
$__: 변수 $__는 검사된 마지막 주소에서 값을 발견하기 위해 자동적으로 x명령어에 의해 설정된다. 타입은 데이터가 출력되는 포맷과 매치시키기 위해 선택된다.
$_exitcode: 변수 $_exitcode는 디버깅되는 프로그램을 끝마칠때 종료 코드를 자동적으로 설정한다.

레지스터들

여러분은 `$'에 이름을 가지는 변수처럼, 표현식에서 머신 레지스터 내용들을 참조할수 있다. 레지스터 이름들은 각 머신마다 다르다.; 머신에서 사용되는 이름을 보기위해 info registers를 사용해라.

info registers: 부동 소수점 레지스터(선택된 스택 프레임내에서)를 제외한 모든 레지스터들의 이름과 값들을 출력한다.
info all-registers: 부동 수수점 레지스터를 포함한 모든 레지스터의 이름과 값들을 출력한다.
info registers regname ...: 각 지정된 레지스터 regname의 상대적 값들을 출력한다. 세부적으로 토론하는 것처럼, 레지스터 값들을 보통 선택된 스택 프레임 값에 상대적이다. regname는 앞에 `$'가 있든 없든, 여러분이 사용하는 머신에서 유효한 레지스터 이름이다.

GDB는 대부분의 머신에서 이용(표현식에서)할수 있는 4개의 "표준" 레지스터 이름을 가지고 있다.--그것들은 아키텍쳐의 공식 내장 레지스터들과 충돌하지 않을때는 언제나. 레지스터 이름 $pc과 $sp는 프로그램 카운터 레지스터와 스택 포인터를 위해 사용된다. $fp는 현재 스택 프레임에 대한 포인터를 포함한 레지스터에 사용되며 $ps는 프로세서 상태를 포함하는 레지스터에 사용된다. 예를 들어, 여러분은 헥사값으로 프로그램 카운터를 출력할수 있다.

p/x $pc

또는 다음에 실행할 명령어를 출력한다.

x/i $pc

또는 스택 포인터(2)에 4를 더한다.

set $sp += 4

가능할때는 언제나, 이들 4개의 표준 레지스터 이름들은 비록 머신이 다른 내장 니모닉이라 할지라도 충돌이 없는 한, 이용할수 있다. info registers 명령어는 공식적인 이름을 보여준다. 예를 들어, SPARC에서 info registers는 $psr로써 프로세서 상태 레지스터를 출력하지만, 여러분은 $ps로 이 레지스터를 참조할수 있다.

GDB는 레지스터가 이런 방법으로 검사될때 정수로써 일반 레지스터의 내용을 고려한다. 몇몇 머신은 부동 소수점을 가질수 있는 특별한 레지스터를 가지고 있다; 이들 레지스터들은 부동 소수점 값을 가진것으로 고려한다. 부동 수서점 값처럼 일반 레지스터의 내용을 참조할 방법이 없다.(비록 여러분이 `print/f $regname'로 부동 소수점처럼 print를 할수 있다 할지라도)

몇몇 레지스터들은 "raw"와 "virtual" 데이터 포맷을 구분한다. OS에 저장되는 레지스터 내용의 데이터 포맷은 프로그램이 보는 것과 같지 않다는 의미이다. 예를 들어, 68881 부동 소수점 프로세서의 레지스터들은 항상 "extended" (raw) 형식으로 저장된다. 그러나 모든 C 프로그램들은 "double" (virtual) 형식으로 작동된다. 그런 경우에, GDB는 보통 virtual 형식(프로그램이 이해할수 있는 형식)만으로 작동한다. 그러나 info registers 명령어는 두개 형식으로 데이터를 출력한다.

보통, 레지스터 값은 선택된 스택 프레임(프레임 선택하기 섹션을 참조해라.)과 관계가 있다. 이것은 만일 모든 스택 프레임이 종료되고 저장된 레지스터가 재저장되면 포함된 제지스터 값을 가질수 있다는걸 의미한다. 하드웨어 레지스터의 내용을 보기 위해, 여러분은 가장 내부 프레임(`frame 0')을 선택해야 한다.

그러나, GDB는 컴파일러에 의해 만들어진 기계어 코드에서 레지스터가 저장되는 곳을 줄여야 한다. 만일 몇몇 레지스터가 저장되지 않는다면, 또는 만일 GDB가 저장된 레지스터에 위치할수 없다면, 선택된 스택 프레임은 차이를 만들지 않는다.

set rstack_high_address address: AMD 29000 패밀리 프로세서에서, 레지스터들은 분리된 "register stack"에 저장된다. GDB가 이 스택의 크기를 결정할 방법은 없다. 보통, GDB는 스택은 "large enough"라고만 가정한다. 만일 필요하다면, 여러분은 set rstack_high_address 명령어로 레지스터 스택의 끝 주소를 지정하여 이 문제를 고려할수 있다. 인자는 주소이어야 하며, 여러분은 16진수로 지정하기 위해 앞에 `0x'를 두길 원할 것이다.
show rstack_high_address: AMD 29000 패밀리 프로세서에서, 레지스터 스택 프레임의 현재 제한값을 출력한다.

부동 소수점 하드웨어

설정에 의존하여, GDB는 부동 소수점 하드웨어의 상태에 관한 더 많은 정보를 준다.

info float: 부동 소수점 유닛에 관한 하드웨어 의존 정보를 보여준다. 정확한 내용과 레이아웃은 부동 소수점 칩에 의존하여 달라진다. 현재, `info float'는 ARM과 x86 머신을 지원한다.

다른 언어에서 GDB 사용하기

프로그램 언어들은 일반적으로 공통적인 면을 많이 가지고 있지만, 이들 언어들은 거의 같은 방식으로 표현되지 않는다. 예를 들어, ANSI C에서 포인터 p의 역참조는 *p이지만, Modula-2에서는 p^이다. 값들도 보통 다르게 표현된다. C에서 16진수 값은 `0x1ae'처럼 나타나지만 Modula-2에서는 `1AEH'처럼 나타난다.

언어 의존적인 정보는 여러분이 프로그램의 원 언어에서의 작동을 표현하도록 하기 위해 그리고 프로그램의 원 언어의 문법과 일관되게 출력 값을 GDB에게 허용하기 위해 GDB내에 내장되어 있다. 여러분이 사용하는 언어는 working language 라고 부른다.

소스 언어 변경.

working language를 제어하기 위해서는 2가지 방법이 있다.--GDB가 자동적으로 설정 하든지 여러분 스스로 선택하든지의 방법. 여러분은 set language 명령어를 사용하여 설정할수 있다. 시작시, GDB는 자동적으로 언어를 설정한다. working language는 여러분의 표현식이 해석되는 방법, 값들이 출력되는 방법등을 결정하기 위해 사용 된다.

working language 이외에, GDB가 알고 있는 모든 소스 파일은 자신의 working language를 가지고 있다. 몇몇 객체 파일 포맷에서, 컴파일러는 특정 소스 파일 언어가 어느것인지 를 가리킨다. 그러나, GDB는 대부분 파일의 이름에서 언어를 유추한다. 소스 파일의 언어는 C++이름이 demangle하는 것처럼 제어한다. -- backtrace 방법은 자신의 언어를 위해 적절히 각 프레임을 보여준다. GDB내에서 소스 파일의 언어를 설정하기 위한 방법은 없다.

이것은 여러분이 C로 만들었지만 다른 언어로 쓰여진 cfront나 f2c같은 프로그램을 사용할때 가장 일반적인 문제이다. 그 경우, C 출력시 #line 지시어를 사용하도록 프로그램을 만들어라.; GDB는 원 프로그램의 소스 코드의 적절한 언어를 알것이다. 그리고 소스 코드를 보여주며 C코드는 만들지 않을 것이다.

파일 이름 확장 리스트과 언어들

소스 파일 이름이 다음 확장들중 하나라면, GDB는 그 언어가 다음중 하나를 가리킨다고 생각한다.

`.mod': Modula-2 소스 파일
`.c': C source file
`.C'
`.cc'
`.cxx'
`.cpp'
`.cp'
`.c++': C++ 소스 파일
`.ch'
`.c186'
`.c286': CHILL 소스 파일
`.s'
`.S': 어셈블리어 소스 파일. 이것은 거의 C처럼 행동하지만, GDB는 stepping할때 함수 prologue를 지나치지 않는다.

working language 설정하기

여러분이 자동적으로 언어를 설정하도록 GDB를 허용한다면, 표현식은 디버깅 세션 및 여러분의 프로그램에서 같은 방법으로 해석된다.

여러분이 원한다면, 여러분은 언어를 설정할수 있다. 이것을 하기 위해, 명령어 `set language lang'를 사용해라. 여기서 lang는 c나 modula-2같은 언어 이름이다. 지원 언어의 리스트를 보고 싶으면, `set language'를 타이핑해라.

언어 설정은 GDB가 자동적으로 working language 갱신하는것을 막아준다. 만일 여러분이 working language가 소스 언어와 같지 않을때나 표현식이 두 언어를 모두 수용할때--그러나 의미는 다를때-- 프로그램을 디버깅할 경우 이것은 혼란을 야기한다. 예를 들어, 현재 소스 파일이 C로 쓰여졌고, GDB는 Modula-2를 파싱한다면:

print a = b + c

위 명령어는 여러분이 의도한 대로 되지 않는다. C에서, 이것은 b와 c를 더하고 결과를 a에 놓는다. 출력 결과는 a 값이된다. Modula-2에서, 이것은 a와 b+c의 결과를 비교한다. 그리고 BOOLEAN결과를 가진다.

GDB로 소스 언어 추정하기

working language를 자동적으로 설정하도록 GDB를 가질려면, `set language local'나 `set language auto'를 사용해라. 그러면 GDB는 working language를 추정한다. 즉, 여러분의 프로그래밍 프레임에서 멈출때(보통 breakpoint를 만날때), GDB는 working language를 프레임내 함수를 위해 기록된 언어로 설정한다. 만일 프레임에서의 언어를 알지 못한다면(즉, 함수나 프레임에 해당하는 블럭이 인식되는 확장이 아닌 소스 파일안에 정의되어 있다면), 현재 working language는 바뀌지 않는다. 그리고 GDB는 경고를 보여준다.

이것은 하나의 소스 파일 전체에 쓰여진 대부분의 프로그램에서는 필요하지 않다. 그러나, 하나의 소스 언어로 쓰여진 프로그램 모듈화와 라이브러리는 다른 소스 언어로 쓰여진 주 프로그램에 의해 사용될수 있다. 이런 경우 `set language auto'을 사용하면 working language를 설정하는데 여러분을 자유스럽게 해준다.

언어 보여주기

다음 명령어들은 여러분이 working language가 무엇인지를 발견하는데 도와준다. 그리고 또한 언어 소스 파일들이 무슨 언어로 쓰여졌는지도 발견하는데 도와준다.

show language: 현재 working language를 보여준다. 이것은 언어에서 여러분이 프로그램의 변수 표현식을 계산하기 위해 print와 같은 명령어를 사용하는 것과 같다.
info frame: 프레임내 소스 언어를 보여준다. 이 언어는 만일 여러분이 프레임에서 식별자를 사용 한다면 working language가 된다. 여기에 나열된 다른 정보를 원한다면, 프레임 정보 섹션을 참조해라.
info source: 소스 파일의 소스 언어를 보여준다. 여기에 나열된 다른 정보를 원한다면, 심볼 테이블 검사하기 섹션을 참조해라.

타입과 범위 검사

경고: 이번 릴리즈에서, 타입과 범위 검사를 위한 GDB 명령어들이 추가되었다 그러나 아직 어떤 영향을 가지지는 않는다. 이 섹션은 지정된 기능들을 문서화 했다.

몇몇 언어들은 컴파일-실행시간 검사를 통해 일반적 에러를 만들지 않도록 하기 위해 고안되었다. 이것들은 함수와 연산자에 대한 인자 타입 검사를 포함하며 확실한 수학적 어버플로어 검사는 런타임시 행해진다. 이와 같은 검사들은 일단 프로그램이 올바르게 돌아가는걸 도와주며 타입 불일치등을 제거하며 컴파일 되고 프로그램이 실행될때 범위 에러들을 검사한다.

GDB는 여러분이 원한다면 위와 같은 조건들을 검사한다. 비록 GDB가 여러분의 프로그램내 문장들을 검사하지 않음에도 불구하고, print 명령어를 통한 평가를 위해 GDB로 직접 들어가 표현식을 검사할수 있다. working language처럼, GDB는 또한 프로그램 소스 언어 기반으로 검사할지 안할지를 결정할수 있다. 지원되는 언어의 기본 설정을 보기 워한다면, 지원되는 언어들섹션을 참조해라.

타입 검사에 대한 개관

Modula-2같은 몇몇 언어들은 연산자와 함수들에 대한 인자들이 올바른 타입인지를 강하게 검사하며 그렇지 않을 경우에는 에러를 발생한다. 이들 검사들을 타입이 달라 실행시간 문제를 야기하는 에러들을 막는다. 예를 들어,

1 + 2 => 3
but
error--> 1 + 2.3

두번째 예는 실패한다. 왜냐하면 CARDINAL 1은 REAL 2.3과 타입이 호환되지 않기 때문이다.

여러분이 GDB 명령어에서 사용할 표현식을 위해, 여러분은 검사를 그냥 넘어가도록 GDB 타입 검사자에게 말할수 있다; 에러같은 어떤 불일치를 처리하고 표현식을 버리기 위해; 또는 불일치된 타입이 일어날때 표현식은 평가하고 경고를 알려주기 위해. 여러분이 이것들중 마지막을 선택할때, GDB는 위의 두번째 예처럼 표현식을 평가하며, 경고도 알려준다.

비록 여러분이 타임 검사를 껐다 할지라도, 거기에는 GDB가 표현식 평가를 막도록하는 데에는 타입과 관련된 몇가지 다른 이유가 있다. 예를 들어, GDB는 int와 struct foo를 추가하는 방법을 알지 못한다. 이러한 특별한 타입 에러들은 사용하는 언어들과는 관계가 없다. 그리고 위에 설명한 것들처럼 표현식에서 일어난다.

각 언어들은 타입에 관해 엄격한 정도를 정의한다. 예를 들어, Modula-2와 C는 산술적 연산자를 위해 인자를 요구한다. C에서, 열거된 타입과 포인터들은 수로써 다시 표현되고, 그래서 이것들은 수치적 연산자를 위해 유효한 인자이다. 특정 언어에 대한 세부적 사항을 위해서는 지원되는 언어들 섹션을 참조해라.

GDB는 타입 검사자를 제어하기 위해 추가적인 명령어를 제공한다:

set check type auto: 현재 working language에 기반하여 타입 검사를 할지를 안할지를 설정한다. 각 언어에 대한 기본 설정을 위해서는 지원되는 언어들 섹션을 참조해라.
set check type on
set check type off: 현재 working language 기본 설정값을 덮어 쓰도록 타입 검사를 on 또는 off로 설정한다. 만일 설정이 기본 언어와 맞지 않다면 경고를 보여 준다. 만일 어떤 타입 불일치가 타입 검사가 on인 동안에 표현식 평가중에 일어난다면, GDB는 메세지를 보여주고 표현식 평가에서 중단된다.
set check type warn: 경고를 보여주기 위해 타입 검사자를 설정하고 항상 표현식 평가를 위해 시도된다. 표현식 평가는 여전히 다른 이유에서 불가능하다. 예를 들어, GDB는 멤버들과 구조체들을 추가할수 없다.
show type: 타입 검사자의 현재 설정을 보여주며, GDB가 자동으로 설정하였는지 안했는지를 보여준다.

범위 검사에 대한 개관

몇몇 언어(Modula-2와 같은)는, 타입의 범위를 초과하면 에러이다; 이것은 실행시간 검사에서 강요된다. 그런 범위 검사는 계산이 오버플로어하지 않고, 배열의 범위를 넘어선 배열 요소를 접근하지 못하도록 프로그램을 정확하게 해준다.

여러분이 GDB 명렁어에서 사용하는 표현식에서, 여러분은 GDB가 세가지 중 하나로 범위 에러를 대하도록 할수 있다: 무시하거나, 항상 에러로써 대하고 표현식에서 중지하거나 경고를 보여주고 표현식을 평가하도록.

범위 에러는 수치적 오버플로어나 배열 인텍스 경계를 넘어설 경우, 여러분이 어떤 타입의 멤버가 아닌 상수를 타입할때 나온다. 그러나, 몇몇 언어들은 에러로써 오버플로어를 다루지 않는다. C에서, 수치적 오버 플로어는 "wrap around" 결과를 야기한다.--예를 들어, 만일 m가 정수 값보다 크고, s는 작다면, 그러면

m + 1 => s

이것은 또한 각각의 언어에 의존하며 몇몇 경우는 컴파일러나 머신에 의존적이다. 특정 언어에 대한 세부사항을 보고자 하면 지원되는 언어들섹션을 참조해라.

GDB는 범위 검사자를 제어하기 위해 추가적인 명령어를 제공한다:

set check range auto: 현재 working language에 기반하에 범위 검사를 on이나 off를 설정한다. 각 언어에 대한 기본 설정을 위해서는 지원되는 언어들 섹션을 참조해라.
set check range on
set check range off: 현재 working language 기본 설정값을 덮어 쓰도록 범위 검사를 on 또는 off로 설정한다. 만일 설정이 기본 언어와 맞지 않다면 경고를 보여준다. 만일 어떤 타입 불일치가 타입검사가 on인 동안에 표현식 평가중에 일어난다면, GDB는 메세지를 보여주고 표현식 평가에서 중단된다.
set check range warn: GDB 범위 검사자가 범위 에러를 찾았을때 메세지를 출력하고 표현식을 평가하기 위해 시도한다. 표현식 평가는 여전히 다른 이유에서 불가능하다. 예를 들어, 프로세스 가 소유하지 않은 메모리에 접근하는 경우이다.(많은 유닉스 시스템의 전형적인 예)
show range: 범위 검사자의 현재 설정값을 보여주며, GDB가 자동적으로 설정하였는지 안했는지를 보여준다.

지원되는 언어들

GDB 4는 C, C++ 그리고 Modula-2를 지원한다. 몇몇 GDB 특징들은 사용하는 언어에 관계없이 표현식에서 사용될수 있다.: GDB @과 :: 연산자, 그리고 `{type}addr' 생성자는(표현식 섹션을 참조해라.) 지원되는 언어의 생성자와 함께 사용될수 있다.

다음 섹션들은 GDB가 지원하는 각 소스 언어들에 대한 상세한 내용이다. 이들 섹션은 언어 매뉴얼은 아니지만, GDB 표현식 파서가 수용하는 것을 알려주는 레퍼런스 같은 것이다. 그리고 입출력 포맷은 다른 언어들 처럼 보여야 한다. 각 언어를 위해 쓰여진 좋은 책들이 많이 있다; 언어 매뉴얼을 위해서 이것들을 참조해라.

C 그리고 C++

C와 C++은 매우 관계가 많기 때문에, GDB의 많은 특징들이 두 언어에 적용된다. 해당 경우에, 우리는 두 언어를 함께 논의할 것이다.

C++ 디버깅 기능은 GNU C++ 컴파일러와 GDB에 의해 수행된다. 그러므로, 효과적으로 C++코드를 디버깅하기 위해, 여러분은 GNU C++ 컴파일러 g++로 C++프로그램을 컴파일 해야 한다.

C++ 프로그램을 디버깅할때, stab 디버깅 포맷을 사용해라. 여러분은 g++ 명령어 옵션 `-gstabs'나 `-gstabs+'를 사용하여 포맷을 선택할수 있다. 더 많은 정보를 위해 Using GNU CC의 `Options for Debugging Your Program or GNU CC' 섹션을 참조해라.

C 그리고 C++ 연산자

연산자들은 특정 타입의 값으로 정의되어야 한다. 예를 들어, +는 구조체가 아닌 숫자로 정의되어 있다. 연산자들은 그룹의 타입으로 자주 정의되어 있다.

C와 C++을 위해, 다음 정의들이 있다:

Integral types는 다음과 같은 스토리지-클래스와 함께 int를 포함한다. ; char; 그리고 enum.
Floating-point types는 float 그리고 double를 포함한다.
Pointer types는 (type*)과 같이 정의되어있는 모든 타입을 포함한다.
Scalar types는 위의 모든걸 포함한다.

다음 연산자들도 지원된다. 우선권이 높은순으로 리스트되어 있다.

,: 컴마나 순차 연산자. 컴마로 분리되어 나열된 표현식은 왼쪽에서 오른쪽으로 평가된다.
=: 대입. 대입 표현식 값은 대입된 값이다. 스칼라 타입으로 정의되어 있다.
op=: a op= b 형태의 표현식으로 사용되며, a = a op b 과 같이 해석된다. op= 와 = 는 우선권이 같다. op는 |, ^, &, <<, >>, +, -, *, /, % 중 하나이다.
?:: 3항 연산자. a ? b : c는 다음과 같다: 만일 a라면 b이고, 그렇지 않으면 c이다. a는 정수형이어야 한다.
||: 논리적 OR. 정수형에서만 정의된다.
&&: 논리적 AND. 정수형에서만 정의된다.
|: Bitwise OR. 정수형에서만 정의된다.
^: Bitwise exclusive-OR. 정수형에서만 정의된다.
&: Bitwise AND. 정수형에서만 정의된다.
==, !=: 등가와 비등가. 스칼라형에서만 정의된다. 이 표현식의 값은 0이면 거짓이고 0이 아니면 참이다.
<, >, <=, >=: 작거나, 크거나, 작거나 같고, 크거나 같다. 스칼라 형에서만 정의된다. 이 표현식의 값은 0이면 거짓이고 0이 아니면 참이다.
<<, >>: 왼쪽으로 쉬프트 그리고 오른쪽으로 쉬프트. 정수형에서만 정의된다.
@: GDB "인공 배열" 연산자(표현식 섹션을 참조해라.).
+, -: 더하기 그리고 빼기. 정수형, 부동소수형, 포인터형에서만 정의된다.
*, /, %: 곱하기, 나누기, 나머지연산. 곱하기와 나누기는 정수형, 부동소수형에서만 정의된다. 나머지 연산은 정수형에서만 정의된다.
++, --: 증가, 감소. 변수앞에 쓰이면, 연산은 변수가 표현식대로 사용되기 전에 수행된다; 변수 뒤에 쓰이면, 연산이 되기전에 변수 값이 사용된다.
*: 포인터 역참조. 포인터형에서만 정의된다. ++과 연산순위가 같다.
&: 주소 연산자. 변수에서 정의된다. ++과 연산순위가 같다. C++을 디버깅할때, GDB는 C++ 언어자체에서 허용하는 범위이상으로 `&'을 사용할수 있다.: 여러분은 C++ 참조 변수(`&ref'로 선언된)가 저장되어 있는 주소를 검사하기 위해 `&(&ref)`을 사용할수 있다.(또는, 여러분이 원한다면, 간단히 `&&ref')
-: 부정. 정수형이나 부동 소수형에서만 정의된다. ++과 연산순위가 같다.
!: 논리적 부정. 정수형에서만 정의된다. ++과 연산순위가 같다.
~: Bitwise 보수 연산자. 정수형에서만 정의된다. ++과 연산순위가 같다.
., ->: 구조체 멤버, 그리고 포인터가 가리키는 구조체 멤버. 편의를 위해, GDB는 두개를 같은것으로 간주하며, 저장된 타입의 정보에 기반하여 역참조 포인터인지 어떤지를 선택한다. struct과 union 데이터에서 정의된다.
[]: 배열 인덱스. a[i]는 *(a+i)처럼 정의된다. ->과 연산순위가 같다.
(): 함수 파라미터 리스트. ->과 연산순위가 같다.
::: C++ 범위 연산자. struct, union, 그리고 class 타입에서만 정의된다.
::: 더블 콜론 또한 GDB 범위 연산자로 표시된다. (Expressions 섹션을 참조해라.). 위의 ::과 연산순위가 같다.

C , C++ 상수들

GDB는 여러분이 다음과 같은 방법으로 C와 C++상수들을 나타낼수 있도록 허용한다.:

정수형 상수들은 연속된 숫자이다. 8진수 상수들은 앞에 `0'(즉, 0), 그리고 16진수 상수들은 `0x'나 `0X'이 앞에 온다. 상수들은 보통 문자 `l'로 끝난다. 이것은 상수는 long 값으로 대해야 한다는것을 가리킨다.
부동 소수점 상수들은 연속된 수, 소수점다음에 연속된 정수, 그리고 선택적으로 지수승이 뒤따른다. 지수의 형태는: `e[[+]|-]nnn'이며, nnn는 다른 연속된 수이다. `+' 는 양의 지수를 나타낸다.
열거된 상수들은 열거된 식별자나 정수등으로 이루어진다.
문자 상수들은 단일 인용부호 (')에 의해 둘러싸여져 있는 단일 문자나 수--문자(ASCII 값)의 숫자값--이다. 인용부호안에서, 단일 문자는 문자나 escape sequences를 나타내며, 그것은 `\nnn'의 형태이며, nnn는 문자의 8진수 순서값(ASCII 값)을 나타낸다.; 또는 `\x'의 형태이며, `x'는 미리 정의된 특별한 문자이다--예를 들어, newline은 `\n'
문자열 상수는 이중 인용부호(")에 의해 둘러싸여져 있는 연속된 문자 상수들이다.
포인터 상수는 정수 값이다. 여러분은 C 연산자 `&'를 사용하여 상수들에 대한 포인터를 쓸수 있다.
배열 상수들은 괄호 `{'와 `}'에 의해 둘러싸여저 콤마로 분리된 리스트이다.; 예를 들어, `{1,2,3}'는 3개-원소의 정수 배열이며, `{{1,2}, {3,4}, {5,6}}'는 three-by-two 배열이고 `{&"hi", &"there", &"fred"}'는 3개 원소들의 포인터 배열이다.
C++ 표현식

GDB 표현식 처리는 C++표현식의 중요 부분집합을 해석하기 위한 확장된 수들을 가지고 있다.

경고: 여러분이 GNU C++ 컴파일러로 컴파일 한다면 GDB는 C++ 코드를 디버깅 할수 있다. 게다가, C++디버깅은 심볼 테이블에 추가적인 디버깅 정보를 사용 하였는지에 의존 하며 특별한 지원을 요구한다. GDB는 stab 디버깅 포맷을 가진것만 지원한다. 특별히, 만일 여러분의 컴파일러가 심볼 테이블을 위한 stab 확장을 가지고 있는 a.out, MIPS ECOFF, RS/6000 XCOF, 또는 ELF를 만든다면, 이들 기능은 모두 이용할수 있다. (GNU CC로, 여러분은 stab 디버깅 확장을 위해 `-gstabs'을 사용할수 있다.) 객체 코드 포맷은 표준 COFF 또는 ELF에서 DWARF, 다른 한편으로, GDB에서 대부분의 C++ 지원은 작동하지 않는다.
1. 멤버 함수 호출은 허용된다.; 여러분은 다음과 같은 표현식을 사용할수 있다.
```
count = aml->GetOriginal(x, y)
```
2. 멤버 함수가 활성화(선택된 스택 프레임에서)되어 있는 동안, 여러분의 표현식은 멤버 함수처럼 같은 네임 스페이스를 이용할수 있다.: 즉, GDB는 C++과 같은 규칙을 허용하는 클래스 객체 포인터 this를 허용한다.
3. 여러분은 오버로드된 함수를 호출할수 있다; GDB는 한가지 제약을 주어 적당한 정의로 이 함수 호출을 할수 있다.--여러분은 여러분이 호출하길 원하는 함수에 의해 요구되는 타입의 인자를 사용해야 한다. GDB는 생성자나 사용자-정의 타입 연산자를 요구하는 변환을 하지 않는다.
4. GDB는 C++ 레퍼런스로 선언된 변수를 이해한다; 여러분은 C++소스에서 처럼 표현식에서 사용 할수 있다--이것들은 자동적으로 역참조 된다. GDB가 프레임을 출력할때 보여줬던 파라미터 리스트에서, 참조 변수의 값은 출력되지 않는다(다른 변수와 달리); 이것들은 난잡한걸 피한다. 왜냐하면 참조는 자주 커다란 구조체를 위해 사용되기 때문이다. 만일 여러분이 `set print address off'를 지정하지 않는다면, 참조 변수의 address는 항상 보여진다.
5. GDB는 C++ 이름 분해 연산자 ::를 지원한다--여러분의 표현식은 프로그램에서 하는 표현식처럼 사용할수 있다. 하나의 범위가 다른 곳에서 정의되었다 할지라도, 여러분은 필요하다면, 예를 들어 `scope1::scope2::name' 처럼 반복적으로 ::를 사용할수 있다. GDB는 또한 C, C++ 디버깅(프로그램 변수들섹션을 참조해라.)에서 소스 파일에 대한 참조에 의해 이름 범위 분해를 허용한다.
C 그리고 C++ 기본값

만일 여러분이 자동적으로 타입과 범위 검사를 설정하도록 GDB를 허용한다면, 작업 언어가 C나 C++로 바뀌었을때는 언제나 기본값으로 off가 된다. 이것은 여러분이나 GDB가 작업언어를 선택할때에 관계없이 일어난다.

만일 여러분이 자동적으로 언어를 설정하도록 GDB를 허용한다면, 그것은 `.c', `.C', or `.cc'를 끝이름으로 가지고 있는 소스 파일을 인식하고, GDB가 이들 파일들 하나에서 컴파일된 코드에 들어간다면, GDB는 C나 C++로 작업 언어를 설정한다. 세부적 사항을 위해 GDB로 소스 언어 추론하기.섹션을 참조해라.

C 그리고 C++ 타입과 범위 검사

기본적으로, GDB가 C나 C++ 표현식을 파싱할때, 타입 검사는 사용되지 않는다. 그러나, 만일 여러분이 타입 검사를 켜 놓았다면, GDB는 다음의 경우 두 변수의 타입을 같은 것으로 고혀한다.
- 두 변수들은 구조체이고 같은 구조체 유니온이나 열거된 태그이다.
- 두 변수는 같은 타입 이름이나 typedef를 통해 같이 선언되었던 타입을 가지고 있다.
만일 켜져 있다면, 범위 검사는 수치적 연산자로 행해진다. 변수 인덱스는 검사되지 않는다. 왜냐하면, 인덱스들은 자주 배열 자체로가 아닌 포인터를 인텍스하기 위해 사용되기 때문이다.

GDB 와 C

set print union와 show print union 명령어는 union 타입에 적용된다. `on'로 설정되었을때, struct나 class 내부의 어떤 union 또한 출력된다. 그렇지 않으면, 그것은 `{...}'처럼 나타난다.

@연산자는 포인터들과 메모리 할당 함수로 형성된 동적 배열의 디버깅을 도와준다. 표현식 섹션을 참조해라.

C++을 위한 GDB 특징들

몇몇 GDB 명령어들을 C++에서 유용하다. 그리고 몇몇 명령어들은 C++사용을 위해 디자인되 었다. 정리하면:

breakpoint menus
여러분이 오버로딩된 이름의 함수에 breakpoint를 원한다면, GDB breakpoint menus는 여러분이 원하는 함수 정의가 어느것인지를 지정하는데 도와준다. Breakpoint menus 섹션을 참조해라.
rbreak regex
정규식 표현을 사용하는 breakpoint 설정은 특정 클래스의 멤버가 아닌 오버로딩된 brekapint 설정을 도와준다. breakpoints 설정하기 섹션을 참조해라.
catch exceptions

info catch
이 명령어를 사용하여 C++ 예외 처리를 디버깅하라. Breakpoints 와 예외 섹션을 참조해라.
ptype typename
타입 typename를 위한 다른 정보뿐만 아니라 상속 관계도 출력한다. 심볼 테이블 검사하기 섹션을 참조해라.
set print demangle

show print demangle

set print asm-demangle

show print asm-demangle
C++ 소스로써 코드를 출력할때와 디스어렘블리를 출력할때 소스 형태로 C++ 심볼들을 출력할지를 제어한다. 출력 설정 섹션을 참조해라.
set print object

show print object
객체의 실제 타입을 출력 할지 선언된 타입을 출력 할지를 선택한다. 출력 설정 섹션을 참조해라.
set print vtbl

show print vtbl
가상 함수 테이블 출력을 위한 포맷을 제어한다. 출력 설정 섹션을 참조해라.
Overloaded symbol names
여러분은 C++에서 심볼들의 선언을 위해 사용된 같은 표기를 사용하여, 오버로딩된 심볼들의 정의를 지정할수 있다.: 단지 symbol보다는 symbol(types). 여러분은 또한 이용할수 있는 선택을 리스트 하기 위해서나 리스트된 타입을 마치기 위해 GDB 명령어-라인 완성형을 사용할수 있다. 이것에 관한 세부사항을 보고자하면, 명령어 완성 섹션을 참조해라.

Modula-2

Modula-2를 지원하기 위해 GDB를 만들기 위한 확장들은 GNU Modula-2 컴파일러(현재도 개발중)에서 나왔다. 다른 Modula-2 컴파일러들은 현재 지원되지 않으며, 그것들에 의해 만들어진 실행 파일들을 디버깅하기 위한 시도는 GDB가 실행 심볼 테이블을 읽은 것처럼 대부분 에러를 준다.

연산자

연산자는 특정 타입의 값으로 정의되어야 한다. 예를 들어, +는 숫자에서 정의되지만 구조체에서는 아니다. 연산자들은 자주 그룹 타입으로 정의된다. Modula-2의 목적을 위해, 다음 정의들이 있다:
- Integral types은 INTEGER, CARDINAL, 그리고 하위 범위로 이루어진다.
- Character types은 CHAR 그리고 하위 범위로 이루어진다.
- Floating-point types은 REAL로 이루어진다.
- Pointer types은 POINTER TO type 과 같이 선언된 것으로 이루어진다.
- Scalar types은 위의 모든것으로 이루어진다.
- Set types은 SET 그리고 BITSET 타입으로 이루어진다.
- Boolean types은 BOOLEAN타입으로 이루어진다.
다음 연산자들도 지원되며 증가하는 우선권으로 나타난다.:

,
함수 인자나 배열 인덱스 분리자.
:=
대입. var := value의 값은 value이다.
<, >
정수, 부동 소수점, 또는 열거형보다 작거나 크다.
<=, >=
정수, 부동 소수점, 또는 나열형 또는 설정된 타입을 포함하여 작거나, 크거나, 작거나 같거나, 크거나 같거나. <와 연산순위가 같다.
=, <>, #
등호 그리고 같지 않은 표현식의 두가지 방법, 유효한 스칼라 형. <과 연산순위가 같다. GDB 스크립트에서, 단지 <>만 부등을 위해 이용할수 있다. 왜냐하면 #는 스크립트의 주석과 충돌하기 때문이다.
IN
멤버쉽 설정. 타입과 멤버의 타입을 정의한다. <과 연산순위가 같다.
OR
불린형 OR. 불린형에만 정의된다.
AND, &
분린형 AND. 불린형에만 정의된다.
@
GDB "인공 배열" 연산자(Expressions 섹션을 참조해라.)
+, -
정수형과 부동 소수점 형, 또는 유니온 그리고 다른 타입의 집합에서 더하기 빼기
*
Multiplication on integral and floating-point types, or set intersection on set types.
/
부동 소수점 타입이나 형에서 대칭형의 다른 타입에서 나누기. *과 연산순위가 같다.
DIV, MOD
정수 나누기와 나머지. 정수형에서 정의된다. *과 연산순위가 같다.
-
부정. INTEGER과 REAL 데이터에서 정의된다.
^
포인터 역참조. 포인터형에서만 정의된다.
NOT
불린형 부정. 불린형에서 정의된다. ^과 연산순위가 같다.
.
RECORD 필드 선택자. RECORD 데이터에서 정의된다. ^과 우선순위가 같다.
[]
배열 인덱싱. ARRAY 데이터에서 정의된다. ^과 연산순위가 같다.
()
순차형 인지 리스트. PROCEDURE 객체에서 정의된다. ^과 연산순위가 같다.
::, .
GDB와 Modula-2 범위 연산자.

경고: Sets and their operations are not yet supported, so GDB treats the use of the operator IN, or the use of operators +, -, *, /, =, , <>, #, <=, and >= on sets as an error.

내장 함수와 프로시져

Modula-2는 몇몇 내장 프로시져와 함수를 이용할수 있다. 이걸 기술할때, 다음 메타 변수들이 사용된다.

a
ARRAY 변수를 나타낸다.
c
CHAR 상수나 변수를 나타낸다.
i
변수나 정수형 상수를 나타낸다.
m
집합에 속하는 식별자를 나타낸다. 일반적으로 메타 변수 s와 함께 같은 함수에서 사용된다. 타입 s는 SET OF mtype이어야 한다. (mtype는 타입 m이다.)
n
변수나 정수형 상수 또는 부동 소수점 형을 나타낸다.
r
변수나 부동 소수점 형 상수를 나타낸다.
t
형을 나타낸다.
v
변수를 나타낸다.
x
변수나 많은 형중 하나의 상수를 나타낸다. 세부적인 것을 위해 함수의 설명을 참조해라.

모든 Modula-2 내장 프로시져는 다음에 설명하는 것처럼 결과를 리턴한다.

ABS(n)
절대 값 n를 리턴한다.
CAP(c)
만일 c가 소문자라면, 그것은 같은 대문자를 리턴한다. 그렇지 않으면, 그것은 인자를 리턴한다.
CHR(i)
서수 값 i의 문자를 리턴한다.
DEC(v)
변수 v의 값을 감소한다. 새로운 값을 반환한다.
DEC(v,i)
i로 변수 v의 값을 감소시킨다. 새로운 값을 리턴한다.
EXCL(m,s)
집합 s에서 원소 m을 제거한다. 새로운 집합을 반환한다.
FLOAT(i)
정수 i와 같은 부동 소수형을 반환한다.
HIGH(a)
a의 마지막 멤버의 인덱스를 리턴한다.
INC(v)
변수 v에 있는 값을 감소한다. 새로운 값을 리턴한다.
INC(v,i)
i로 변수 v에 있는 값을 증가시킨다. 새로운 값을 반환한다.
INCL(m,s)
원소 m가 집합 s에 있지 않다면 추가시킨다. 새로운 집합을 리턴한다.
MAX(t)
타입 t의 최대 값을 리턴한다.
MIN(t)
타입 t의 최소 값을 리턴한다.
ODD(i)
만일 i가 홀수라면 TRUE를 반환한다.
ORD(x)
인자의 서수를 반환한다. 예를 들어, 문자의 서수 값은 ASCII 값이다.(머신에서 지원하는 ASCII 문자 집합). x는 서수형이어야 하며 정수, 문자 열거형을 포함한다.
SIZE(x)
인자의 크기를 반환한다. x는 변수나 형이다.
TRUNC(r)
r의 정수형을 반환한다.
VAL(t,i)
서수 값이 i인 타입 t의 멤버를 반환한다.

경고: 집합과 그것들의 연산은 아직 지원되지 않는다. 그래서 GDB는 프로시져 INCL과 EXCL의 사용을 에러로써 대한다.

상수들

GDB는 다음 방법으로 Modula-2의 상수들을 표현하도록 여러분에게 허용한다.:
- 정수형 상수는 단순히 연속된 숫자이다. 표현식이 사용될때, 상수는 표현식의 나머지와 함께 타입-호환되도록 해석된다. 16진수 정수들은 마지막에 `H'로 지정되며 8진수 값은 마지막에 `B'가 지정된다.
- 부동 소수점 상수들도 10진수와 다른 연속된 수가 뒤따르는 연속된 숫자처럼 보인다. 지수는 `E[+|-]nnn'의 형태로 지정될수 있다. 반면에 `[+|-]nnn'는 원하는 지수형태이다. 부동 소수점형 상수의 숫자 모두는 유효한 10진수이어야 한다.
- 문자 상수는 단일 (')나 더불 (") 인용구의 의해 닫혀진 단일 문자로 이루어진다. 그들은 순서 값에 의해 표현되며(ASCII 값), `C'가 뒤따른다.
- 문자열 상수는 단일 (')나 더블 (") 인용구같은 쌍에 의해 닫혀진 연속된 문자들로 이루어진다. C 스타일의 이스케이프 순서 또한 허용된다. 이스케이프 순서에 대한 간단한 설명을 원하면 C 그리고 C++ 상수들 섹션을 참조해라.
- 열거형 상수들은 열거형 식별자들로 이루어진다.
- 불린형 상수들은 식별자 TRUE 그리고 FALSE로 이루어진다.
- 포인터 상수들은 단지 정수 값들로만 이루어진다.
- 상수 집합들은 아직 지원되지 않는다.
Modula-2 기본값

타입과 범위 검사를 자동적으로 GDB에 의해 설정된다면, 작업 언어가 Modula-2로 바뀔때는 언제나 기본적으로 on가 된다. 이것은 여러분이나 GDB가 선택된 작업 언어에 관계없이 일어난다.

만일 여러분이 자동적으로 언어를 설정하도록 GDB를 허용한다면, `.mod' 라는 이름의 작업 언어를 Modula-2로 설정하기 위해 파일에서 컴파일된 코드로 들어간다. GDB로 소스 언어 추정하기 섹션을 참조해라.

표준 Modula-2에서 벗어난 것

몇몇 변화는 디버깅 하기 쉽도록 Modula-2 프로그램을 만들기 위해 만들었다. 이것은 타입 엄격함을 덜하도록 한다.:
- 표준 Modula-2에서와 달리, 포인터 상수들은 정수로써 형성된다. 이것은 여러분이 디버깅 동안 포인터 변수들을 수정하도록 허용한다.(표준 Modula-2에서, 포인터 변수에 포함되어 있는 실제 주소는 여러분에게서 숨겨진다; 그것은 다른 포인터 변수나 포인터를 반환하는 표현식으로 직접 할당을 통해 수정될수 있다.)
- C 이스케이프 시퀀스는 비 출력 문자들을 나타내기 위해 스트링과 문자들에서 사용된다. GDB는 이들 내장된 이스케이프 시퀀스를 가진 문자열을 출력한다. 단일 비-출력 문자들은 `CHR(nnn)' 포맷을 사용하여 출력한다.
- 대입 연산자(:=)는 오른쪽 인자의 값을 리턴한다.
- 모든 내장 프로시져는 그들의 인자를 수정하고 반환한다.
Modula-2 타입과 범위 검사

경고: 이번 릴리즈에서, GDB는 아직 타입이나 범위 검사를 하지 않는다.

GDB는 다음 조건에서 두 Modula-2 변수 타입을 같은것으로 고려한다.:
- TYPEt1 = t2 문장으로 같게 선언된 타입이다.
- 가은 라인에 선언되어 있어야 한다.(주의: 이것은 GNU Modula-2 컴파일러에서만 참이며, 다른 컴파일러에서는 참이 아닐수도 있다.)
타입 검사가 enable된 상황이라면, 타입이 같지 않는 변수들을 합치는 시도는 에러이다.

범위 검사는 모든 수치적 연산, 대입, 배열 인덱스 바운드, 그리고 모든 내장 함수와 프로시져에서 행해진다.

범위 연산자 :: 그리고 .

Modula-2 범위 연산자(.)와 GDB 범위 연산자(::) 사이에는 약간의 미묘한 차이가 있다. 문법은 비슷하다:
```
module . id
scope :: id
```
scope는 모듈이나 프로시져의 이름이고, module는 모듈의 이름이고 id는 다른 모듈을 제외하고 프로그램 내 선언된 식별자이다.

:: 연산자는 식별자 id를 위해 scope에 의해 지정된 범위를 찾도록 GDB를 만든다. 만일 지정된 범위에서 발견되지 않는다면, GDB는 scope에 의해 지정된 것을 하나 닫고 모든 범위를 찾는다.

module가 지정한 정의 모듈에서 포함된 id에 의해 지정된 식별자를 위해 . 연산자는 GDB가 현재 범위를 검사하도록 만든다. 이 연산자에서, 만일 식별자 id가 정의된 모듈 module에 포함되지 않거나 id가 module에서 식별자가 아니라면 에러이다.

GDB 와 Modula-2

몇몇 GDB 명령어들은 Modula-2 프로그램을 디버깅할때 거의 사용되지 않는다. set print와 show print의 다섯 하위 명령어는 특히 C와 C++을 위해 적용된다: `vtbl', `demangle', `asm-demangle', `object', and `union' 처음 4개는 C++에 적용되며 마지막은 C union 타입에 적용되며 Modula-2에서는 직접 유사한 것은 없다.

다른 언어를 사용하는 동안 이용할수 있는 반면 @ 연산자(표현식 섹션을 참조해라)는 Modula-2에서는 유용하지 않다. 이것은 C와 C++에서는 할수 있지만 Modula-2에서는 만들수 없는 dynamic arrays의 디버깅을 피하기 위한 의도이다. 그러나, 주소가 정수형 상수에 의해 지정될수 있기 때문에, 생성자 `{type}adrexp'는 여전히 유용하다. (표현식 섹션을 참조해라.)

GDB 스크립트에서, Modula-2 비등호 연산자 #는 주석읠 시작으로써 해석된다. 대신에 <>를 사용해라.

심볼 테이블 검사하기

이 섹션에서 기술한 명령어들은 프로그램에 정의된 심볼(변수 이름, 함수 그리고 타입) 에 관한 것을 물어 볼수있도록 허용한다. 이 정보는 프로그램의 텍스트로 있으며 프로그램 실행중 바뀌지 않는다. GDB는 여러분이 GDB를 시작할때(파일 선택하기섹션을 참조 해라) 가리키는 파일이나, 또는 파일-관리 명령어들(파일들을 지정하기 위한 명령어들섹션을 참조해라) 중 하나로 이 정보를 여러분의 프로그램의 심볼 테이블 안에서 발견한다.

가끔, 여러분은 이상한 문자를 포함하는 심볼을 참조할 필요가 있으며, GDB는 보통 단어 구분자로써 처리한다. 가장 자주 있는 경우가 다른 소스 파일(프로그램 변수들섹션을 참조해라)의 정적 변수를 참조할때이다. 파일 이름들은 디버깅 심볼처럼 객체 파일로 기록되지만, GDB는 보통 3개의 단어 `foo' `.' `c'처럼 `foo.c'를 전형적인 파일 이름을 파싱한다. GDB가 단일 심볼로써 `foo.c'를 인식하도록 하기 위해, 단일 인용부호로 묶어라; 예를 들어,
```
p 'foo.c'::x
```
이것은 `foo.c'파일의 범위내에 잇는 x의 값을 보기 위해서이다.
info address symbol
symbol을 위한 데이터가 저장되어 있는 곳을 나타낸다. 레지스터 변수를 위해, 이것은 유지되는 레지스터가 어느것인지를 말해준다. 비-레지스터 지역 변수를 위해, 이것은 변수가 항상 저장되어 있는 스택-프레임 오프셋을 출력한다. `print &symbol'과는 대조적으로, 이것은 레지스터 변수 그리고 변수의 현재 순간의 정확한 주소를 출력하는 스택 지역 변수 모두에서 잘 작동하지는 않는다.
whatis exp
표션식 exp의 데이터 형을 출력한다. exp는 실제 평가되지는 않으며, 역효과 작동(대입 또는 함수 호출)은 일어나지 않는다. 표현식섹션을 참조해라.
whatis
변수 히스토리의 마지막 값 $의 데이터 형을 출력한다.
ptype typename
데이터 타입 typename의 특징을 출력한다. typename은 타입의 이름이거나 `class class-name', `struct struct-tag', `union union-tag' 또는 `enum enum-tag'의 형태를 가지고 있는 C 코드를 위한 것이다.
ptype exp

ptype
표현식 exp의 타입의 특징을 출력한다. ptype는 타입의 이름 대신에 세부적 특징을 출력함으로써 whatis와는 다르다. 예를 들어, 변수 선언에서:
```
struct complex {double real; double imag;} v;
```
두개의 명령어가 다음 출력을:
```
(gdb) whatis v
type = struct complex
(gdb) ptype v
type = struct complex {
    double real;
    double imag;
}
```
whatis처럼, 값 히스트로내 마지막 변수 $의 타입을 가리키는 변수 없이 ptype을 사용해라.
info types regexp

info types
regexp(여러분이 인자를 주지 않는다면, 프로그램의 모든 타입)과 매칭되는 모든 타입의 간단한 설명을 출력한다. 각 타입 이름은 그것이 완전한 라인임에도 불구하고 일치된다;`i type value'는 스트링 value를 포함하는 이름의 프로그램내 모든 타입에 관한 정보를 준다. 그러나 `i type ^value$'는 완전한 이름이 value인 타입에 관한 정보만 준다. 이 명령어는 두가지면에서 ptype와 다르다: 첫째, whatis처럼 그것은 세부적인 사항은 출력하지 않는다; 둘째, 그것은 타입이 정의된 모든 소스 파일을 나열한다.
info source
현재 소스 파일의 이름을 보여준다--즉, 현재 실행 시점을 포함하는 함수를 위한 소스 파일--그리고 그것이 쓰여진 언어도 보여준다.
info sources
디버깅 정보가 있는 프로그램내 모든 소스 파일의 이름을 보여주며, 두개의 리스트를 구성한다: 심볼이 이미 읽혀진 파일들과 필요할때 읽혀지는 심볼이 있는 파일들
info functions
이름과 정의된 모든 데이타 타입을 출력한다.
info functions regexp
이름과 정의된 모든 데이타 타입을 출력하며, 이름은 정규식 표현식 regexp과 일치되는 이름이다. 이와 같이, `info fun step'는 step를 포함하는 이름의 모든 ㅎ삼수를 발견한다.; `info fun ^step'는 step로 시작하는 이름의 모든것을 발견한다.
info variables
이름과 함수 밖에서 정의된 모든 변수의 데이터 타입을 출력한다.(즉, 지역 변수를 제외하고.)
info variables regexp
이름과 모든 변수들의 데이터 타입(지역 변수를 제외하고)을 출력한다.그리고 이름은 정규식 표현식 regexp과 일치하는 이름을 포함한다. 몇몇 시스템은 프로그램을 멈추고 재시작 하는것 없이 프로그램을 대체할수 있도록 각개 객체 파일들을 허용한다. 예를 들어, VxWorks에서 여러분은 버그가 있는 객체 파일을 재 컴파일하고 계속 돌릴수 있다. 만일 여러분이 이스스템중 하나에서 돌린다면, 여러분은 GDB가 자동적으로 링크된 모듈들을 위해 심볼을 다시 로딩할수 있도록 허용한다.

set symbol-reloading on
특정 이름을 가진 객체 파일을 다시 볼때 심볼 정의들을 상응하는 소스파일로 대체 한다.
set symbol-reloading off
같은 이름의 객체 파일들을 다시 만났을때 심볼 정의를 대체하지 않는다. 이것은 기본 값이다; 만일 여러분이 자동적으로 다시 링크된 모듈을 허용하는 시스템이 아니라면, 여러분은 symbol-reloading를 off로 놓아야 한다. 그렇지 않으면 GDB는 같은 이름을 가지는 몇몇 모듈(다른 디렉토리나 라이브러리)을 포함하는 커다란 프로그램을 링크할때 심볼들을 버리기때문이다.
show symbol-reloading
현재의 on나 off 설정을 보여준다.

maint print symbols filename

maint print psymbols filename

maint print msymbols filename
디버깅 심볼 데이타의 덤프를 파일 filename에 쓴다. 이들 명령어는 GDB 심볼-읽기 코드를 디버깅하기 위해 사용된다. 디버깅 데이터를 가지는 심볼들만 포함된다. 만일 여러분이 `maint print symbols'를 사용한다면, GDB는 모든 세부적 사항을 가지고 있는 모든 심볼들을 포함한다. 여러분은 이들이 있는 파일들을 찾기 위해 명령어 info sources를 사용할수 있다. 만일 여러분이 대신에 `maint print psymbols'를 사용한다면, 덤프는 GDB가 부분적으로 알고 있는 심볼에 관한 정보를 보여준다.--즉, GDB가 대충 훑어 읽은 파일들에 정의된 심볼들만, 그러나 완전히 읽지 않은 것은 제외하고. 마침내, `maint print msymbols'는 GDB가 몇몇 심볼들을 읽은 각 객체 파일을 요구하기 위해 최소 심볼 정보를 덤프한다. GDB가 심볼(symbol-file에서 기술)들을 읽는 방법을 위해서, 파일을 지정하기 위한 명령어들 섹션을 참조해라.
실행 변경

일단 여러분이 프로그램에서 에러를 발견했다고 생각하면, 여러분은 실행의 나머지에서 정확한 결과를 얻기 위해 명확히 에러를 수정하는 것을 원할것이다. 여러분은 프로그램의 실행을 바꾸기 위해 GDB의 특징을 사용하여, 실험에 의해 답을 발견할수 있다.

예를 들어, 여러분은 새로운 값을 변수나 메모리 위치에 저장할수 있다. 또, 프로그램에 시그널을 줄수 있고, 다른 주소에서 다시 시작하거나 심지어 함수에서 반환할수도 있다.

변수에 대입하기

변수의 값을 수정하기 위해, 대입 표현식을 평가한다. 표현식섹션을 참조해라. 예를 들어,
```
print x=4
```
값 4를 변수 x에 저장하고, 대입 표현식의 값을 출력한다. 지원되는 언어에서 연산자에 관한 정보를 더 원하면, 다른 언어에서 GDB 사용하기 섹션을 참조해라.

여러분이 대입 값 보는것에 흥미가 없다면, print 대신에 set를 사용해라. set는 표현식의 값을 출력하지 않고 값 히스토리( 값 히스토리 섹션을 참조해라)에 놓지 않는것을 제외하고 print와 같다. 표현식은 결과를 위해서만 평가된다.

만일 set명령어의 인자 스트링의 시작이 set 하위 명령어와 동일하게 나타난다면, set 대신에 set variable 명령어를 사용해라. 이 명령어는 하위 명령어가 없다는것을 제외하고 set와 동일하다. 예를 들어, 만일 여러분의 프로그램이 width 변수를 가지고 있다면, 여러분은 `set width=13'로 새 값을 설정한다면 에러가 발생를 만나게 된다. 왜냐하면, GDB는 set width명령어를 가지고 있기 때문이다.:
```
(gdb) whatis width
type = double
(gdb) p width
$4 = 13
(gdb) set width=47
Invalid syntax in expression.
```
물론 무효한 표현식은 `=47'이다. 프로그램 변수 width를 설정하기 위해, 다음과 같이 사용해라.
```
(gdb) set var width=47
```
GDB는 C보다 대입시 더 유연한 변환을 허용한다.; 여러분은 정수 값을 포인터 값이나 반대로 해서 자유스럽게 저장할수 있다. 그리고 여러분은 어떤 구조체도 같은 길이나 짧은 다른 구조체로 변환할수 있다.

값을 메모리내 임의의 곳에 저장하기 위해, 지정된 주소(표현식섹션을 참조해라)에 지정된 타입의 값을 만들기 위한 생성자 `{...}'를 사용해라. 예를 들어, {int} 0x83040는 정수로써 메모리 위치 0x83040를 가리킨다.
```
set {int}0x83040 = 4
```
이것은 값 4를 메모리 위치에 저장한다.

다른 주소에서 계속 하기

보통, 여러분이 프로그램을 계속할때, 여러분은 continue명령어를 가지고 멈춘 위치에서 계속 할수 있다. 여러분은 대신에 다음 명령어를 사용하여 여러분 자신이 선택한 주소에서 계속 할수 있다.

jump linespec
라인 linespec에서 시작을 다시 한다. 만일 거기에 breakpoint가 걸려 있다면 즉시 실행은 다시 멈춘다. linespec의 다른 형태의 특성을 보고자 하면, 소스 라인 출력하기 섹션을 참조해라. jump 명령어는 현재 스택 프레임이나 스택 포인터, 어떤 메모리 위치의 내용, 프로그램 카운터 외의 레지스터등을 바꾸지 않는다. 라인 linespec가 현재 실행시점에서 다른 함수에 있다면, 만일 두 함수가 다른 형태의 인자나 지역 변수를 예상한다면 결과는 알수 없다. 이런 이유때문에, jump 명령어는 만일 지정된 라인이 현재 실행함수내에 있는지 없는지 확신이 요구된다. 그러나, 만일 여러분이 프로그램의 기계어 코드에 익숙하다면 예측할수 없는 결과 조차도 예측할수 있다.
jump *address
주소 address에서 명령어 실행을 계속한다.

여러분은 새로운 값을 레지스터 $pc에 저장하여 jump와 같은 효과를 가질수 있다. 차이점은 이것이 프로그램이 돌아가는 프로그램을 시작하 지 않는다는 것이다; 여러분이 continue할때 돌아갈곳의 주소만 바꾼다. 예를 들어,
```
set $pc = 0x485
```
이것은 프로그램이 멈춘 주소보다 다음 continue룰 만들거나 주소 0x485에서 명령어 실행을 stepping하게 만든다. 계속과 단계 섹션을 참조해라.

jump 명령어를 사용하는 가장 일반적인 경우는 더 세부적으로 실행을 검사하기 위해 이미 실행된 프로그램의 일부분을 뒤--더 많은 breakpoint를 설정-- 로 가는것이다.

프로그램에 시그널 주기

signal signal
여러분의 프로그램이 중지한 곳에서 실행을 다시 시작한다. 그러나 즉시 signal 신호를 준다. signal 는 신호의 이름이나 번호이다. 예를 들어, 많은 시스템에서 signal 2 그리고 signal SIGINT 는 인터럽트 신호를 보내는 같은 방법이다. 선택적으로, 만일 signal 가 0이라면 신호를 주는것 없이 실행을 계속 한다. 이것은 여러분의 프로그램이 신호로 멈추었을때 그리고 continue 명령어로 다시 시작할때 신호를 볼 경우 유용하다.;`signal 0' 은 신호 없이 다시 시작하도록 한다. signal 는 명령어 실행후에 두번 RET 를 누를때 반복하지 않는다.

signal 명령어 호출은 쉘에서 kill 기능과 같지 않다. kill 로 신호를 보내는것은 GDB가 시그널 핸들링 테이블에 의존하여 신호가 해야할것을 결정하도록 야기 시킨다. (신호들 섹션을 참조해라). signal 명령어는 여러분의 프로그램에 직접 신호를 보낸다.

함수에서 반환하기

return

return expression
여러분은 return 명령어를 가지고 함수 호출의 실행을 취소할수 있다. 여러분이 expression 인자를 준다면, 해당 값은 함수의 반환값으로 사용된다.

여러분이 return 를 사용한다면, GDB 는 선택된 스택 프레임을 버린다(그리고 해당 프레임내에 있는 모든 프레임들). 여러분은 미리 반환된 프레임을 버리도록 만듬으로써 이것을 생각할수 있다. 여러분이 반환된 값을 지정하길 원한다면, return에 대한 인자로서 그 값을 주면된다.

이것은 선택된 스택 프레임 (프레임 선택하기 섹션을 참조해라.) 을 팝하며 그것 내부에 있는 다른 프레임들은 가장 깊숙히 남아 있는 프레임으로써 호출 함수에 남는다. 그 프레임은 선택되어 진다. 지정된 값은 함수의 반환 값들을 위해 사용되는 레지스터에 저장된다.

return 명령어는 실행을 다시 시작하지 않는다.; 이것은 함수가 단지 반환되었다면 존재하는 상태로 프로그램을 남긴다. 대조적으로, finish 명령어는 (계속과 단계 섹션을 참조해라.) 선택된 스택 프레임이 자연적으로 반환될때까지 실행을 계속 한다.

프로그램 함수들 호출하기

call expr
void 반환 값을 출력하는 것 없이 표현식 expr을 평가한다.

여러분은 만일 여러분이 void 반환값을 가지고 출력을 난잡하게 하지 않고 프로그램에서 함수 실행을 원한다면, print 명령어의 변종을 가지고 이것을 할수 있다. 만일 결과가 void가 아니라면, 출력되고 값 히스토리에 저장된다.

새로운 사용자-제어 변수, call_scratch_address는 GDB가 타겟에서 함수를 호출 할때 사용되기 위한 영역의 위치를 지정한다. 이것은 스택 영역에 놓는 일반적 방법은 명령어와 데이터 공간이 구분된 시스템에서는 작동하지 않기 때문에 필요하다.

프로그램 패치하기

기본적으로, GDB는 프로그램 실행 코드(또는 코어 파일)를 포함하는 파일을 연다. 이것은 기계 코드의 우연한 변경을 막는다; 그러나 이것은 또한 의도적인 프로그램 이진 파일 패치도 막는다.

만일 여러분이 이진 파일을 패치하길 원한다면, 여러분은 set write명령어로 할수 있다. 예를 들어, 여러분은 내부 디버그 플래그나 비상 복구를 만들기를 원할지도 있다.

set write on

set write off
만일 여러분이 `set write on'를 지정한다면, GDB는 읽기와 쓰기를 위해 실행 그리고 코어 파일을 연다.; 만일 여러분이 `set write off'(기본값)를 지정한다면, GDB는 읽기-전용으로 연다. 만일 여러분이 이미 파일을 로딩했다면, 여러분은 여러분의 새로운 설정이 효과를 보게 하기 위해 set write를 바꾼 후에, 다시 로드해야 한다.(exec-file나 core-file 명령어를 사용하여)
show write
실팽 파일과 코어 파일이 역시 읽기-쓰기로 열려져 있는지를 보여준다.

GDB 파일들

GDB는 심볼 테이블을 읽고 프로그램을 시작하기 위해서 디버깅 되는 프로그램의 이름을 알 필요가 있다. 전에 돌아간 코어 덤프를 디버깅하기 위해, 여러분은 GDB에게 코어 덤프 파일의 이름을 말해야 한다.

파일들을 지정하기 위한 명령어들

여러분은 실행파일 이름과 코어 덤프 파일 이름들을 지정하길 원할지도 모른다. 이것을 하기 위한 일반적 방법은 시작시에 GDB의 시작 인자를 사용하는 것이다. (GDB에 들어가고 나가기 섹션을 참조해라.)

가끔 GDB 세션동안에 다른 파일로 바꾸는게 필요하다. 또는 여러분은 GDB를 돌리고 사용할 파일 이름을 지정하는걸 잊을수도 있다. 이러한 상황에서 새로운 파일들을 지정하는 GDB 명령어들은 유용하다.

file filename
디버깅할 프로그램으로 filename을 사용해라. 심볼과 메모리의 내용을 읽는다. 이 명령어는 또한 여러분이 run명령어를 사용할때 프로그램을 실행한다. 만일 여러분이 디렉토리를 지정하지 않고 GDB 작업 디렉토리에서 파일이 발견되지 않는다면, shell이 프로그램을 돌릴기 위해 하는 것처럼 GDB는 탐색하기 위한 디렉토리의 리스트로써 환경 변수 PATH를 사용한다. 여러분은 path 명령어를 사용하여 GDB와 프로그램을 위해, 이 변수의 값을 바꿀수 있다. 메모리 대응 파일들을 가진 시스템에서, 보조 파일 `filename.syms'는 filename의 심볼 테이블 정보를 가진다. 만일 그렇다면, GDB는 더 빨리 시작하려고 `filename.syms'에서 심볼 테이블로 대응한다. 파일 옵션 `-mapped' 과 `-readnow'에 대한 설명을 참조해라. (명령어 라인에서 이용할수 있으며, 아래에서 설명한 것처럼 명령어 file, symbol-file, 또는 add-symbol-file 에서 이용할수 있다.)
file
인자 없이 file은 GDB가 실행 파일과 심볼 테이블에 대해 가지고 있는 것을 버리도록 만든다.
exec-file [ filename ]
돌리기 위한 프로그램(그러나 심볼 테이블이 아니다)을 filename에서 발견하도록 지정한다. 만일 프로그램의 위치가 필요하다면, GDB는 환경 변수 PATH를 탐색한다. filename을 생략하는 것은 실행 파일에서 정보를 버린다는 것을 의미한다.
symbol-file [ filename ]
파일 filename에서 심볼 테이블 정보를 읽는다. PATH는 필요하다면 탐색한다. 같은 파일에서 돌리기 위해 심볼 테이블과 프로그램을 가지고 file 명령어를 사용한다. 인자 없는 symbol-file은 프로그램 심볼 테이블의 GDB 정보를 깨끗히 한다. symbol-file 명령어는 GDB가 편리 변수, 값 히스토리 그리고 모든 breakpoint 그리고 자동 디스플레이 표현식의 내용을 잊도록 한다. 그것들은 내부 데이터 기록 심볼들과 데이터 타입에 대한 포인터를 포함하기 때문이며, GDB내 버려져야 하는 예전 심볼 테이블 데이터의 일부분이다. 만일 여러분이 한번 실행한후 다시 RET를 누른다면, symbol-file은 반복되지 않는다. GDB가 특정 환경을 위해 설정되었을때, GDB는 그 환경에서 만들어진 표준 포맷이 무엇이든지 디버깅 정보를 이해한다.;여러분은 GNU 컴파일러나 다른 컴파일러를 사용할지 모른다. 가장 좋은 결과는 GNU 컴파일러에서 얻어진다.; 예를 들어, gcc를 사용하면, 여러분은 최적화된 코드를 위한 디버깅 정보를 만들수 있다. 몇몇 종류의 객체 파일에서, symbol-file 명령어는 심볼 테이블을 읽지 않는다. 대신에, 명령어는 소스 파일과 존재하는 심볼을 찾기 위해 빠르게 심볼 테이블을 검사한다. 세부적인 것은 추후 읽는다. 두 단계 읽기전략의 목적은 빠르게 시작하도록 GDB를 만드는 것이다. 대부분의 경우를 위해, 특정 소스 파일을 위한 심볼 테이블 세부사항은 읽는 동안 가끔 멈추는것을 제외하고 눈에 보이지 않는다.(set verbose 명령어는 원한다면 중지들을 메세지로 바꿀수 있다. 경고 옵션과 메세지들 섹션을 참조해라.) 우리는 COFF에서는 아직 두 단계 전략을 수행하지 않았다. 심볼 테이블이 COFF형식으로 저장되었을때, symbol-file는 심볼 테이블 데이터를 읽는다.
symbol-file filename [ -readnow ] [ -mapped ]
file filename [ -readnow ] [ -mapped ]
만일 여러분이 GDB가 이용할수 있는 전체 심볼 테이블을 가지고 있다는것을 확인할길 원한다면, 여러분은 심볼 테이블 정보를 로딩하는 명령어에서 `-readnow' 옵션을 사용하여 심볼 테이블을 읽기 위해 2 단계 전략으로 겹지정할수 있다. 만일 메모리 대응 파일들이 mmap 시스템 콜을 통해 시스템에서 이용할수 있다면, 여러분은 프로그램을 위한 재 사용 파일로 쓰도록 GDB에게 야기 시키기 위해, 다른 옵션 `-mapped'를 사용할수 있다. GDB 디버깅 세션은 실행 프로그램에서 심볼 테이블을 읽는 시간을 보내기 보다는 이 보조 심볼 파일(만일 프로그램이 바뀌지 않는다면)에서 심볼 정보를 대응한다. `-mapped' 옵션은 `-mapped' 명령어 라인 옵션을 가지고 GDB를 시작하는 것과 같은 효과를 가진다. 여러분은 프로그램을 위해 심볼 정보 모두를 가지고 잇는 보조 심볼을 확실히 만들기 위해 두 옵션을 같이 사용할수 있다. myprog라 불리는 프로그램을 위한 보조 심볼 파일은 `myprog.syms'라 불린다. 일단 이 파일이 존재한다면, 여러분이 myprog를 디버깅할때 GDB는 그것을 사용하기 위해 항상 시도한다. `.syms' 파일은 여러분이 GDB를 돌리고 있는 호스트 머신에 의존한다. 그것은 내부 GDB 심볼 테이블의 정확한 이미지를 가지고 있다. 이것은 멀티 호스트 플랫폼을 통해 공유될수 없다.
core-file [ filename ]
"메모리 내용"으로 사용되기 위해 코어 덤프 파일의 관한 것을 지정한다. 전통적으로, 코어 파일은 코어 파일이 생성하는 프로세서 주소 공간의 일부분을 포함한다.; GDB는 다른 부분을 위해 실행 파일 자체를 접근할수 있다. 인자 없는 core-file 는 어떤 코어파일도 사용되지 않는다는 것을 지정한다. 프로그램이 GDB에서 실제로 돌아갈때 코어 파일은 무시된다는 점을 주의해라. 그래서, 만일 여러분이 프로그램을 돌리고 대신에 코어파일을 디버깅하길 워한다면, 여러분은 프로그램이 돌아가는 자식 프로세스를 죽여야 한다. 이것을 하기 위해, kill 명령어를 사용해라. (자식 프로세스 죽이기 섹션을 참조해라.)
load filename
원격 디버깅 기능을 GDB에 설정하는 것에 의존하여, load 명령어는 이용될수 있다. 그것이 존재한다면, 원격 시스템에서 디버깅을 이용하기 위해 filename을 만들수 있다.--예를 들어, 다운로드나 동적 링크. load는 add-symbol-file 명령어처럼, GDB내의 filename 심볼 테이블을 기록한다. 만일 GDB가 load 명령어를 가지고 있지 않다면, 실행은 에러 메세지 "You can't do that when your target is ..."를 갖는다. 파일은 실행시 지정되는 주소가 무엇이든지 로딩된다. 몇몇 객체 파일 형식을 위해, 여러분은 프로그램을 링크할때 로딩 주소를 지정할수 있다; a.out같은 다른 포맷을 위해, 객체 파일 형식은 고정 주소를 지정한다. VxWorks에서, load는 GDB내 심볼테이블을 추가할 뿐만 아니라 현재 타겟 시스템에서 동적으로 filename을 링크한다. Intel 960 board에 대한 Nindy 인터페이스에서, load는 GDB내 심볼을 추가할 뿐만 아니라 960에 filename을 다운로드한다. 여러분이 Hitachi SH, H8/300, 또는 H8/500 board에 원격 디버깅을 선택할때, load 명령어는 프로그램을 Hitachi board(GDB 와 Hitachi microprocessors 섹션을 참조해라.)에 다운 로드하고 호스트(file 명령어처럼)내 GDB를 위한 현재 실행 타겟으로써 그것을 연다. 이 명령어를 사용한 다음 다시 RET를 누른다면 load는 반복되지 않는다.
add-symbol-file filename address
add-symbol-file filename address [ -readnow ] [ -mapped ]
add-symbol-file 명령어는 파일 filename 에서 추가적인 심볼 테이블 정보를 읽는다. 여러분은 filename이 돌아가고 있는 프로그램에 동적으로 로딩될때 이 명령어를 사용할수 있다. address는 파일이 로딩되는 메모리 주소이어야 한다; GDB는 자체적으로 이것을 이해하지 못한다. 여러분은 표현식처럼 address를 지정할수 있다. 파일 filename의 심볼 테이블은 symbol-file 명령어로 읽는 심볼 테이블에 추가된다. 여러분은 여러번 ADD-SYMBOL-FILE 명령어를 사용할수 있다; 새로운 심볼 데이터는 예전것에 추가된다. 대신에 예전 심볼 데이터 모두를 버리기 위해, symbol-file 명령어를 사용해라. 여러분이 이 명령어를 사용한후 RET를 누른다면, add-symbol-file 는 반복되지 않는다. 여러분은 GDB가 filename을 위한 심볼 테이블 정보를 관리하는 방법을 바꾸기 위해 symbol-file 명령어 처럼, `-mapped' and `-readnow' 옵션을 사용할수 있다.
add-shared-symbol-file
add-shared-symbol-file 명령어는 Motorola 88k를 위한 OS Harris' CXUX에서만 사용될수 있다. GDB는 자동적으로 공유 라이브러리를 찾는다. 그러나 만일 GDB가 발견하지 못한다면, 여러분은 add-shared-symbol-file를 돌릴수 있다. 이 명령어는 인자를 가지지 않는다.
section
section 명령어는 실행 파일의 섹션 SECTIO의 기본 주소를 ADDR로 바꾼다. 만일 exec 파일이 섹션 주소를 포함하지 않거나 파일 자체에 지정된 주소가 잘못되었을때, 이 명령어는 사용될수 있다. 각 섹션은 따로 따로 바뀌어야 한다. "info files" 명령어는 모든 섹션과 주소를 나열한다.
info files
info target
info files 과 info target는 동의어이다; 두개는 실행 파일의 이름가 GDB가 현재 사용하는 코어 덤프 파일의 이름과 로딩된 심볼에서 파이을 포함한 현재 타겟을 출력한다. (디버깅 타겟 지정하기 섹션을 참조해라.) 명령어 help target는 현재 것보다 가능한 모든 타겟을 리스트한다.
파일을 지정하는 모든 명령어는 인자로써 절대적이고 상대적인 파일이름 모두를 허용한다. GB는 파일 이름을 절대 파일 이름으로 변환하며 그런 방식으로 파일이름을 기억한다. GDB는 SunOS, SVr4, Irix 5, 그리고 IBM RS/6000 공유 라이브러리를 지원한다. GDB는 여러분이 run 명령어를 사용할때나 코어 파일을 검사할때 자동적으로 공유 라이브러리에서 심볼 정의들을 로딩한다. (여러분이 run 명령어를 사용하기 전에, GDB는 공유 라이브러리내 함수에 대한 참조를 이해하지 못한다.--만일 여러분이 코어파일을 디버깅하지 않는다면.) info share info sharedlibrary 현재 로딩된 공유 라이브러리의 이름을 출력한다. sharedlibrary regex share regex Unix 정규식 표현과 일치하는 파일을 위해 공유 객체 라이브러리 심볼들을 로딩한다. 자동적으로 로딩된 파일들 처럼, 그것은 코어 파일이나 run을 타이핑 한뒤 프로그램에 의해 요구되는 공유 라이브러리들을 로딩한다. 만일 regex가 생략된다면, 프로그램이 요구하는 모든 공유 라이브러리들은 로딩된다. 심볼 파일들을 읽을때의 에러들 심볼 파일을 읽는 동안, GDB는 가끔 인식하지 못하는 심볼 타입이나 컴파일러 출력시 버그같은 문제를 만난다. 기본적으로, GDB는 그런 문제를 여러분에게 인식시키지 않는다. 왜냐하면 그것들은 상대적으로 일반적이며 컴파일러를 디버깅하는 사람들에게 우선적으로 흥미잇는 것들이기 때문이다. 만일 여러분이 좋지 않는 구조의 심볼 테이블에 관한 정보를 참조하는데 흥미가 있다면, 여러분은 문제가 얼마나 일어났는지에 관계없이, 그런 타입의 문제에 관한 메세지만을 출력하도록 GDB에게 요구할수 있다.; 또는 여러분은 set complaints (경고 옵션과 메세지들 섹션을 참조해라.). 명령어로 문제가 얼마나 많이 일어났는지를 보기 위해 더 많은 메세지를 출력하도록 GDB에게 요구할수 있다. 현재 출력된 메세지와, 그 의미는: inner block not inside outer block in symbol 심볼 정보는 심볼 범위가 시작하고 끝난 곳(함수나 문장 블럭의 시작과 같은)을 보여준다. 이 에러는 내부 범위 블럭은 외부 범위 블럭에 완전히 포함되지 않았다는 것을 가리킨다. GDB는 만일 외부 블럭과 같은 범위를 가지고 있다면 내부 블럭을 다루어서 문제를 해결한다. 에러 메세지에서, symbol은 만일 외부 블럭이 함수가 아니라면 "(don't know)" 처럼 보여진다. block at address out of order 심볼 범위 블럭을 위한 심볼 정보는 주소가 증가하는 순서로 일어나야 한다. 이 에러는 그렇지 않다는 것을 가리킨다. GDB는 이 문제를 해결하지 않았으며 심볼을 읽는 소스 파일내 심볼을 위치시키는데 문제를 가지고 있다. (여러분은 set verbose on를 지정하여 영향 받는 소스 파일이 무엇인지를 결정 할수 있다. 경고 옵션들과 메세지들 섹션을 참조해라.) bad block start address patched 심볼 범위 블럭을 위한 심볼 정보는 앞 소스 라인의 주소부도 작은 시작 주소를 가진다. 이것은 SunOS 4.1.1 (그리고 초기) C 컴파일러에서 발생하는것으로 알려져 있다. GDB는 전 소스 라인에서 시작하여 심볼 범위 블럭을 다루어 이 문제를 해결한다. bad string table offset in symbol n 심볼 수 n은 문자열 테이블의 크기보다 큰 문자열 테이블에 대한 포인터를 포함 한다. GDB는 이름 foo를 가지도록 심볼을 고려하여 이 문제를 해결하며, 만일 많은 심볼들이 이 이름으로 끝난다면 다른 문제를 야기할수도 있다. unknown symbol type 0xnn 심볼 정보는 GDB가 읽는 방법을 모르는 새로운 데이터 타입을 포함하고 있다. 0xnn 는 16진수로 잘못 이해하고 있는 심볼 타입이다. GDB는 이 심볼 정보를 무시하여 에러를 해결한다. 이것은 비록 그러한 심볼을 접근할수 없다할지라도, 여러분이 프로그램을 디버깅하는걸 허용한다. 만일 여러분이 그런 문제를 만나고 디버깅하는것처럼 느낀다면, 여러분은 gdb를 디버깅할수 있고, complain에 breakpont를 할수 있고, 함수 read_dbx_symtab 로 이동하여 심볼을 검사하기 위해 *bufp 를 검사할수 있다. stub type has NULL name GDB는 구조체나 클래스를 위해 완전한 정의를 발견할수 없다. const/volatile indicator missing (ok if using g++ v1.x), got... C++ 멤버 함수를 위한 심볼 정보가 컴파일러의 최근 버전이 출력해야 하는 몇몇 정보가 보이지 않는다. info mismatch between compiler and debugger GDB는 컴파일러에 의한 타입 지정 출력을 파싱할수 없다. 디버깅 타겟 지정하기 target 은 여러분의 프로그램이 돌아가는 실행 환경을 말한다. 자주, GDB는 여러분의 프로그램과 같은 호스트 환경에서 돌아간다; 그런 경우, 디버깅 타겟은 여러분이 file 이나 core 명령어를 사용할때 부수적 효과로써 지정된다. 여러분이 더 많은 유동성이 필요할때 -- 예를 들어, 물리적으로 각각 다른 호스트에서 GDB를 돌리거나 시리얼 포트를 통해 독립형 시스템을 제어하거나 TCP/IP접속을 통해 실시간 시스템을 제어할때 -- 여러분은 GDB를 위해 설정된 타겟 타입들중 하나를 지정하기 위해 target 명령어를 사용할수 있다. (타겟 관리를 위한 명령어들 섹션을 참조해라). 활동(Active) 타겟 여기에는 세 종류의 타겟이 있다: 프로세스들, 코어 파일들, 실행 파일들 GDB는 각 클래스에서 하나씩 세개의 활동 타겟들을 동시에 작동시킬수 있다. 이것은 여러분이 프로세스를 시작하고 코어 파일에서의 작동을 포기하지 않고 해당 활동을 조사하는것을 허용한다. 예를 들어, 여러분이 `gdb a.out' 를 실행한다면, 실행 파일 a.out 만이 활동 타겟이다. 여러분이 코어파일도 역시 명시한다면 --아마도 앞에서 크래쉬되고 코어 덤프된-- GDB는 두개의 활동 타겟을 가지게 되고 tandem에서 이것들을 사용하여 메모리 주소에 대한 요구를 만족시키기 위해 corefile 타겟에서 처음 찾고 그 다음에 실행 화일에서 찾는다. (전형적으로, 이들 타겟의 두 클래스들은 복잡하다. 왜냐하면 코어 파일들은 단지 프로그램의 읽기-쓰기 메모리--변수그리고 등등--와 머신의 상태만을 포함하지만 실행 화일은 프로그램의 텍스트와 초기화된 데이터만을 포함한다.) 여러분이 run 을 타입한다면, 여러분의 실행 화일 역시 활동 프로세스 타겟이 된다. 프로세스 타겟이 활성화되면 메모리 주소를 요구하는 모든 GDB 명령어들은 이 타겟을 참조한다; 활성화된 코어 파일이나 실행 파일 타겟에서 주소는 프로세스 타겟이 활 성화되는 동안은 모호해진다. 새로운 코어 파일이나 실행 타겟을 선택하기 위해 core-file 그리고 exec-file 명령어들을 사용해라. (파일을 지정하기 위한 명령어들 를 참조해라). 이미 돌아가고 있는 프로세스를 타겟으로 지정하기 위해 attach 명령어를 사용해라.(이미 돌아가고 있는 프로세스 디버깅 섹션을 참조해라). 타겟 관리를 위한 명령어들 target type parameters 타겟 머신이나 프로세스에 대한 GDB 호스트 환경을 접속한다. 타겟은 전형적으로 디버깅 기능을 가지기 위한 프로토콜이다. 여러분은 타겟 머신에 대한 타입이나 프로토콜을 지정하기 위해 type 인자를 사용해라. parameters 는 타겟 프로토콜에 의해 해석되지만, 전형적으로 접속된 디바이스 이름이나 호스트 이름들, 프로세스 숫자 그리고 보드 비율과 같은 것들을 포함한다. 여러분이 만일 명령어 실행후 다시 RET 를 한다면 target 명령어는 반복하지 않는다. help target 이용할수 있는 모든 타겟의 이름을 보여준다. 현재 선택된 타겟을 보여주기 위해, info target 이나 info files 를 사용해라. (파일을 지정하기 위한 명령어들 섹션을 참조해라.). help target name 타겟을 선택하기 위해 필요한 파라미터들을 포함하여 특정 타겟을 기술한다. set gnutarget args GDB는 여러분의 파일들을 읽기 위해 BFD 라이브러리를 사용한다. GDB는 그것이 executable, core, 또는 .o 파일인지를 알지만, 여러분은 set gnutarget 명령어를 가지고 파일 포맷을 지정할수 있다. 대부분의 target 명령어들과 달리, gnutarget 과 target 은 머신이 아닌 프로그램을 가리킨다. 경고: set gnutarget 으로 파일 포맷을 지정하기 위해, 여러분은 실제 BFD 이름을 알아야 한다. 파일을 지정하기 위한 명령어들 섹션을 참조해라. show gnutarget 읽기 위해 설정된 gnutarget 파일 포맷이 무엇인지를 보여주기 위해 show gnutarget 명령어를 사용해라. 여러분이 gnutarget 설정하지 않았다면, GDB는 자동적으로 각 파일을 위한 파일 포맷을 결정하며 show gnutarget 는 The current BDF target is "auto"를 보여준다. 여기에 몇몇 일반적 타겟이 있다.(GDB 설정에 의존하여 이용할수 있든지 없든지): target exec program 실행 파일. `target exec program' 는 `exec-file program'과 같다. target core filename 코어 덤프 파일. `target core filename' 는 `core-file filename'과 같다. target remote dev GDB-의존 프로토콜에서 원격 시리얼 타겟. dev 인자는 접속을 위해 사용한 시리얼 장치가 무엇인지를 지정한다.(e.g. `/dev/ttya'). 원격 디버깅 섹션을 참조해라. target remote 는 지금 load 명령어를 지원한다. 이것은 여러분이 타겟 시스템에 대한 스터브를 갖는 다른 방법을 가지고 있거나 여러분이 다운 로드로 떨어져 있지 않은 메모리 어떤곳에 놓을수 있을 경우만 유용하다. target sim CPU 모의 실험 장치. 가상 CPU 타겟 섹션을 참조해라. target udi keyword AMD UDI 프로토콜을 사용하는 원격 AMD29k 타겟. keyword 인자는 사용할 29k 보드나 모의 시험 장치가 무엇인지를 지정한다. AMD29K를 위한 UDI 프로토콜 섹션을 참조해라. target amd-eb dev speed PROG 시리얼 라인으로 연결된 PC 기반 원격 AMD EB29k 보드. target remote 처럼 dev 는 시리얼 장치이다.; speed 는 여러분이 라인 속도를 지정하도록 허용한다; 그리고 PROG 는 PC에 DOS가 나타나는 것처럼 디버깅을 위해 프로그램의 이름이다.is the AMD29K를 위한 EBMON 프로토콜. target hms dev 여러분의 호스트에 시리얼 라인으로 연결된 Hitachi SH, H8/300, 또는 H8/500 board. 시리얼 라인과 사용되는 통신 속도를 제어 하기 위한 특별한 명령어 device 그리고 speed를 사용해라. GDB 그리고 Hitachi 마이크로 프로세서 섹션을 참조해라. target nindy devicename Nindy Monitor에 의해 제어되는 Intel 960 보드. devicename 은 접속을 위해 사용되는 시리얼 장치의 이름이다. e.g. `/dev/ttya'. 원격 i960(Nindy)에서 GDB 섹션을 참조해라. target st2000 dev speed Tandem's STDBUG 프로토콜에서 돌아가는 Tandem ST2000 폰 스위치. dev 는 ST2000 시리얼 라인에 연결된 장치의 이름이다; speed 는 통신 라인 속도이다. 만일 GDB가 TCP나 Telnet을 사용하여 ST2000에 접속하기 위해 설정되었다면 인자들은 사용되지 않는다. Tandem ST2000에서 GDB 섹션을 참조해라. target vxworks machinename TCP/IP를 통해 연결된 VxWorks 시스템 machinename인자는 타겟 시스템의 머신 이름이거나 IP 주소이다. GDB 와 VxWorks 섹션을 참조해라. target bug dev MVME187 (m88k) 보드에서 돌아가는 BUG 모니터. target cpu32bug dev CPU32 (M68K) 보드에서 돌아가는 CPU32BUG 모니터. target op50n dev OKI HPPA 보드에서 돌아가는 OP50N 모니터. target w89k dev Winbond HPPA 보드에서 돌아가는 W89K 모니터. target est dev CPU32 (M68K) 보드에서 돌아가는 EST-300 ICE 모니터. target rom68k dev IDP 보드에서 돌아가는 ROM 68K 모니터. target array dev Tech LSI33K RAID 콘트롤러 보드 배열. target sparclite dev 적재를 위한 목적으로만 사용되는 Fujitsu sparclite 보드들. 여러분은 프로그램을 디버깅하기 위한 추가적인 명령어를 사용해야 한다. 예를 들어: GDB 표준 원격 프로토콜을 사용하는 target remote dev 다른 타겟들이 GDB의 다른 설정들을 이용한다; 여러분의 설정은 더 많은 타겟이거나 거의 없는 타겟들이다. 타겟의 바이트 순서 선택하기 여러분은 지금 타겟 시스템이 사용하는 바이트 순서를 선택할수 있다. set endian big 그리고 set endian little 명령어를 사용해라. 실행과 관련된 바이트 순서의 사용을 위해 GDB에 명령하기 위해서 set endian auto 명령어를 사용해라. 여러분은 show endian 명령어를 가지고 현재 설정된 바이트 순서를 볼수 있다. 경고: 현재, 단지 내장된 MIPS 설정만이 타겟의 바이트 순서의 동적 선택을 지원한다. 원격 디버깅 만일 여러분이 일반적인 방법으로 GDB를 돌릴수 없는 머신에서 돌아가는 프로그램을 디버깅 한다면, 원격 디버깅을 사용하는것은 유용하다. 예를 들어, 여러분이 OS 커널을 원격디버깅할때나 완전한 특징의 디버거를 돌릴기에 충분한 일반적인 OS를 가지고 있지 않은 작은 시스템에서 사용할수 있다. GDB 몇몇 설정들은 특별한 디버깅 타겟들과 함께 작동될수 있도록 시리얼이나 TCP/IP 인터페이스를 가지고 있다. 게다가, GDB는 여러분이 원격 스텁(stubs)--GDB와 통신하기 위해 원격 시스템에서 돌아가는 코드--을 쓴다면 사용할수 있는 일반적인 시리얼 프로토콜(GDB에 한정되어 있지만 다른 특정 타겟 시스템에는 한정되어 있지 않다)을 가지고 있다. 다른 원격 타겟들도 여러분의 GDB설정에서 이용할수 있다; 리스트를 보고자 하면 help target를 사용해라. GDB 원격 시리얼 프로토콜 다른 머신(디버깅 target 머신)에서 돌아가는 프로그램을 디버깅하기 위해, 여러분은 우선 프로그램을 위해 우선 준비해야할 필수사항들 모두를 재 배열해야 한다. 예를 들어, C 프로그램을 위해 여러분이 필요한것: C 런타임 환경을 설정하기 위한 시작 루틴:이것들은 `crt0'라는 이름을 가지고 있다. 시작 루틴은 하드웨어 벤더에 의해 제공되거나, 여러분 자신이 써야 한다. 여러분은 입출력을 관리하는 프로그램의 서부 루틴 호출을 지원하기 위해 C 서브 루틴 라이브러리가 필요할지 모른다. 여러분의 프로그램을 다른 머신을 위해 가지기 위한 방법--예를 들어, 다운 로드 프로그램. 이것들은 자주 하드웨어 제조업체에 의해 제공된다. 그러나 여러분은 하드웨어 문서를 가지고 여러분 자신이 써야 할지도 모른다. 다음 단계는 GDB가 돌아가고 있는 머신(host 머신)과 통신하기 위해 시리얼 포트를 사용하기 위해 조정하는 것이다. 일반적으로, 구조는 다음과 같이 보인다: On the host, GDB는 이 프로토콜 사용 방법을 이미 알고 있다; 그 밖의 모든 것이 설정되었을때, 여러분은 단순히 `target remote' 명령어를 사용할수 있다. (디버깅 타겟 지정하기 섹션을 참조해라.) On the target, 여러분은 여러분의 프로그램을 GDB 원격 시리얼 프로토콜을 수행하는 약간 특이한 목적의 서브루틴에 연결해야 한다. 이들 서브루틴을 포함하는 파일은 debugging stub라 불린다. 어떤 원격 타겟에서, 여러분은 stub를 여러분의 프로그램에 링크하는 대신 보조 프로그램 gdbserver를 사용할수 있다. 세부 사항을 위해, gdbserver 프로그램 사용하기 을 참조해라. debugging stub는 원격 머신의 아키텍쳐에 의존한다; 예를 들어, SPARC 보드의 프로그램을 디버깅 하기 위해 `sparc-stub.c'를 사용해라. 이들 작동 원격 stub는 GDB와 함께 배포된다: i386-stub.c Intel 386과 호환 아키텍쳐를 위해서. m68k-stub.c Motorola 680x0 아키텍쳐를 위해서. sh-stub.c Hitachi SH 아키텍쳐를 위해서. sparc-stub.c SPARC 아키텍쳐를 위해서. sparcl-stub.c Fujitsu SPARCLITE 아키텍쳐를 위해서. GDB 배포판내 `README'는 다른 최근 추가된 stub가 나열되어 있다. stub가 여러분을 위해 할수 있는 것 여러분의 아키텍쳐를 위한 debugging stub는 이들 세 서브 루틴을 제공한다.: set_debug_traps 이 루틴은 여러분의 프로그램을 멈추었을때 돌리기 위해 handle_exception을 조정한다. 여러분은 프로그램 시작근처에서 이 서브루틴을 호출해야 한다. handle_exception 이것은 커다란 일이지만, 여러분의 프로그램은 결코 그것을 명백히 호출해서는 안된다.--설정 코드는 trap이 발생했을때 돌리기 위해 handle_exception를 조정한다. handle_exception는 여러분의 프로그램이 실행(예를 들어, breakpoint) 도중 멈출때 제어를 가진다. 그리고 호스트 머신에 있는 GDB와 통신을 중개한다. 이것은 통신 프로토콜이 이행되진다.; handle_exception는 타겟 머신에서 GDB를 대신해서 행동한다.; 그것은 프로그램 상태에서 요약 정보를 보내면서 시작한다. 그리고 실행을 계속 하고, 여러분이 프로그램을 다시 시작하도록 만들기 위해 GDB 명령어를 실행할때까지 GDB가 필요할때 정보를 조사하고 전달한다.; 그런 면에서, handle_exception는 타겟 머신에서 자신의 코드에게 제어를 리턴한다. breakpoint 여러분의 프로그램이 breakpoint를 포함하도록 만들기 위해 보조 서브 루틴을 사용해라. 특정 상황에 의존하여, 이것은 GDB가 제어를 갖기 위한 유일한 방법이다. 예를 들어, 만일 여러분의 타겟 머신이 인터럽트 버튼을 정렬한다면, 여러분은 이것을 호출할 필요가 없다; 인터럽트 버튼을 누르는 것은 제어를 handle_exception에게 전달하는 것이다--결과적으로, GDB에게. 몇몇 머신에서, 시리얼 포트로 간단히 받는 문자들 또한 trap을 발생시킨다.; 또, 그런 상황에서 여러분은 자신의 프로그램에서 breakpoint를 호출할 필요가 없다.--간단히, 호스트에서 `target remote'을 돌리면 GDB 세션이 제어를 갖는다. 만일 이것들중 어떤 것도 사실이 아니라면, 또는 만일 여러분이 단순히 여러분의 디버깅 세션의 시작을 위해 미리 결정한 지점에서 여러분의 프로그램을 멈추도록 만들기를 원한다면, breakpoint를 호출해라. 여러분이 stub를 위해 해야 하는 것 GDB에서 debugging stub는 특별한 chip 아키텍쳐를 위해 설정된다. 그러나 이것들은 여러분의 디버깅 타겟 머신에 관한 정보를 가지고 있지 않다. 무엇보다도 여러분은 시리얼 통신과 통신 하는 방법을 stub에게 말해야 한다. int getDebugChar() 시리얼 통신에서 단일 문자를 읽기 위해 이 서브루틴을 써라. 여러분의 타겟 시스템에서 getchar와 같다; 다른 이름은 여러분이 원한다면 두개를 구별하도록 여러분에게 허용하기 위해서이다. void putDebugChar(int) 시리얼 통신에서 단일 문자를 쓰기 위해 이 서브루틴을 써라. 여러분의 타겟 시스템에서 putchar와 같다; 다른 이름은 여러분이 원한다면 두개를 구별하도록 여러분에게 허용하기 위해서이다. 만일 여러분이 작동중인 프로그램을 멈추도록 GDB를 원한다면, 여러분은 인터럽트-driven 드라이버를 사용할 필요가 있다. 그리고 ^C (`\003', control-C 문자)를 받을때 멈추도록 해야 한다. 그것은 GDB가 원격 시스템을 멈추도록 만들때 사용되는 문자이다. GDB를 적당한 상태로 돌리기 위해 디버깅 타겟에서 가져야 할것은 표준 stub를 바꾸는 것이다.; 빠르고 지저분한 방법은 breakpoint 명령어를 실행하는 것이다. ("더럽다"라는 말은 GDB가 SIGINT대신에 SIGTRAP를 보고한다는 것이다.) 여러분에게 필요한 다른 루틴들은: void exceptionHandler (int exception_number, void *exception_address) 예외 처리 테이블에 exception_address를 인스톨 하기위해 이 함수를 써라. 여러분은 이함수를 인스톨 해야 한다. 왜냐하면, stub는 여러분의 타겟 시스템의 예외 처리 테이블내에 무엇이 있는지 알 방법이 없기 때문이다. (예를 들어, 프로세서 테이블은 롬안에 있으며, RAM안에 테이블을 가리키는 엔트리를 포함한다.) exception_number는 바뀌어야 하는 예외 번호이다.; 그것의 의미는 아키텍쳐-의존적이다(예를 들어, 다란 넘버는 0으로 나누기, 잘못된 정렬 접근 등을 나타낸다.) 이 예외가 일어날때, 제어는 직접 exception_number에게 전달되어야 한다. 그리고 프로세서 상태(스택, 레지스터 등등)는 프로세스 예외가 있어났을때 처럼 되어야 한다. 그래서, 만일 여러분이 exception_address에 도달하도록 jump 명령어를 사용하길 원한다면, 서브 루틴으로 jump하지 말고 단순히 jump해야 한다. 386에서, exception_address는 핸들러가 작동하는 동안 인터럽트들이 마스크되도록 하기 위해 인터럽트 게이트로써 인스톨 되어야 한다. 게이트는 우선권 레벨 0이어야 한다. SPARK과 68k stub는 exceptionHandler 에서 도움 없이 그것들을 인터럽트 마스크를 할수 있다. void flush_i_cache() (스팍 그리고 sparclite만) 여러분의 타겟 머신에서 명령어 캐쉬를 비우기 위해 이 서브루틴을 써라. 만일 거기에 명령어 캐시가 없다면, 서브루틴은 no-op가 된다. 명령어 캐시를 가지고 있는 타겟 머신에서, GDB는 프로그램의 상태가 안정되도록 만들기 위해 이 함수를 필요로 한다. 여러분은 또한 이 라이브러리 루틴을 이용할수 있도록 활실히 만들어야 한다: void *memset(void *, int, int) 이 함수는 메모리 영역을 주어진 값으로 설정하는 표준 라이브러리 함수 memset이다. 만일 여러분이 libc.a의 무료 버전을 가지고 있다면, memset은 거기에 있다; 그렇지 않으면, 여러분은 하드웨어 제조업체서 얻거나 자신이 써야 한다. 만일 여러분이 GNU C 컴파일러를 사용하지 않는다면, 여러분은 다른 표준 라이브러리 서브 루틴이 필요할지 모른다.; 이것은 한 stub에서 다른것으로 바뀐다. 그러나 일반적으로 stub들은 gcc가 inline코드로 만드는 일반 라이브러리 서브루틴을 사용한다. Putting it all together 결론적으로, 여러분의 프로그램을 디버깅할 준비가 되어 있다면, 여러분은 다음 단계를 밟아야 한다. 여러분은 하위-레벨 루틴을 지원하도록 확실히 해야 한다.(여러분이 stub를 위해 해야하는 것 섹션을 참조해라.). getDebugChar, putDebugChar, flush_i_cache, memset, exceptionHandler. 프로그램의 맨위 근처에 이 라인들을 넣어라: set_debug_traps(); breakpoint(); 680x0 스터브에서만, 여러분은 exceptionHook라 불리는 변수를 제공해야 한다. 보통 여러분의 사용은: void (*exceptionHook)() = 0; 그러나 set_debug_traps를 호출하기에 앞서, 여러분은 프로그램내 함수에 포인터를 설정해라. 그러면 그 함수는 GDB가 trap(예를 들어, bus error)에서 멈춘후 계속될때 호출된다. exceptionHook가 가리키는 함수는 파라미터 하나로 호출된다; 예외 번호인 int. 컴파일과 링크를 함계: 여러분의 프로그램, 타겟 아키텍쳐를 위한 GDB debugging stub 그리고 지원 서부루틴. 타겟 머신과 GDB 호스트 사이에 시리얼 연결을 가지도록 해라. 그리고 호스트에 있는 시리얼 포트를 동일시 해라. 여러분의 프로그램을 타겟 머신(도는 제조업체에서 제공하는 것이든지)에서 다운로드 하고 시작해라. 원격 디버깅을 시작하기 위해, 호스트 머신에서 GDB를 돌려라. 그리고 원격 머신에서 돌아가는 플고그램을 실행 파일로써 지정해라. 이것은 여러분의 프로그램 심볼과 순 텍스트의 내용을 발견하는 방법을 GDB에게 말해준다. 그리고 target remote 명령어를 사용하여 통신을 설정해라. 인자는 타겟 머신과 통신하는 방법을 가리킨다.--직접 시리얼 라인에 연결하는 디바이스 이름이나 TCP 포트(보통 타겟 머신에 시리얼 라인을 가지고 있는 터미널 서버)를 통해. 예를 들어, `/dev/ttyb'라는 이름의 디바이스에 접속하는 시리얼 라인을 사용하기 위해: target remote /dev/ttyb TCP 연결을 사용하기 위해, host:port 형태의 인자를 사용해라. 예를 들어, manyfarms라는 이름의 터미널 서버의 포트 2828에 연결하기 위해: target remote manyfarms:2828 지금 여러분은 원격 시스템을 검사하고 데이터를 바꾸고 step과 continue를 위해 일반 명령어 모두를 사용할수 있다. 원격 프로그램을 다시 시작하고 디버깅을 멈추기 위해, detach 명령어를 사용해라. GDB가 원격 프로그램을 기다릴때는 언제나, 만일 여러분이 인터럽트 문자(C-C)를 타입한다면, GDB는 프로그램을 멈추게 한다. 이것은 원격 시스템이 사용하는 하드웨어와 시리얼 드라이버의 일부분에 의존하여 성공할지도 실패할지도 모른다. 만일 여러분이 다시 인터럽트 문자를 타이핑한다면, GDB는 이 프롬프트를 보여준다: Interrupted while waiting for the program. Give up (and stop debugging it)? (y or n) 만일 여러분이 y를 타이핑한다면, GDB는 원격 디버깅 세션을 끊는다. (만일 여러분이 나중에 다시 원한다고 결정한다면, 여러분은 다시 연결하기 위해 `target remote'를 사용할수 있다.) 만일 여러분이 n라고 타이핑한다면, GDB는 waiting상태로 다시 돌아간다. 통신 프로토콜 GDB에서 제공하는 stub 파일들은 타겟쪽의 통신 프로토콜을 사용한다. 그리고 GDB 쪽은 GDB 소스 파일 `remote.c'을 사용한다. 보통, 여러분은 통신하기 위해 이 서브루틴을 사용할수 있으며, 세부적인 것은 무시해라. (만일 여러분이 자신의 stub 파일을 사용한다면, 여러분은 여전히 세부적인 것은 무시할수 있다: 존재하는 stub파일들중 하나로 시작해라. `sparc-stub.c'는 잘 구성되었으며 읽기 쉽다) 그러나, 여러분은 프로토콜에 관해 알아야 할 필요가 있다.--예를 들어, 만일 타겟 머신에 하나의 시리얼 통신만 있다면, 여러분은 여러분의 프로그램이 특별한 무엇인가를 하길 원한지도 모른다. 모든 GDB 명령어들과 응답들은 checksum을 포함한 패킷으로 보내진다. 패킷은 문자 `$'로 시작하며 `#'로 끝나며 2개의 숫자 checksum이 뒤따른다. $packet info#checksum checksum은 packet info 문자들의 합 modulo 256으로써 계산된다. 호스트나 타겟 머신이 패킷을 받을때 예상되는 첫 응답은 승인이다.; 단일 분자, `+'(패킷을 올바르게 받았다는 것을 가리키기 위해)나 `-'(재전송을 요구하기 위해) 호스트(GDB)는 명령어를 보내고, 타겟(프로그램과 합쳐진 debugging stub)은 응답시 데이터를 보낸다. 타겟 또한 프로그램이 멈출때 데이터를 보낸다. 명령어 패킷은 명령어의 종류를 구별하는 첫 문자로 구별된다. 현재 지원되는 명령어 몇개가 있다.(`gdb/remote.c.'에 명령어의 완전한 리스트가 있다.) g CPU 레지스터의 값을 요구한다. G CPU 레지스터의 값을 설정한다. maddr,count addr 위치에서 count 바이트를 읽는다. Maddr,count:... addr 위치에 count 바이트를 쓴다. c caddr 현재 주소에서 실행을 다시 시작한다.(또는 제공된다면 addr에서) s saddr 현재 프로그램 카운터나 제공된다면 addr에서 한 명령어를 step하라. k 타겟 프로그램을 죽인다. ? 가장 최근의 신호를 보여준다. GDB 시그널 핸들링 명령어를 이용하도록 여러분을 허용 하기 위해, debugging stub의 함수중 하나는 POSIX 신호 값에 상응하는 것으로써 CPU trap을 알려준다. T GDB가 단일 stepping이나 조건적 breakpoint에 관한 결정을 할 필요가 있을때 원격 stub가 레지스터들에게 보내는걸 허용한다. 이것은 stepped된 각 명령어를 위해 전체 레지스터 집합을 가져오는 것을 줄여준다. GDB 원격 시리얼 프로토콜은 레지스터를 위해 캐시를 통해 쓰기를 수행한다. GDB는 타겟이 작동중이라면 레지스터를 다시 읽는다. 만일 여러분이 시리얼 연결시 문제점을 가지고 있다면, 여러분은 명령어 set remotedebug를 사용할수 있다. 이것은 다시 보낸 모든 패킷을 원격 머신에 시리얼 라인을 통해서 보고하도록 GDB를 만든다. 패킷 디버깅 정보는 GDB 표준 출력 스트림에 출력된다. set remotedebug off는 이것을 끄며 show remotedebug는 현재 상태를 보여준다. gdbserver 프로그램 사용 gdbserver은 Unix 같은 시스템을 위한 제어 프로그램이며 target remote를 통해 원격 GDB로 여러분의 프로그램에 연결하는것을 허용한다. --그러나 보통 debugging stub에 링킹 없이. gdbserver는 debugging stub를 완전히 대신하지 못한다. 왜냐하면 이것은 GDB 자체가 하는 것과 같은 OS 기능을 필요하기 때문이다. 사실, 원격 GDB에 연결 하기 위해 gdbserver를 돌릴수 있는 시스템은 로컬에서 GDB를 돌릴수 있다. 그럼에도 불구하고, gdbserver는 가끔 유용하다. 왜냐하면 GDB 자체보다 더 작은 프로그램이기 때문이다. GDB 모두를 포팅하는 것보다 쉽다. 그래서 여러분은 gdbserver를 사용하여 새로운 시스템에서 보다 빨리 시작할수 있다. 결론적으로, 만일 여러분이 real-time 시스템을 위한 코드를 개발한다면, 여러분은 real-time 작동과 관련된 교환은 예를 들어, 크로스-컴파일처럼 다른 시스템에서도 가능하게 개발하는 작업 만큼 편리하게 만든다는 것을 발견할 것이다. 여러분은 디버깅을 위한 비슷한 선택을 만들기 위해 gdbserver를 사용할수 있다. GDB와 gdbserver는 표준 GDB 원격 시리얼 프로토콜을 사용하여 시리얼 라인이나 TCP 연결을 통해 통신한다. 타겟 머신에서 여러분은 여러분이 디버깅하길 원하는 프로그램의 복사본을 가질 필요가 있다. gdbserver는 여러분의 프로그램 심볼 테이블을 필요로 하지 않는다. 그래서 여러분은 공간이 필요하다면 프로그램을 strip 할수 있다. 호스트 시스템의 GDB는 심볼 모두를 가지고 있다. 서버를 사용하기 위해, 여러분은 GDB와 통신하는 방법을 말해야 한다; 프로그램의 이름; 그리고 프로그램을 위한 인자들. 문법은: target> gdbserver comm program [ args ... ] comm는 디바이스 명(시리얼 라인을 사용하기 위해)이나 TCP 호스트 이름 그리고 포트 번호중 하나이다. 예를 들어, 인자 `foo.txt'를 가진 Emacs를 디버깅 하기 위해서 그리고 시리얼 포트 `/dev/com1'로 GDB와 통신하기 위해: target> gdbserver /dev/com1 emacs foo.txt gdbserver는 통신하기 위해 호스트 GDB를 위해 기다린다. 시리얼 라인 대신 TCP 연결을 사용하기 위해: target> gdbserver host:2345 emacs foo.txt 전 예와 유일한 차이점은 TCP를 통해 호스트 GDB와의 통신을 지정하는 첫 인자이다. `host:2345' 인자는 gdbserver는 머신 `host'에서 로콜 TCP 포트 2345에 TCP 연결을 기대한다는 의미이다. (현재, `host' 부분은 무시된다.) 여러분은 타겟 시스템에서 이미 사용되고 있는 TCP 포트가 아니라면 원하는 포트 번호 어떤것이든지 선택할수 있다. (예를 들어, 23는 telnet를 위해 예약되어 있다.) (3) 여러분은 호스트 GDB target remote 명령어로 같은 포트 번호를 사용해야 한다. GDB 호스트 머신에서, 여러분은 프로그램을 strip하지 않은 복사본이 필요하다. 왜냐하면, GDB는 심볼과 디버깅 정보가 필요 하기 때문이다. 보통때처럼 GDB 시작시, 처음 인자로써 프로그램의 지역 복사본의 이름을 사용해라. (만일 시리얼 라인이 9600 bps 외로 작동중이라면 여러분은 `--baud' 옵션이 필요 할지 모른다.) 그후, gdbserver로 통신을 설정하기 위해 target remote를 사용해라. 인자는 장치 이름이거나 host:PORT 형태의 TCP 포트 기술자이다. 예를 들어: (gdb) target remote /dev/ttyb 시리얼 라인 `/dev/ttyb'로 서버와 통신한다. 그리고 (gdb) target remote the-target:2345 호스트 `the-target'의 포트 2345와 TCP 연결을 통해 통신한다. TCP 연결을 위해, 여러분은 target remote 명령어를 사용하기 앞서 gdbserver를 시작해야 한다. 그렇지 않으면 여러분은 호스트 시스템에 의존하는 텍스트 에러를 가질 것이다. 그러나 보통은 `Connection refused'와 같은 것을 본다. gdbserve.nlm 프로그램 사용하기 gdbserve.nlm는 NetWare 시스템을 위한 제어 프로그램이며 target remote를 통하여 원격 GDB와 여러분의 프로그램을 연결하는 걸 허용한다. GDB와 gdbserve.nlm는 표준 GDB 원격 시리얼 프로토콜을 사용하여, 시리얼 라인을 통하여 통신한다. 타겟 머신에서, 여러분은 여러분이 디버깅하길 원하는 프로그램의 복사본을 가질 필요가 있다. gdbserve.nlm는 여러분 프로그램의 심볼 테이블이 필요하지 않는다. 그래서 여러분은 공간을 저장할 필요가 있다면 프로그램을 strip할수 있다. 호스트 시스템에서 GDB는 모든 심볼 핸들링을 한다. 서버를 사용하기 위해, 여러분은 GDB와 통신하기 위한 방법을 말할수 있다; 여러분의 프로그램 이름; 그리고 프로그램을 위한 인자들. 문법은: load gdbserve [ BOARD=board ] [ PORT=port ] [ BAUD=baud ] program [ args ... ] board와 port는 시리얼 라인을 지정한다; baud 는 연결에서 사용하는 baud 비율을 가리킨다. port와 node는 0이 기본이며 baud는 9600 bps가 기본 값이다. 예를 들어, 인자 `foo.txt'를 가진 Emacs를 디버깅 하기 위해 그리고 시리얼 포트 번호 2나 19200 bps 연결을 사용하는 보드 1로 GDB와 통신하기 위하여: load gdbserve BOARD=1 PORT=2 BAUD=19200 emacs foo.txt GDB 호스트 머신에서, 여러분은 프로그램을 strip하지 않은 복사본이 필요하다. 왜냐하면 GDB는 심볼과 디버깅 정보가 필요하기 때문이다. 보통때 처럼 GDB 시작시, 처음 인자로써 프로그램의 지역 복사본의 이름을 사용해라. (만일 시리얼 라인이 9600 bps외로 작동중이라면 여러분은 `--baud' 옵션이 필요할지 모른다.) 그후, gdbserve.nlm로 통신을 설정하기 위해 target remote를 사용해라. 인자는 장치 이름(`/dev/ttyb' 처럼, 시리얼 장치)이다. 예를 들어: (gdb) target remote /dev/ttyb 시리얼 라인 `/dev/ttyb'로 서버와 통신한다. 원격 i960 (Nindy)에서 GDB Nindy는 Intel 960 타겟 시스템을 위한 ROM Monitor 프로그램이다. GDB가 Nindy를 사용하는 원격 Intel 960을 제어하기 위해 설정되었을때, 여러분은 몇몇 방법으로 960에 접근하는 방법을 GDB에게 말할수 있다. 명령어 라인 옵션을 통해 시리얼 라인, Nindy 프로토콜, 통신 스피드를 지정한다; 시작시 프롬프트에 대한 응답으로; GDB 세션 동안 어떤 시점에서 target을 사용하여. 타겟을 관리하기 위한 명령어들 섹션을 참조해라. Nindy로 시작하기 만일 여러분이 어떤 명령어 라인 옵션들을 사용하지 않고 gdb를 시작한다면, 여러분은 일반적인 GDB 프롬프트에 도착하기 전에 사용할 시리얼 포트가 프롬프트 된다.: Attach /dev/ttyNN -- specify NN, or "quit" to quit: 접미사(`/dev/tty' 다음)가 사용하길 원하는 시리얼 포트를 식별하는 것은 무엇이든지 프롬프트로 응답한다. 만일 여러분이 선택한다면, 여러분은 빈 라인을 가지고 프롬프트에 응답하여 Nindy 연결이 없이도 시작할수 있다. 여러분이 이렇게 하든지 후에 Nindy에 연결하길 원한다면, target를 사용해라. (타겟을 관리하기 위한 명령어들 섹션을 참조해라.) Nindy를 위한 옵션들 이것들은 부착된 Nindy-960 보트를 가지고 GDB 세션을 시작하기 위한 시작 옵션들이다.: -r port 타겟 시스템 접속시 사용되기 위한 시리얼 인터페이스의 시리얼 포트 이름을 지정한다. 이 옵션은 보통 GDB가 Intel 960 타겟 아키텍쳐를 위해 설정될때 이용된다. 여러분은 다음처럼 port를 지정할지도 모른다; 완전한 경로 이름 (e.g. `-r /dev/ttya'), `/dev' (e.g. `-r ttya')에서 장치 이름, 또는 특정 tty (e.g. `-r a')를 위한 단일 접미사. -O (0이 아니라 대문자 "O".) GDB는 타겟 시스템에 접속하기 위해 "old" Nindy 모니터 프로토콜을 사용해야 한다는것을 지정한다. 이 옵션은 GDB가 Intel 960 타겟 아키텍쳐를 위해 설정될때 이용된다. 경고: 만일 여러분이 `-O'를 지정하였다면, 그러나 새로운 프로토콜을 예상하는 타겟 시스템에 접속을 시도하고, 연결이 실패하면 스피트가 잘못 맞추어져 있는것처럼 보인다. GDB는 몇몇 다른 라인 속도로 다시 연결하기 위해 시도한다. 여러분은 인터럽트로 이 처리를 그만둘수 있다. -brk GDB는 Nindy 타겟에 연결하기 전에 리셋시키기 위해 처음에 타겟 시스템에 BREAK 신호를 보내야만 한다. 경고: 많은 타겟 시스템은 이것을 요구하는 하드웨어를 가지고 있지 않다; 그것은 몇몇 보드에서만 작동한다. 표준 `-b' 옵션은 시리얼 포트에서 사용되는 라인 스피드를 제어한다. Nindy 리셋 명령어 reset Nindy 타겟을 위해, 이 명령어는 원격 타겟 시스템에 "break"를 보낸다; 이것은 타겟이 break가 탐지되었을때 하드 리셋(또는 다른 흥미로운 행동)을 이행할 회로를 가지고 있다면 유용하다. AMD29K을위한 UDI 프로토콜 GDB는 a29k 프로세서 패밀리를 디버깅하기 위해 AMD의 UDI("Universal Debugger Interface") 프로토콜를 지원한다. MiniMON 모니터에서 돌아가는 AMD 타겟을 가지고 이 설정을 사용하기 위해, 여러분은 지불하는 것 없이 AMD에서 이용할수 있는 프로그램 MONTIP가 필요하다. 여러분은 또한 AMD에서 이용할수 잇는 UDI-conformant a29k 시뮬레이터 프로그램 ISSTIP 를 가지고 GDB를 사용할수 있다. target udi keyword 원격 a29k 보드나 시뮬레이터를 위해 UDI 인터페이스를 선택한다. keyword는 AMD 설정 파일 `udi_soc'에 있는 엔트리이다. 이 파일은 a29k 타겟과 연결할때 사용되는 파라미터들을 지정하기 위한 keyword 엔트리를 포함 한다. `udi_soc' 파일이 여러분의 작업 디렉토리에 있지 않다면, 여러분은 경로에 환경 변수 `UDICONF'를 설정해야 한다. AMD29K를 위한 EBMON 프로토콜 AMD는 DOS 기반 모티너 프로그램 EBMON과 함께 PC에 맞는 a29k 개발 보드를 배포한다. 간단히 말해, 이 개발 시스템은 "EB29K"라 불린다. Unix 시스템에서 GDB를 이용하여 EB29K 보드에 있는 프로그램을 돌리기 위해서, 여러분은 우선 PC와 유닉스 시스템의 시리얼 포트를 연결해야 한다. 다음에서 우리는 여러분이 PC의 `COM1'포트와 유닉스 시스템의 `/dev/ttya'를 케이블을 연결했다고 가정한다. 통신 설정 다음 단계는 PC위의 DOS에서 다음을 하여 PC 포트를 설정하는 것이다.: C:\> MODE com1:9600,n,8,1,none 이 예제--MS DOS 4.0시스템에서--는 PC 포트를 9600 bps로, 패리티 없고, 8 데이터 비트, 1 stop 비트 그리고 "retry" 은 없는것으로 설정한다.; 여러분은 Unix 쪽 통신을 설정할때 통신 인자를 일치시켜야 한다. PC 제어를 시리얼 라인의 Unix 쪽에 주기위해, DOS 콘솔에서 다음을 타이핑해라.: C:\> CTTY com1 (후에, 만일 여러분이 DOS 콘솔로 제어를 가져오길 원한다면, 여러분은 명령어 CTTY con 를 사용할수 있다-- 그러나 여러분은 제어를 가지고 있는 장치로 보내야만 한다. 예제에서 `COM1' 시리얼 라인으로) Unix 호스트에서, PC와 통신하기 위해 tip나 cu 같은 통신 프로그램을 사용해라; 예로, cu -s 9600 -l /dev/ttya cu 옵션은 라인 스피드 그리고 사용할 시리얼 포트 지정하는걸 보여준다. 만일 여러분이 대신에 tip를 사용한다면, 여러분의 명령어 라인은 다음과 같다: tip -9600 /dev/ttya 여러분의 시스템은 우리가 tip에 대한 인자로 보여준 `/dev/ttya'와 다른 이름을 요구할지 모른다. 사용할 포트를 포함하여 통신 파라미터들은 "remote" 기술 파일에 있는tip 인자와 관련이 있다.--보통 시스템 테이블 `/etc/remote'. tip나 cu 연결 사용은, DOS 작업 디렉토리를 여러분의 a29k 프로그램의 복사본을 포함하는 디렉토리로 바꾼다. 그리고 PC 프로그램 EBMON를 시작한다.(EB29K 제어 프로그램은 AMD에 의해 여러분의 보드에 제공된다.) 여러분은 여러분은 다음과 비슷하게 EBMON의 초기화 출력을 보아야 한다. 그리고 EBMON 프롬프트 `#'로 끝난다. C:\> G: G:\> CD \usr\joe\work29k G:\USR\JOE\WORK29K> EBMON Am29000 PC Coprocessor Board Monitor, version 3.0-18 Copyright 1990 Advanced Micro Devices, Inc. Written by Gibbons and Associates, Inc. Enter '?' or 'H' for help PC Coprocessor Type = EB29K I/O Base = 0x208 Memory Base = 0xd0000 Data Memory Size = 2048KB Available I-RAM Range = 0x8000 to 0x1fffff Available D-RAM Range = 0x80002000 to 0x801fffff PageSize = 0x400 Register Stack Size = 0x800 Memory Stack Size = 0x1800 CPU PRL = 0x3 Am29027 Available = No Byte Write Available = Yes # ~. 그리고 cu나 tip 프로그램(EBMON 프롬프트에서 ~.를 타이핑하여 예제에서 행해졌다)을 종료한다. EBMON는 작동을 계속하며 GDB에 인계하기 위해 준비한다. 이 예제에서, 우리는 같은 29k 프로그램이 PC와 유닉스 시스템에 있다는 것을 확실히 하기 위해 가장 편리한 방법을 사용했다; PC/NFS 연결은 유닉스 호스트에 있는 파일 시스템 처럼 PC 위에 "drive G:"를 설정한다. 만일 여러분이 PC/NFS나 두 시스템을 연결할수 있는 것을 가지고 있지 않다면, 여러분은 유닉스 시스템에서 PC로 29k 프로그램을 가질수 있는 다른 방법을 결정해야 한다--아마도 플로피-디스크 전달; GDB는 시리얼 라인으로 다운로드를 하지 않는다. EB29K 크로스 디버깅 마지막으로, 유닉스 시스템에 있는 여러분의 29k의 이미지를 포함하는 디렉토리로 cd하고 GDB를 시작해라--여러분의 29k 프로그램의 이름을 인자로 지정하여: cd /usr/joe/work29k gdb myfoo 지금 여러분은 target 명령어를 사용할수 있다: target amd-eb /dev/ttya 9600 MYFOO 이 예제에서, 유리는 여러분의 프로그램은 `myfoo'라 불리는 파일에 있다고 가정한다. target amd-eb의 마지막 인자로 주어진 파일 이름은 DOS에 나타난 프로그램의 이름이어야 한다. 우리 예제에서, 이것은 단순히 MYFOO이지만, 일반적으로 그것은 DOS 경로를 포함할수 있으며 Unix 쪽에서 이름과 비슷하지 않는 전달 메카니즘에 의존한다. 이시점에서, 여러분은 여러분이 원하는 어떤 breakpoint를 설정할수 있다; 여러분이 29k 보드에서 돌아가는 프로그램을 보길 원한다면, GDB 명령어 run를 사용 해라. 원격 프로그램 디버깅을 멈추게 하기 위해, GDB detach 명령어를 사용해라. PC의 제어를 콘솔로 리턴하기 위해, GDB 세션을 마친후 EBMON에 연결하기 위해 다시 tip나 cu를 사용해라. 여러분은 EBMON를 끄기 위해 명령어 q를 타입할수 있다. 그리고 제어를 DOS 명령어 라인 인터프리터에 리턴한다. 주 DOS 콘솔에 명령어 입력을 반환하기 위해 CTTY con를 타이핑해라. 그리고 tip나 cu를 마치기 위해 ~.를 타이핑해라. 원격 로그 target amd-eb 명령어는 현재 작업 디렉토리에 연결시 문제점들을 디버깅 하는데 돕기 위해 파일 `eb.log'를 만든다. `eb.log'는 보내는 명령어에 대한 에코를 포함하여 EBMON에서 나오는 모든것을 다 기록한다. 다른 윈도우 창에서 이파일에 `tail -f'를 돌리면 EBMON에서 발생하는 문제점이나 PC쪽 연결에서 예상치 못한 이벤트를 이해하는데 도와준다. Tandem ST2000에서 GDB ST2000을 호스트 시스템에 연결하기 위해서는 제조업체의 메뉴얼을 참조해라. 일단 ST2000을 물리적으로 연결하고, 여러분은 작동할수 있다: To connect your ST2000 to the host system, see the manufacturer's manual. Once the ST2000 is physically attached, you can run: target st2000 dev speed 디버깅 환경으로 설정한다. dev는 `/dev/ttya'처럼, 보통 시리얼 라인을 통해 ST2000에 연결하는 시리얼 장치의 이름이다. 여러분은 문접 hostname:portnumber을 사용하여 TCP 연결(예를 들어, 시리얼 라인을 터미널 concentrator을 통해 연결하기 위해)로써 dev를 지정할수 있다. load와 attach 명령어는 이 타겟에서 정의되어 있지 않다; 여러분은 프로그램을 표준 작동 처럼 ST2000에 로드해야 한다. GDB는 분리해서 디버깅 정보(심볼)와 호스트 컴퓨터에서 이용할수 있는 프로그램의 디버깅 정보를 읽는다. 이들 보조 GDB 명령어는 ST2000 환경에서 여러분을 도와준다.: st2000 command command를 STDBUG 모니터에 보낸다. 이용할수 명령어를 위해 제조업체의 매뉴얼을 참조해라. connect STDBUG 명령어 모니터에 제어 터미널을 연결해라. 여러분이 STDBUG로 대화식을 할때, 여러분이 GDB 명령어 프롬프트로 가기 위해 두 연속된 문자들중 하나를 타이핑해라: RET~.(Return, tilde, periold)나 RET~C-d(Return, tiilde, control-D) GDB 와 VxWorks GDB는 Unix 호스트에서 네트웍상에서 돌아가고 있는 VxWorks 타겟의 태스크를 spawn 시키고 디버깅시키는거를 가능하게 해준다. VxWorks 쉘에서 spawn되어 이미 작동중인 태스크도 디버깅할수 있다. GDB는 Unix 호스트와 VxWorks 타겟에서 돌아가는 코드를 사용한다. 프로그램 gdb는 유닉스 호스트에서 설치되고 실행된다. (호스트에서 디버깅 프로그램을 위해 GDB와 구별되어 vxgdb라는 이름으로 설치된다.) VxWorks-timeout args 모든 VxWorks 기반 타겟은 vxworks-timeout 옵션을 지원한다. 이 옵션은 유저에 의해 설정되며 args는 GDB가 rpc 응답을 기다리는 초를 나타낸다. 만일 여러분의 VxWorks 타겟이 느린 소프트웨어 시뮬레이터나 thin 네트웍 라인의 반대쪽이라면 여러분은 이것을 사용할수 있다. VxWorks에 연결시 다음 정보가 매뉴얼에 있었다; VxWorks의 새로운 릴리즈는 수정된 매뉴얼을 사용한다. To use GDB with VxWorks, you must rebuild your VxWorks kernel to include the remote debugging interface routines in the VxWorks library `rdb.a'. To do this, define INCLUDE_RDB in the VxWorks configuration file `configAll.h' and rebuild your VxWorks kernel. The resulting kernel contains `rdb.a', and spawns the source debugging task tRdbTask when VxWorks is booted. For more information on configuring and remaking VxWorks, see the manufacturer's manual. 일단 여러분은 VxWorks 시스템 이미지에 `rdb.a'를 포함하고 GDB를 발견하기 위해 여러분의 유닉스 실행 경로를 설정하면, 여러분은 GDB를 돌릴 준비가 된다. 여러분의 Unix 호스트에서, gdb를 돌려라.(또는 인스톨에 의존하여, vxgdb) GDB는 프롬프트를 보여준다: (vxgdb) VxWorks에 연결하기 GDB 명령어 target는 네트웍에서 VxWorks에 연결하는 걸 허용한다. 호스트 이름이 "tt"인 타겟에 연결하기 위해, 타입핑해라: (vxgdb) target vxworks tt GDB는 다음과 같은 메세지를 보여준다: Attaching remote machine across net... Connected to tt. GDB는 부트된후, VxWorks 타겟에 로드된 객체 모듈의 심볼 테이블을 읽는다. GDB는 명령어 찾기 경로에 리스트된 디렉토리 검색으로 이들 파일을 찾는다. (프로그램 환경 섹션을 참조해라); 만일 객체 파일을 찾는걸 실패한다면, 다음과 같은 메세지가 출력된다: prog.o: No such file or directory. 이런 일이 일어 났을때, 적당한 디렉토리를 GDB 명령어 path로 검색 경로에 추가해라. 그리고 다시 target 명령어를 실행해라. VxWorks 다운 로드 만일 여러분이 VxWorks 타겟에 연결하고 아직 로드되지 않은 객체를 디버깅 하길 원한다면, 여러분은 GDB load 명령어를 사용할수 있다. load 명령어에 대한 인자로써 주어지는 객체 파일은 실제로 2번 열린다: 코드를 다운 로드 하기 위해 VxWorks 타겟에 의해서 한번, 그리고 심볼 테이블을 읽기 위해 GDB에 의해서. 이것은 만일 현재 작업 디렉토리가 두 시스템 간에 다르다면 문제를 야기할수 있따. 만일 두 시스템이 같은 파일시스템으로 마운트된 NFS를 가지고 있다면, 여러분은 절대 경로를 사용하여 이들 문제를 피할수 있다. 다른 방법으로, 객체 파일이 있는 디렉토리와 경로 없이 이름으로 파일을 참조하여 작업 디렉토리를 설정하는 것도 간단하다. 예를 들어, 프로그램 `prog.o'은 VxWorks내 `vxpath/vw/demo/rdb'에 있고 호스트에서는 `hostpath/vw/demo/rdb'에 있다고 하자. 이 프로그램을 로드 하기위해, VxWorks에서는 이렇게 타이핑해라: -> cd "vxpath/vw/demo/rdb" v 그리고, GDB에서는: (vxgdb) cd hostpath/vw/demo/rdb (vxgdb) load prog.o GDB는 다음과 비슷하게 반응을 출력한다: Reading symbol data from wherever/vw/demo/rdb/prog.o... done. 여러분은 소스 파일에 해당하는 것을 고치고 재 컴파일 한후 객체 모듈을 다시 로드하기 위해 load 명령어를 사용할수 있다. 이것은 GDB가 현재 정의된 모든 breakpoint, 자동 디스플레이, 편리 변수들, 그리고 값 히스토리를 지우도록 GDB를 만든다. (이것은 타겟 시스템의 심볼 테이블을 참조하는 디버거 데이터 구조체들의 완전성을 보존하기 위해 필요하다.) 실행되는 태스크들 여러분은 다음과 같은 attach 명령어를 사용하여 존재하는 태스크를 연결할수 있다: (vxgdb) attach task task는 VxWorks 16진수 태스트 ID이다. 태스크는 여러분이 GDB에 연결할때 돌리거나 일시 중지시킬수 있다. 작동중인 태스크는 연결시키는 타임에서 중지된다. GDB와 Sparclet GDB는 Sparclet 타겟에서 돌아가는 태스크들을 유닉스 호스트에서 디버깅 할수 있다. GDB는 Unix 호스트와 Sparclet 타겟 모두에서 돌아가는 코드를 사용한다. 프로그램 gdb는 Unix 호스트에 설치하고 실행된다. timeout args GDB는 remotetimeout 옵션을 지원한다. 이 옵션은 유저에 의해 설정되며 args는 응답을 위해 GDB가 기다려야 하는 초를 나타낸다. 디버깅을 위해 컴파일할때, 디버깅 정보를 갖기 위해 "-g" 옵션을 포함해라. 그리고 여러분이 타겟에 로드하길 원하는 곳에 프로그램을 재배치 시키기 위해 "-Ttext" 옵션을 포함해라. 여러분은 또한 섹션의 크기를 줄이기 위해 "-n"이나 "-N"을 더하길 원할지도 모른다. sparclet-aout-gcc prog.c -Ttext 0x12010000 -g -o prog -N 여러분은 주소가 여러분이 의도한 곳인지를 검사하기 위해 objdump를 사용할수 있다. sparclet-aout-objdump --headers --syms prog 일단 여러분이 GDB를 발견하기 위해 Unix 실행 탐색 경로를 설정하면, 여러분인 GDB를 돌릴 준비가 된 것이다. 여러분의 Unix 호스트에서, gdb를 돌린다. (또는 설치시 의존하여, sparclet-aout-gdb) GDB는 프롬프트를 보여준다: (gdbslet) 디버깅을 위해 파일 설정하기 GDB 명령어 file는 여러분이 디버깅할 프로그램을 선택하도록 한다. (gdbslet) file prog 그리고 GDB는 `prog'의 심볼 테이블을 읽는 걸 시도한다. GDB는 명령어 탐색 경로에 리스트된 디렉토리에서 파일을 찾는다. 만일 파일이 디버깅 정보(옵션 "-g")를 가지고 컴파일 되었다면, 소스 파일은 역시 검색된다. GDB는 디렉토리 탐색 경로에 나열된 디렉토리를 탐색하여 소스 파일들을 찾을수 있다. (프로그램 환경 섹션을 참조해라.) 만일 파일을 찾는걸 실패한다면, 다음과 같은 메세지를 출력한다: prog: No such file or directory. 이런일이 일어날때, 알맞는 디렉토리를 GDB 명령어 path로 탐색 경로에 추가시키고 dir을 하고 다시 target 명령어를 실행해라. Sparclet에 연결하기 GDB 명령어 target는 여러분이 Sparclet 타겟에 연결하도록 한다. 시리얼 포트 "ttya"로 타겟과 연결하기 위해: (gdbslet) target sparclet /dev/ttya Remote target sparclet connected to /dev/ttya main () at ../prog.c:3 GDB는 다음과 같은 메세지를 보여준다: Connected to ttya. Sparclet 다운 로드 일단 Sparclet 타겟에 연결하면, 여러분은 호스트에서 타겟으로 파일을 다운 로드하는 GDB load 명령어를 사용할수 있다. 파일이름과 로드 오프셋은 load 명령어에 대한 인자로써 주어진다. 파일 포맷이 aout이기 때문에, 프로그램은 시작 주소에 로드되어야 한다. 여러분은 이 값을 찾기 위해 objdump를 사용할수 있다. 로드 오프셋은 각 파일 섹션의 VMA(virtual memory address)에 더해진 오프셋이다. 예를 들어, 만일 프로그램 `prog'를 텍스트 주소 0x1201000에, 데이터를 0x12010160에, bss를 0x12010170에 링크한다면: (gdbslet) load prog 0x12010000 Loading section .text, size 0xdb0 vma 0x12010000 코드가 프로그램이 링크된 곳과 다른 주소에 로드된다면, 여러분은 심볼 테이블을 맵 할수 있는 곳을 GDB에게 말하기 위해 section과 add-symbol-file 명령어를 사용할지도 모른다. Running 그리고 디버깅 여러분은 GDB 실행 제어 명령어 b, step, run 등등을 사용하여 태스크를 디버깅할수 있다. 명령어의 리스트를 위해 GDB 매뉴얼을 참조해라. (gdbslet) b main Breakpoint 1 at 0x12010000: file prog.c, line 3. (gdbslet) run Starting program: prog Breakpoint 1, main (argc=1, argv=0xeffff21c) at prog.c:3 3 char *symarg = 0; (gdbslet) step 4 char *execarg = "hello!"; (gdbslet) GDB 와 Hitachi 마이크로 프로세서들 GDB는 여러분의 Hitachi SH, H8/300 또는 H8/500과 애기할때 다음것들을 알아야 한다: `target hms' 사용을 위해 여러분이 원하는것, Hitachi 마이크로 프로세서를 위한 원격 디버깅 인터페이스, 또는 `target e7000', Hitachi SH 그리고 Hitachi 300H를 위한 내장 회로 에뮬레이터.(`target hms'는 GDB가 Hitachi SH, H8/300, H8/500을 위해 설정될때 기본값이다.) Hitachi Board에 호스트를 연결할 시리얼 장치(호스트에서 이용할수 있는 첫 시리얼 장치가 기본값이다.) 시리얼 장치에서 사용할 스피드 Hitachi 보드에 접속하기 만일 여러분이 시리얼 장치를 설정할 필요가 있다면 gdb 명령어 `device port' 를 사용해라. 기본적인 port는 호스트에서 이용가능한 포트이다. 이것은 Unix 호스트에서 필요하며 `/dev/ttya' 같은 것을 말한다. gdb는 통신 스피드를 설정하기 위한 명령어를 가지고 있다:`speed bps'. 이 명령어는 유닉스 호스트에서만 사용된다; DOS 호스트에서, DOS mode 명령어를 가지고 GDB 밖에서 라인 스피드를 설정해라. (예를 들어, 9600 bps 연결을 위해 `mode com2:9600,n,8,1,p') `device' 명령어와 `speed' 명령어는 여러분이 Hitachi 마이크로 프로세서 프로그램을 디버깅하기 위해 유닉스 호스트를 사용할때 이용할수 있다. 만일 여러분이 DOS 호스트를 사용한다면, GDB는 PC 시리얼 포트를 사용하여 개발 보드와 통신하기 위해 asynctsr라 불리는 보조 terminate-and-stay-resident 프로그램에 의존한다. E7000 in-circuit emulator에서 사용하기 여러분은 Hitachi SH나 H8/300H에서 코드를 개발하기 위해 E7000 in-circuit emulator를 사용할수 있다. GDB를 E7000에 연결하기 위한 `target e7000' 명령어 형태중 하나를 사용해라. target e7000 port speed 만일 여러분의 E7000이 시리얼 포트에 연결된다면 이 형태를 사용해라. port 인자는 사용할 시리얼 포트를 가리킨다.(예를 들어, `com2'). 세번째 인자는 초당 bits로 라인 스피드이다.(예를 들어, `9600') target e7000 hostname 만일 E7000이 TCP/IP 네트웍에 있는 호스트에 설치되었다면, 여러분은 호스트 이름을 지정할수 있다; GDB는 연결하기 위해 telnet를 사용한다. Hitachi micros를 위한 특별한 GDB 명령어들 몇몇 GDB 명령어드들은 H8/300 이나 H8/500 설정에서만 이용할수 있다.: set machine h8300 set machine h8300h `set machine'으로 H8/300 아키텍쳐의 두 변종 중 하나를 위해 GDB를 조건화 할수 있다. 여러분은 결과적으로 어떤 종류인지를 검사하기 위해 `show machine'를 사용할수 있다. set memory mod show memory 여러분은 `set memory'를 사용하여 H8/500 메모리 모델(mod)을 지정한다.; 메모리 모델이 효과가 있는지를 `show memory'로 검사해라. mod가 받아들일수 있는 값은 small, big, medium, and compact이다. GDB 와 원격 MIPS 보드들 GDB는 시리얼 라인에 연결된 MIPS 보드와 통신하기 위해 MIPS 원격 디버깅 프로토콜을 사용할수 있다. 이것은 여러분이 `--target=mips-idt-ecoff'로 GDB를 설정할때 이용한다. 타겟 보드에 연결을 지정하기 위해 GDB 명령어들을 사용한다: target mips port 보드에서 프로그램을 돌리기 위해, 인자로써 프로그램의 이름을 주고 gdb를 시작해라. 보드에 연결하기 위해, 명령어 `target mips port'를 사용해라. port는 보드에 연결하는 시리얼 포트의 이름이다. 만일 프로그램이 보드에 다운로드되어 있지 않다면, 여러분은 다운 로드를 위해 load 명령어를 사용해라. 여러분은 일반적인 GDB 명령어 모두를 사용할수 있다. 예를 들어, 이런순서로 시리얼 포트를 통해 타겟 보드에 연결되며 로드 되고 디버거를 통해서 prog라 불리는 프로그램을 실행한다: host$ gdb prog GDB is free software and ... (gdb) target mips /dev/ttyb (gdb) load prog (gdb) run target mips hostname:portnumber 몇몇 GDB 호스트 설정에서, 여러분은 시리얼 포트 대신에 문법 `hostname:portnumber'를 사용하여 TCP 연결(보통, 터미널 문자로 관리되는 시리얼 라인을 위해)을 지정할수 있다. target pmon port target ddb port target lsi port GDB는 또한 MIPS 타겟을 위해 특정 명령어들을 지원한다: set processor args show processor 여러분이 processor-type-specific registers를 접근하길 원할때 MIPS 프로세서의 타입을 설정하기 위해 set processor 명령어를 사용해라. 예를 들어, set processor r3041는 3401칩에 알맞는 CPO 레지스터를 사용하도록 GDB에게 말한다. GDB가 사용하고 있는 MIPS 프로세서가 무엇인지를 보기 위해 show processor 명령어를 사용해라. GDB가 사용하고 있는 레지스토를 보기 위해서는 info reg 명령어를 사용해라. set mipsfpu double set mipsfpu single set mipsfpu none show mipsfpu 만일 여러분의 타겟 보드가 MIPS 부동 소수점 프로세서를 지원하지 않는다면, 여러분은 명령어 `set mipsfpu none'를 사용해야 한다.(만일 여러분이 이것이 필요하다면, 여러분은 .gdbinit 파일에 명령어를 놓길 원할지 모른다.) 이것은 GDB가 부동 소수점 값을 반환하는 함수의 리턴값을 발견하는 방법을 말해준다. 이것은 또한 보드의 함수를 호출할때 부동 소수점 레지스터를 저장하는 것을 허용한다. 만일 여러분이 single precision 부동 소수점 레지스터를 지원하는 부동 소수점 coprocessor를 사용한다면, 명령어 `set mipsfpu single'를 사용해라. 기본 double precision 부동 소수점 coprocessor는 `set mipsfpu double'를 사용하여 선택할수 있다. 전 버전에서, 유일한 선택은 double precision 또는 부동 수서점 이 없는 것이었다. 그래서 `set mipsfpu on'는 double precision을 선택했으며 `set mipsfpu off'는 부동 소수점이 없는 것으로 선택했다. 보통처럼, 여러분은 `show mipsfpu'로 mipsfpu 변수에 관해 질의할수 있다. set remotedebug n show remotedebug 여러분은 remotedebug 변수를 설정하여 보드와의 통신에 관한 디버깅 정보를 볼수 있다. 만일 여러분이 `set remotedebug 1'를 사용하여 1로 설정한다면, 모든 문자는 출력된다. 여러분은 명령어 `show remotedebug'로 어떤때든지 현재 값을 검사할수 있다. set timeout seconds set retransmit-timeout seconds show timeout show retransmit-timeout 여러분은 MIPS 원격 프로토콜에서 set timeout seconds 명령어를 사용하여 패킷을 기다리는 동안 사용하는 타임 아웃을 제어할수 있다. 기본 값은 5초이다. 비슷하게, 여러분은 set retransmit-timeout seconds 명령어를 사용하여 패킷의 승인을 기다리는 동안 사용되는 타임아웃을 제어할수 있다. 기본값은 3초이다. 여러분은 show timeout과 show retransmit-timeout로 두 값을 검사할수 있다.(이들 명령어는 GDB가 `--target=mips-idt-ecoff'로 설정할때 만 이용할수 있다.) set timeout에 의해 설정되는 타임 아웃은 GDB가 프로그램이 멈추는 걸 기다릴때는 적용되지 않는다. 그런 경우, GDB는 영원히 기다린다. 왜냐하면 프로그램이 멈춘후 얼마나 오랫동안 돌아갔는지를 알 방법이 없기 때문이다. 가상 CPU target 몇몇 설정을 위해, GDB는 여러분이 하드웨어 CPU 대신 여러분의 프로그램을 디버깅할수 있는데 사용할수 있는 CPU simulator를 포함한다. 현재, 시뮬레이터는 GDB가 zilog Z8000나 Hitachi microprocessor 타겟을 디버깅할때 이용한다. Z8000 패밀를 위해, `target sim'는 Z8002(Z8000 아키텍쳐의 unsegmented variant)나 Z8001(segmented variant)을 시뮬레이트한다. 시뮬레이터는 객체 코드를 조사하여 적당한 아키텍쳐가 무엇인지를 다시 인식한다. target sim Debug programs on a simulated CPU (which CPU depends on the GDB configuration) 타겟을 지정한후, 여러분은 여러분의 호스트 컴퓨터의 프로그램과 같은 스타일로 가상 CPU로 프로그램을 디버깅할수 있다; 새로운 프로그램 이미지를 로드하기 위해 file 명령어를 사요해라. 그리고 프로그램을 돌리기 위해 run 명령어를 사용해라. 이용할수 있는 모든 머신 레지스터(info reg 참조)를 만드는 것처럼, 이 디버깅 타겟은 특별한 이름의 레지스터로써 3가지의 추가적인 아이템 정보를 제공한다.: cycles simulator내 clock-ticks를 센다. insts simulator내 돌아가는 명령어를 센다. time 초당 60번 실행 타임. 여러분은 GDB 표현식에서 이들 값을 참조할수 있다; 예를 들어, `b fputc if $cycles>5000'는 적어도 5000 시뮬레이션된 clock ticks후에 일지 중지하도록 조건적 breakpoint를 설정한다. GDB 제어하기 여러분은 set 명령어를 사용하여 GDB와 서로 상호작용하는 방법을 수정할수 있다. GDB가 데이터를 나타내는 방법을 제어하는 명령어를 위해서 Print 설정하기 섹션을 참고해라.; 다른 셋팅들은 여기서 설명한다. Prompt GDB는 prompt 라 불리는 문자열을 출력하여 명령어를 읽기 위한 준비를 나타낸다. 이 문자열은 보통 `(gdb)'라 불린다. 여러분은 set prompt 명령어를 가지고 프롬프트 문자열을 바꿀수 있다. 예를 들어, GDB를 가지고 GDB를 디버깅할때 . For 여러분이 현재 대화하고 있는것이 무엇인지 항상 말할수 있게 하기 위해서 GDB의 세션들중 하나에 있는 프롬 프트를 바꾸는것은 유용하다. 주의: set prompt 는 여러분이 프롬프트를 설정한후 스페이스를 추가하지 않는다. 이것은 여러분이 스페이스 끝에 프롬프트를 설정하거나 그걸 하지 않은 프롬프트도 설정하게 해준다. set prompt newprompt 이후에 프롬프트 문자열로써 newprompt 를 사용하도록 GDB에게 명령한다. show prompt 형식라인을 출력한다.: `Gdb'의 프롬프트는 : your-prompt' 명령어 편집 GDB는 readline 인터페이스를 통해 입력 명령어들을 읽는다. GNU 라이브러리는 사용자를 위한 명령어 라인 인터페이스를 제공하여 프로그램을 위한 일관적인 행동을 제공한다. 장점들은 명령어들의 GNU Emacs-style 또는 csh의 히스토리와 같은 vi-style 명령어 라인 편집 그리고 디버깅 세션을 통하여 명령어 히스토리의 저장과 재호출등이다. 여러분은 set 명령어를 가지고 GDB에서 명령어 라인 편집의 행동을 제어할수 있다. set editing set editing on 명령어 라인 편집을 가능하게 한다(기본으로 가능). set editing off 명령어 라인 편집을 불가능하게 한다. show editing 명령어 라인 편집이 가능한지 보여준다. 명령어 히스토리 GDB는 여러분의 디버깅 세션동안에 여러분이 사용한 명령어의 발자취를 쫓아갈수 있다. 그래서 여러분은 무엇이 일어났는지 확실히 할수 있다. GDB 명령어 히스토리 기능을 관리하는 이들 명령어들을 사용해라. set history filename fname GDB 명령어 히스토리 파일 이름을 fname으로 설정해라. 이것은 GDB가 초기 명령어 히스토리 리스트를 읽는 파일이며 해당 파일이 존재할때 해당 세션에서 명령어 리스트를 쓴다. 여러분은 히스토리 확장이나 아래 나열한 히스토리 명령어 편집 특징들을 통해서 이 리스트를 접근할수 있다. 이 파일은 기본적으로 환경 변수인 GDBHISTFILE 값이거나, 이 변수가 설정되어 있지 않다면 `./.gdb_history' 를 기본으로 갖는다. set history save set history save on set history filename 명령어로 지정한 파일에 있는 명령어 히스토리를 저장한다. 기본적으로 이 옵션은 꺼져있다. set history save off 파일에 명령어 히스토리 저장을 멈춘다. set history size size GDB가 명령어 리스트에 유지하는 명령어들의 숫자를 설정한다. 이 값은 기본적으로 환경 변수 HISTSIZE 값이거나 이 변수가 설정되어 있지 않다면 256이다. 히스토리 확장은 문자 ! 에 특별한 의미를 부여한다. ! 이 C에서 logical not 오퍼레이션이기 때문에 히스토리 확장은 기본적으로 꺼져 있다. 여러분이 set history expansion on 명령어로 히스토리 확장을 켜놓는다면, 여러분은 확장에서부터 그것을 막기 위해 스페이스나 탭이 ! (표현에서, 그것이 logical not으로 사용될때) 다음에 가끔 필요하다. readline 히스토리 기능들은 히스토리 확장이 켜져 있을때 조차도 != 와 !( 문자열에서 대체를 시도하지 않는다. 히스토리 확장을 위한 명령어들은 다음과 같다: set history expansion on set history expansion 히스토리 확장기능을 킨다. 히스토리 확장은 기본적으로 꺼져 있다. set history expansion off 히스토리 확장을 끈다. readline 코드는 편집과 히스토리 확장 특징의 복잡한 문서화로 시작한다. GNU Emacs나 vi 에 익숙하지 않은 사용자들은 그것을 읽기를 원할지도 모른다. show history show history filename show history save show history size show history expansion 이들 명령어들은 GDB 히스토리 파라미터들의 상태를 보여준다. show history 는 네가지의 상태 모두를 출력한다. show commands 명령어 히스토리에 있는 마지막 10개의 명령어들을 보여준다. show commands n 명령어 숫자 n을 중심으로 10개의 명령어들을 보여준다.. show commands + 마지막으로 보여준 명령어 다음 10개 명령어들을 보여준다. 스크린 크기 어떤 GDB 명령어들은 스크린에 많은 양의 정보를 출력한다. 여러분이 해당 정보를 읽는데 도와주도록 하기 위해, GDB는 멈추고 여러분에게 출력의 각페이지 끝에서 여러분을 위한 입력을 기다린다. 출력을 계속 하기 위해 RET 을 타입하거나 출력의 나머지를 버리기 위해서 q 를 타입해라. 또한 스크린 폭 설정은 출력 라인들을 가릴때 결정한다. 출력되는것에 의존하여 GDB는 다음라인으로 넘치게 하기 보다 읽기 가능한 곳에서 라인을 자른다. 보통 GDB는 TERM 환경 변수 값과 stty rows 그리고 stty cols 설정의 termcap 데이타 베이스에서 스크린 크기를 안다. 이것이 맞지 않다면 set height 과 set width 명령어로 그것을 겹쳐 쓸수 있다.: set height lpp show height set width cpl show width 이들 set 명령어들은 스크린 크기 lpp 라인과 스크린 넓이 cpl 문자들을 지정한다. show 명령어는 현재 설정을 보여준다. 만일 여러분이 높이를 0으로 설정하면, GDB는 출력에 상간없이 멈추지 않는다. 이것은 출력을 파일이나 editor 버퍼로 할때 유용하다. 마찬가지로, 여러분은 GDB에서 출력을 가리는것을 막기 위해 `set width 0' 를 지정할수 있다. 숫자들 여러분은 일반적 변환으로 GDB에서 8진수, 10진수, 16진수로 숫자들을 사용할수 있다: 8진수는 `0'으로 시작하고, 10진수는 `.'으로 끝나고, 16진수는 `0x'으로 시작한다. 이것들중 어떤것과도 시작하지 않은 경우 기본적으로 10진수이다.; 마찬가지로 숫자들을 표현하는 기본은(특별한 포맷이 지정되지 않았다면) 10진수이다. 여러분은 set radix 명령어로 입력과 출력을 위한 기본 진수를 바꿀수 있다. set input-radix base 입력수를 위한 기본 진수를 설정한다. 지원되는 base 는 8, 10, 또는 16이다. base 는 그것 자체로 명백하거나 현재의 기본 진수 사용을 지정해야 한다.; 예를 들어 set radix 012 set radix 10. set radix 0xa 위의것중 어떤것은 10진수로 설정할수 있다. 다른 한편으로 `set radix 10' 는 진수가 무엇이든지 상관하지 않고 바꾸지 않도록 남겨둔다. set output-radix base 출력을 위한 기본 진수를 설정한다. 지원되는 base 는 8, 10, 또는 16이다. base 는 그것 자체로 명백하거나 현재의 기본 진수사용을 지정해야 한다. show input-radix 숫자 입력을 위한 현재 기본 진수를 출력한다. show output-radix 숫자 출력을 위한 현재 기본 진수를 출력한다. 경고 옵션들과 메세지들 기본적으로, GDB는 내부 작동에 관해서 침묵한다. 만일 여러분이 느린 컴퓨터에서 돌린다면, 여러분은 set verbose 명령어를 사용하길 원할 것이다. 이것은 GDB가 긴 내부 작동을 하고 있을때 여러분이 GDB가 크래쉬 되었다고 생각하지 않게 해준다. 현재, set verbose 에 의해 제어되는 메세지들은 소스 파일의 심볼 테이블이 읽혀지면서 알려주는 것들이다; see symbol-file in section Commands to specify files. set verbose on 어떤 정보 메세지들의 GDB 출력을 가능하게 한다. set verbose off 어떤 정보 메세지들의 GDB 출력을 가능하지 않게 한다. show verbose set verbose 이 켜져있는지 꺼져 있는지 알려준다. 기본적으로, GDB가 객체 파일의 심볼 테이블에 있는 버그들을 만난다면 GDB는 침묵한다. ; 그러나, 여러분이 컴파일러를 디버깅한다면 여러분은 이 정보의 유용성을 발견할 것이다. (심볼 테이블을 읽을때의 에러들 섹션을 참조해라). set complaints limit 문제에 관해 침묵하기 전에 쓰지 않는 심볼의 각 타입에 관한 limit 불평을 출력하도록 GDB에게 혀용한다. 모든 불평을 막기 위해 limit를 0으로 설정해라; 불평을 막혀진 것에서 막기 위해 큰수로 설정한다. show complaints 얼마나 많은 심볼 문제점이 GDB가 만들수 있도록 허용되었는지 보여준다. 기본적으로, GDB는 가끔 어떤 명령어를 확실히 할지를 위해 불명확한 의문인경우 경고하고 물어본다. 예를 들어, 여러분은 이미 돌아가고 있는 프로그램을 돌릴다면: (gdb) run The program being debugged has been started already. Start it from the beginning? (y or n) 만일 여러분이 자신의 명령어가 확실하다고 단정한다면, 이 특징들을 disable 시킬수 있다: set confirm off 확인 요구를 disable 시킨다. set confirm on 확인 요구(기본값)를 enable 시킨다. show confirm 확인 요구의 상태를 보여준다. 명령어들 순서 breakpoint 명령어들(Breakpoint 명령어 리스트 섹션을 참조해라)외에, GDB는 유닛으로써 실행 명령어의 순서들을 저장하는데 2가지 방법을 제공한다: 사용자 정의 명령어들과 명령 파일들. 사용자 정의 명령어들 사용자 정의 명령어는 여러분이 명령어로써 새로운 이름을 할당하는 GDB 명령어 이다. 이것은 define 명령어로 할수 있다. 사용자 명령어는 화이트 스페이스로 분리된 10개의 인자들까지 받아들일수 있다. 인자들은 $arg0...$arg9를 통해 사용자 명령어내 접근할수 있다. 간단한 예로: define adder print $arg0 + $arg1 + $arg2 명령어를 실행하기 위해: adder 1 2 3 이것은 명령어 adder를 정의하며 세 인자의 합을 출력한다. 인자들은 텍스트 치환이므로 참조변수, 복합 표현식이나 내부 함수 호출을 수행할수 있다. define commandname commandname이름의 명령어를 정의한다. 만일 그 이름으로 명령어가 있다면, 여러분은 다시 정의하길 원하는지 물어볼것이다. 명령어의 정의는 다른 GDB 명령어라인으로 이루어지며 다음에 define 명령어를 준다. 이들 명령어 마지막에는 end를 포함하는 라인으로 마크된다. if 단일 인자를 주며 이것은 평가할수 있는 표현식이다. 표현식이 참(0이 아닌값)이라면 실행되는 명령어 시리즈가 뒤따라 온다. 선택적으로 다음에 else이 올수 있으며, 표현식이 거짓이라면 실행되는 명령어 시리지가 뒤따라 온다. 리스트의 마지막은 end을 포함하는 라인으로 표시된다. while 문법은 if와 비슷하다:명령어는 단일 인자를 가지며 평가할수 있는 표현식이며 라인당 하나씩 실행할 명령어가 뒤따르며 end로 끝난다. 명령어들은 표현식이 참으로 평가되는 한 반복적으로 실행된다. document commandname 유저 정의 명령어 commandname를 문서화한다. 그래서 help로 접근할수 있다. 명령어 commandname는 이미 정의되어 있어야 한다. 명령어는 define가 명령어 정의의 라인들을 읽는 것처럼 문서의 라인들을 읽으며 end로 끝난다. document명령어를 마친후, 명령어 commandname에 대한 help는 여러분이 쓴 문서를 보여준다. 여러분은 명령어에 대한 문서를 바꾸기 위해 다시 document명령어를 쓸수 있다. define된 명령어를 재정의하는 것은 기존 문서는 바꾸지 않는다. help user-defined 각각의 문서에 대한 첫 라인과 함께 모든 사용자 정의 명령어들을 리스트한다. show user show user commandname commandname을 정의하기 위해 사용된 GDB 명령어를 보여준다.(그러나 문서화는 제외) 어떤 commandname도 주어지지 않았다면, 모든 사용자 정의 명령어들을 위한 정의를 보여준다. 사용자 정의 명령어를 실행할때, 정의된 명령어는 출력되지 않는다. 어떤 명령어에서 에러라면 사용자 정의 명령어들의 실행을 멈춘다. 만일 대화식으로 사용되었다면, 확신을 요구하는 명령어들은 사용자 정의 명령어내에서 사용 될때 물어보는것 없이 처리된다. 많은 GDB 명령어들은 사용자 정의 명령어를 사용할때 메세지를 생략했다는 것을 말하기 위해 보통 메세지들을 출력한다. 사용자 정의 명령어 고리들(hooks) 여러분은 특별한 사용자 정의 명령어인 hooks를 정의할수 있다. 만일 사용자 정의 명령어 `hook-foo'가 존재한다면, 여러분이 명령어 `foo'를 돌릴때는 언제나 명령어 전에 실행(인자 없이)된다. 추가적으로 가상 명령어, `stop'가 존재한다. 정의 (`hook-stop')는 프로그램내 실행이 멈출때마다 관련 명령어가 실행되도록 만든다: breakpoint 명령어가 돌아가기 전에, 출력이 보여지거나 스택 프레임이 출력된다. 예를 들어, 단일 stepping 도중 SIGALRM 신호를 무시하도록 하고, 실행도중 정상적으로 대해지도록 정의하고자 하면: define hook-stop handle SIGALRM nopass end define hook-run handle SIGALRM pass end define hook-continue handle SIGLARM pass end 여러분은 GDB내에서 단일 워드 명령어를 위해 훅을 정의할수 있지만 명령어 별칭은 아니다; 여러분은 기본 명령어 이름을 위해 훅을 정의할수 있다. bt보다는 backtrace. 만일 후킹도중 에러가 발생한다면, GDB 명령어의 실행은 멈추고 GDB는 프롬프트(여러분이 타이핑한 명령어가 돌아가기 전에)를 보여준다. 만일 여러분이 어떤 명령어와도 일치하지 않는 후킹을 정의하고자 하면, 여러분은 define 명령어에서 경고를 받는다. 명령어 파일들 GDB를 위한 명령어 파일은 GDB 명령어인 라인 파일들이다. 주석(#로 시작하는 라인)도 역시 포함된다. 명령어 파일내 빈라인도 역시 아무것도 하지 않는다; 이것은 터미널에서 처럼, 마지막 명령어를 반복한다는 의미는 아니다. 여러분이 GDB를 시작할때, 그것은 자동으로 init files에서 명령어를 실행한다. 이것들은 `.gdbinit'라는 이름의 파일들이다. GDB는 홈 디렉토리에서 init 파일을 읽는다. 그리고 명령어 라인 옵션과 오퍼랜드를 처리한다. 그리고 현재 작업 디렉토리에서 init 파일을 읽는다. 홈디렉토리내 init 파일은 명령어 라인 옵션들과 오퍼랜드들 처리에 영향을 주는 옵션 (set complaints 처럼)들을 설정한다. init 파일들은 여러분이 `-nx' 옵션들을 사용하지 않는다면 실행되지 않는다.; 모드 선택하기 섹션을 참조해라. GDB 설정중, init 파일은 다른 이름(이것들은 전형적으로 다른 형태와 공존하기 위해 GDB에 필요한 특별한 형태의 환경이며, 특별한 버전의 init 파일을 위한 다른 이름이다)으로 알려져 있다. 이것들은 특별한 init 파일 이름을 가지고 있는 환경들이다. VxWorks (Wind River Systems real-time OS): `.vxgdbinit' OS68K (Enea Data Systems real-time OS): `.os68gdbinit' ES-1800 (Ericsson Telecom AB M68000 emulator): `.esgdbinit' 여러분은 source 명령어로 명령어 파일의 실행을 요구할수 있다: source filename Execute the command file filename. 명령어 파일내 라인들은 순서적으로 실행된다. 그것들은 싱행되는 순서로 출력되지 않는다. 명령어 중 에러는 명령어 파일의 실행을 끝낸다. 만일 명령어 파일내 사용될때 물어보는것 없이 대화식으로 사용된다면 명령어들은 확신을 요구할수 있다. 많은 GDB 명령어들은 명령어 파일들에서 호출될때 메세지를 생략했다는 것을 말하기 위해 보통 메세지를 출력한다. 출력을 제어하기 위한 명령어들 명령어 파일이나 사용자 정의 명령어의 실행도중, GDB 출력은 보통 막혀진다; 나타나는 유일한 출력은 정의된 명령어에 의해 출력되는 것이다. 이 섹션은 여러분이 원하는 출력을 만드는데 유용한 세 개의 명령어를 나타낸다. echo text text 출력. 비 출력 문자들은 뉴라인을 출력하는 `\n' 같은 C 이스케이프 시퀀스를 포함하여 text에 포함된다. 뉴라인은 여러분이 지정하지 않는다면 출력되지 않는다. 표준 C 이스케이프 시퀀스에다가, 스페이스 다음에 backslash는 스페이스를 나타낸다. 이것은 시작이나 끝에서 스페이스 문자열을 나타내는데 유용하다. 왜냐하면 처음이나 끝 스페이스는 모든 인자에서 제거되기 때문이다. ` and foo = '를 출려갛기 위해, 명령어 `echo \ and foo = \ '를 사용해라. text 끝에 있는 backslash는 연속된 라인의 명령어를 계속하게 하기 위해 사용될수 있다. 예를 들어, echo This is some text\n\ which is continued\n\ onto several lines.\n 다음과 같은 출력을 만든다. echo This is some text\n echo which is continued\n echo onto several lines.\n output expression expression 값을 출력한다. 그리고 그 값외는 어떤 값도 출력하지 않는다: 뉴라인도 없이, `$nn = '도 없이. 값은 값 히스토리에도 역시 들어가지 않는다. 표현식에 관한 더 많은 정보를 원하면 표현식 섹션을 참조해라. output/fmt expression 포맷 fmt에 있는 expression 값을 출력한다. 여러분은 print와 같은 포맷을 사용할수 있다. 더 많은 정보를 원하면 출력 형식 섹션을 참조해라. printf string, expressions... string의 제어하에 expressions의 값을 출력한다. expressions는 콤마와 숫자나 포인터로 구분된다. 이들 값은 마치 여러분의 프로그램이 C 서브루틴에서 실행되는 것 처럼 string에 의해 지정된 것처럼 출력된다. printf (string, expressions...); 예를 들어, 여러분은 이것처럼 16진수 값으로 두 값을 출력할수 있다: printf "foo, bar-foo = 0x%x, 0x%x\n", foo, bar-foo 여러분이 포맷 스트링에서 사용할수 있는 backslash-escape sequence는 문자 다음에 backslash로 이루어지는 것들이다. GNU Emacs에서 GDB 사용하기 특별한 인터페이스는 여러분이 GDB로 디버깅하는 프로그램을 위한 소스 파일들을 보는데(그리고 편집) GNU Emacs를 사용하는걸 허용한다. 이 인터페이스를 사용하기 위해, Emacs에서 명령어 M-x gdb를 사용해라. 인자로써 여러분이 디버깅하길 원하는 실행파일을 주어라. 이 명령어는 Emacs의 하위 프로세스로써 GDB를 시작한다. Emacs에서 GDB를 사용하는 것은 두가지를 제외하고는 GDB 사용과 같다: 모든 "터미널" 입력과 출력은 Emacs 버퍼를 통해 간다. 이것은 GDB 명령어와 출력에 모두 적용되며 입력과 출력은 여러분이 디버깅하는 프로그램에 의해 행해진다. 그것은 여러분이 전 명령어의 텍스트를 복사하고 다시 입력 하는것을 의미하기 때문에 유용하다.; 여러분은 이 방법으로 출력의 일부분을 사용할수 있다. Emacs' 쉘 모드의 모든 기능은 여러분의 프로그램과 상호작동을 위해 이용된다. 특별히, 여러분은 보통처럼 신호를 보낼수 있다--예를 들어, 인터럽트를 위해 C-c C-c, stop을 위해 C-c C-z. GDB는 Emacs를 통해 소스 코드를 보여준다. GDB가 스택 프레임을 보여줄때마다, Emacs는 자동적으로 프레임을 위해 소스 코드를 발견하며 현재 라인의 왼쪽 가장자리에 화살표 (`=>')를 놓는다. Emacs 소스 출력을 위해 분리된 버퍼를 사용하며 GDB 세션과 소스 코드 둘다 보여주기 위해 스크린을 나눈다. 명백한 GDB list나 탐색 명령어들은 여전히 보통때 처럼 출력을 만들지만 여러분은 Emacs에서 그것들을 사용할 이유가 없다. 경고: 만일 여러분의 프로그램이 있는 디렉토리가 현재 디렉토리가 아니라면, 소스 파일의 위치에 관해 Emacs가 혼돈할수 있다. 그런 경우 보조 출력 버퍼는 소스 파일을 보여주기 위해 나타나지 않는다. GDB는 환경 PATH 변수를 탐색하여 프로그램을 발견할수 있다. 그래서 GDB 입력과 출력 세션은 계속 된다. 그러나 Emacs는 소스 파일을 찾기 위해 GDB에서 다시 충분한 정보를 얻지 못한다. 이 문제를 피하기 위해, 프로그램이 존재하는 디렉토리나 M-x gdb 인자에서 프롬프트될때 확실한 파일 이름을 지정하고 GDB 모드를 시작해라. 만일 여러분이 Emacs내 GDB 버퍼에서 다른 위치에 있는 프로그램을 디버깅하기 위해 바꿀때 GDB file 명령어를 사용한다면 비슷한 혼돈이 생길수 있다. 기본적으로, M-x gdb는 `gdb'라 불리는 프로그램을 호출한다. 만일 여러분이 다른 이름(예를 들어, 만일 여러분이 다른 이름을 가지고 몇몇 설정을 유지한다면)으로 GDB를 호출할 필요가 있다면, 여러분은 Emacs 변수 gdb-command-name를 설정할수 잇다; 예를 들어, (setq gdb-command-name "mygdb") 는(ESC ESC나 *scratch* 버퍼에 타이핑하거나 `.emacs' 파일내에) Emacs가 "mygdb"라는 이름의 프로그램을 호출하도록 만든다. GDB I/O 버퍼에서, 여러분은 표준 Shell 모드 명령어에다가 이들 특정 Emacs 명령어를 사용할수 있다: C-h m Emacs' GDB 모드의 특징을 기술한다. M-s GDB step 명령어 처럼 다른 소스 라인을 출력한다.; 또흔 현재 파일과 위치를 보여주기 위해 윈도우의 출력을 갱신한다. M-n 다음 함수 호출을 건너띄는 GDB next 명령어 처럼 이 함수내에서 다음 소스 파인을 실행한다. 그리고 현재 파일과 위치를 보여주기 위해 윈도우의 출력을 갱신한다. M-i GDB stepi 명령어 처럼 한 명령어를 실행한다; 윈도우의 출력을 갱신한다. M-x gdb-nexti GDB nexti 명령어를 사용하여 다음 명령어를 실행한다; 윈도우 출력을 갱신한다. C-c C-f GDB finish 명령어 처럼 선택된 스택 프레임에서 종료할때까지 실행한다. M-c GDB continue 명령어 처럼, 프로그램의 실행을 계속한다. 경고: Emacs v19에서, 이 명령어는 C-c C-p이다. M-u GDB up 명령어 처럼, 숫자 인자(The GNU Emacs Manual에 있는 `Numeric Arguments` 섹션을 참조해라.)가 가리키는 프레임수로 올라 가라. 경고:Emacs v19에서, 이 명령어는 C-c C-u이다. M-d GDB down 명령어 처럼, 숫자 인자가 가리키는 프레임 수로 내려 가라. 경고: Emacs v19에서, 이 명령어는 C-c C-d이다. C-x & 커서가 위치해 있는 곳의 수를 읽어라. 그리고 GDB I/O 버퍼의 끝에 넣어라. 예를 들어, 만일 여러분이 처음에 보여줬던 주소 근처의 역어셈블 코드를 원한다면, disassemble를 타이핑해라.; 그리고 주소를 출력하기 위해 커서를 옮겨라. 그리고 C-x &를 타이핑해서 disassemble를 위해 인자를 넣어라. 여러분은 리스트 gdb-print-command의 요소들을 정의하여 앞으로 이것을 커스터마이징 할수 있다; 일단 정의되면, 여러분은 포맷할수 있거나 그렇지 않으면 프로세스 수들은 집어 넣기 전에 C-x &으로 계속할수 있다. C-x &을 위한 수 인자는 여러분이 원하는 포맷과 Emacs 함수 format를 사용하여 포맷한 요소를 선택하기 위한 인덱스로써 작동한다.; 그렇지 않으면 수는 상응하는 리스트 요소에 대한 인자로써 전달된다. 어떤 소스 파일내에서, Emacs 명령어 C-x SPC (gdb-break)는 소스 라인 포인터에 brekapoint가 설정되도록 GDB에게 말한다. 만일 여러분이 잘못하여 소스 출력 버퍼를 지운다면, 다시 breakpoint를 가지는 쉬운 방법은 프레임 출력을 요구하기 위해 GDB 버퍼에 명령어 f를 타이핑하는 것이다.; 여러분이 Emacs에서 돌릴때, 만일 현재 프레임의 문맥을 여러분에게 보여줄 필요가 있다면 이것은 소스 버퍼를 다시 만든다. Emacs에서 보여주는 소스 파일들은 보통 Emacs 버퍼에 있다. 여러분은 원한다면 이들 버퍼를 가지고 있는 파일들을 편집할수 있다; 그러나 GDB는 Emacs와 라인 넘버를 수단으로 통신한다는것을 기역해라. 만일 여러분이 텍스트에서 라인을 추가하거나 지운다면, GDB가 알고 있는 라인 넘버는 코드에 상응하는 것을 멈춘다. GDB에 있는 버그 리포팅하기 여러분의 버그 리포트는 믿을수 있는 GDB를 만드는데 필수적인 역활을 한다. 버그 리포팅은 여러분의 문제를 해결하는데 도와준다. 그러나 어떤 경우든지 버그 리포팅의 기본 기능은 GDB의 다음 버전을 더 좋게 만들기 위한 전체적 커뮤니티를 도와준다는 것이다. 버그 리포팅은 GDB를 유지하기 위한 여러분의 공헌이다. 버그 리포트시, 여러분은 우리가 버그를 고칠수 있도록 가능한 정보들을 포함해야 한다. 버그를 발견했는가? 여러분이 버그를 발견했는지를 확신하지 못한다면, 여기에 약간의 지침이 있다: 만일 디버거가 치명적인 신호를 받았다면, 그것은 GDB 버그이다. 신뢰적인 디버거는 결코 죽지 않는다. 만일 GDB가 유효한 입력에 에러 메세지를 만든다면, 그것은 버그이다. 만일 GDB가 유효하지 않는 입력에 에러 메세지를 만들지 않는다면, 그것은 버그이다. 그러나, 여러분은 여러분이 생각하는 "invalid input" 를 우리들은 "확장"이나 "전통적인 문제를 위한 지원"으로 생각할수 있다는 점을 주의해라. 만일 여러분이 디버거 툴에 경험이 있는 사용자라면, GDB 향상을 위한 여러분의 제안을 어떤 경우든지 환영한다. 버그를 리포트하는 방법 여러 회사와 개인들이 GNU 제품을 위해 지원을 제공한다. 만일 여러분이 지원 기구 GDB를 얻길 원한다면, 우리는 여러분이 우선 기구에 접촉하길 추천한다. 여러분은 GNU Emacs 배포에 있는 파일 `etc/SERVICE'에서 많은 지원 회사들과 개인들에 관한 정보를 찾을수 있다. 어떤 경우든, 우리는 여러분이 다음 주소들 중 하나로 GDB 버그 리포트를 보내길 추전한다.: bug-gdb@prep.ai.mit.edu {ucbvax|mit-eddie|uunet}!prep.ai.mit.edu!bug-gdb `info-gdb'나, `help-gdb', 또는 어떤 뉴스그룹에도 버그 리포트를 보내지 마라. GDB의 대부분의 ㅅ ㅏ용자들은 버그 리포트를 받길 원하지 않는다. 이들이 하는것은 받은 `bug-gdb'를 정리하는 것이다. 메일링 리스트 `bug-gdb'는 리피터로써 역할을 하는 뉴스 그룹 `gnu.gdb.bug'를 가지고 있다. 메이링 리스트와 뉴스그룹은 정확히 같은 메세지를 전달한다. 자주 사람들은 메일링 리스트 대신 뉴스그룹에 버그 리포트를 포스팅할려고 한다. 이것은 괜찮은것 같지만 중요한 문제를 가지게 된다: 뉴스 그룹 포스팅은 자주 보낸 사람에 대한 메일 경로가 부족하다. 이와 같이, 우리가 더 많은 정보를 요구할 필요할 경우, 우리는 여러분에게 알릴수가 없다. 이런 이유 때문에, 메일링 리스트로 버그 리포트를 보내는 것이 좋다. As a last resort, send bug reports on paper to: GNU Debugger Bugs Free Software Foundation Inc. 59 Temple Place - Suite 330 Boston, MA 02111-1307 USA 버그 리포팅의 기본적인 원리는 이것이다: report all the facts. 만일 여러분이 상태가 사실인지 아닌지를 확신하지 못한다면, 그렇게 써라. 자주 사람들은 사실들을 생략한다. 왜냐하면 그들은 문제의 원인을 안다고 생각하고 몇몇 세부사항은 중요하지 않다고 가정하기 때문이다. 여러분은 예제에서 여러분이 사용하는 변수의 이름은 중요하지 않다고 가정한다. 아마도 그렇지는 않을것이지만, 누구도 확신할수는 없다. 아마도 버그는 메모리에 저장되어 있는 위치에서 가져올때 일어나는 잘못된 메모리 참조이다.; 아마도, 만일 이름이 다르다면, 그 위치의 내용은 버그에도 불구하고 적당한 방법으로 하는것은 디버거에겐 무리다. 안전하게 플레이하고 특별하고 완전한 예를 주어라. 그것이 여러분이 할수 있는 가장 쉬운 것이고 가장 도움이 된다. 버그 리포트의 목적은 버그가 우리에게 새롭다면 버그를 고치는것을 가능하게 해준다는 점을 유의해라. 그러므로 버그가 아직 리포트되지 않았다고 가정하고 보내라. 가끔 사람들은 약간의 사실만을 주고 "Does this ring a bell?"을 물어본다. 이들 버그 리포트는 쓸모없다. 그리고 우리는 버그를 리포트 한 사람에게 약간의 잔소리를 하는것을 제외하고 모든 사람들에게는 응답 거절을 하도록 한다. 버그를 고치도록 가능하게 하기 위해, 여러분은 이것들 모두를 포함해야 한다: GDB 버전. GDB는 여러분이 인자 없이 시작하였다면 알려준다; 여러분은 또한 show version을 사용하여 어느때라도 그것을 출력할수 있다. 이것 없이, 우리는 GDB의 어느 버전에 버그가 있는지를 알지 못한다. 여러분이 사용하는 머신의 타입 그리고 OS의 이름 그리고 버전 넘버. GDB를 컴파일 하기 위해 사용했던 컴파일러(그리고 버전)--e.g. "gcc--2.0". 여러분이 디버깅할려는 프로그램을 컴파일 하는데 사용한 컴파일러(그리고 버전)-- e.g. "gcc--2.0". 여러분이 예제를 컴파일하기 위해 컴파일러에게 준 명령어 인자와 관찰된 버그. 예를 들어, 여러분은 `-O' 사용하였는가? 여러분이 중요한 무언가를 생략하지 않았는지 보장하기 위해, 그것들 모두 리스트 해라. Makefile(또는 make에서 출력되는것)의 복사본으로도 충분한다. 만일 유리가 인자를 추측한다면, 우리는 잘못 추측할수도 있고 버그를 만나지 못할지도 모른다. 완전한 입력 스크립트 그리고 모든 필요한 소스 파일들, 그것들이 버그를 다시 만들어 줄 것이다. A description of what behavior you observe that you believe is incorrect. For example, "It gets a fatal signal." 예를 들어, "치명적 신호를 가졌다." 물론, GDB가 치명적 신호를 가진게 버그라면, 우리는 확실히 주의할 것이다. 그러나 만일 버그가 잘못된 출력이라면, 눈에 띄는 잘못이 아니라면 우리는 신경쓰지 않을 것이다. 여러분은 실수를 만들 기회를 우리에게 주지 않을 것이다. 여러분이 경험한 문제가 치명적 신호일지라도, 여러분은 여전히 명백히 말해야 한다. 여러분의 GDB 복사본이 오작동을 계속하거나 시스템에 있는 C 라이브러리 루틴의 버그를 만났다고 가정하자.(가능한 일이다!) 여러분의 복사본은 크래쉬되고 우리의 것은 그렇지 않을 것이다. 만일 여러분이 크래쉬되었다고 우리에게 말한다면, 우리가 크래쉬에 실패할때, 우리는 버그가 우리에게 일어나지 않았다고 알 것이다. 만일 여러분이 크래쉬될 것이라고 우리에게 말하지 않는다면, 우리는 관찰에서 어떤 결정도 할수 없다. 만일 여러분이 GDB 소스를 바꾸길 원한다면, 차이나는 부분을 우리에게 보내라. 만일 여러분이 GDB 소스에 있는것을 토론하길 원한다면, 라인 넘버가 아니라 문맥으로 가리켜라. 개발 소스의 라인은 여러분의 소스에 있는 라인과 일치하지 않는다. 여러분의 라인 넘버는 우리에게는 유용한 정보를 주지 못한다. 여기에 필요하지 않는 몇가지 것이 있다: 버그에 대한 보고. 버그를 만나는 사람들은 자주 입력 파일에 대한 변경은 버그를 사라지게 하는지 그리고 변경이 영향을 주지 않는지를 조사하는데 많은 시간을 보낸다. 이것은 시간을 소비하는 것이며 유용하지 않다. 왜냐하면 우리가 버그를 발견하는 방법은 디버거에 breakpoint를 놓고 간단한 예제를 돌려서 발견하지 예제들에서 추정해서 하지 않기 때문이다. 우리는 여러분이 그밖의 것을 하는데 여러분의 시간을 보내길 추천한다. 물론, 여러분은 원래것 대신에 보고 하기 위해 간단한 예를 발견한다면, 우리에게는 편할 것이다. 출력에 있는 에러들은 쉽게 찾을 수 있고, 디버거로 돌리는것도 시간이 덜 걸릴것이다. 그러나, 단순한게 중요한게 아니다; 만일 여러분이 이걸 하기를 원하지 않는다면, 어쨋든 버그를 리포트해라. 그리고 여러분이 사용한 전체 테스트 경우를 우리에게 보내라. 버그에 대한 패치. 만일 패치가 좋다면 버그에 대한 패치는 우리에게 도움을 준다. 그러나 테스트 경우처럼, 패치가 우리가 필요한 모든 것이라고 가정하고 필요한 정보를 생략하지 마라. 우리는 패치로 문제를 볼수 잇고 다른 방법으로 문제를 고칠수 있다. 그렇지 않으면 우리는 전체적으로 이해하지 못할지도 모른다. GDB처럼 복잡한 프로그램은 가끔 코드를 통해 어떤 경로를 따라가도록 프로그램을 만드는 예제를 만드는것은 매우 어렵다. 만일 여러분이 예제를 우리에게 보내주지 않는다면, 우리는 예제를 만들수 없을지 모르며, 그래서 버그를 고치기 위해 조사할수 없을지도 모른다. 그리고 만일 우리가 여러분이 고칠려고 한 버그를 이해하지 못하거나 여러분의 패치로 기능이 개선된다고 이해하지 못한다면, 우리는 패치를 설치하지 않을 것이다. 테스트 경우는 이해하는데 우리를 도와준다. 버그가 무엇인지에 대한 추측이나 관련된 것. 그런 추측은 보통 좋지 않다. 우리 조차도 그 사실을 발견하기 위해 처음에 디버거를 사용하지 않고 그런 것을 추측할수 없다. 형식화된 문서 GDB 4 릴리즈는 메인 소스 디렉토리(4)의 `gdb' 하위 디렉토리에 PostScript나 GhostScript로 출력할수 있는 이미 형식화된 레퍼런트 카드를 포함한다. 만일 여러분이 프린터에서 PostScript나 GhostScript를 사용할수 있다면, 여러분이 `refcard.ps'로 즉시 레퍼런트 카드를 출력할수 있다. 이 릴리즈는 또한 레퍼런스 카드에 대한 소스도 포함한다. 여러분은 TeX를 사용하여 포맷을 지정할수 있다: make refcard.dvi GDB 레퍼런트 카드는 US "letter" 크기의 종이에 landscape 모드로 출력하도록 디자인되었다; 즉, 쉬트 11인티에 8.5인치정도 넓다. 여러분은 DVI 출력 프로그램에 옵션으로써 출력 형태를 지정할 필요가 있다. GDB를 위한 모든 문서들은 기계-읽기 배포본의 일부로써 온다. 문서들은 Textinfo 문서로 쓰여졌으며 단일 소스 파일을 온라인 정보와 출력 매뉴얼로 만드는데 사용할수 있는 문서시스템이다. 여러분은 문서의 온라인 버전을 만들기 위해 Info 형식 명령어들중 하나를 사용할수 있다. 그리고 출력된 버전의 조판을 위해 TeT(또는 texi2roff)를 사용할수 있다. GDB는 `gdb' 서브 디렉토리에 이 문서의 온라인 Info 버전의 형식화된 복사본을 이미 포함하고 있다. 주요 Info 파일은 `gdb-version-number/gdb/gdb.info'이며, 같은 디렉토리에서 `gdb.info*'와 매치되는 파일들을 가리킨다. 만일 필요하다면, 여러분은 이들 파일들을 출력하거나 다른 에디터로 읽을수 있다; 그러나 GNU Emacs에서 info를 사용하거나 GNU Texinfo 배포판의 일부로써 이용할수 있는 info 프로그램으로 읽을수 있다. 만일 여러분이 스스로 이들 Info 파일들을 형식화하길 원한다면, 여러분은 texinfo-format-buffer 나 makeinfo같은 Info 형식 프로그램들 중 하나가 필요할지 모른다. 만일 여러분이 makeinfo를 인스톨한다면, 그리고 GDB 소스 디렉토리(`gdb-`)의 최상위 레벨에 있다면, 여러분은 다음과 같이 타이핑하여 Info 파일을 만들수 있다: cd gdb make gdb.info 만일 여러분이 이 매뉴얼의 복사본을 조판하고 출력하기를 원한다면, 여러분은 DBI output 파일들을 출력할수 있는 프로그램 TeX가 필요하다. 그리고 Textinfo 정의 파일 `texinfo.tex'이 필요하다. Text는 조판 프로그램이다; 그것은 직접 파일을 출력하지 않으며 DVI 파일을 불러 output 파일들을 만든다. 만일 여러분의 시스템에 TeX가 설치되어 있다면, 그런 프로그램을 가지고 있을 것이다. 사용할 정확한 명령어는 시스템에 의존한다; lpr -d가 일반적이다; 다른(PostScript 장치들)것은 dvips이다. DVI 출력 명령어는 어떠한 확장이나 `.dvi' 확장 없이 파일이름을 요구한다. TeX 또한 `texinfo.tex'라 불리는 매크로 정의 파일들을 요구한다. 이 파일은 Textinfo 형식으로 쓰여진 문서를 조판하는 방법을 TeX에게 말해준다. TeX는 Textinfo 파일을 읽거나 조판을 할수 없다. `texinfo.tex'는 GDB와 함께 배포되며 `gdb-version-number/texinfo' 디렉토리에 위치한다. 만일 여러분이 TeX와 DVI 프린터 프로그램을 가지고 있다면, 여러분은 이 매뉴얼을 조판하고 출력할수 있다. 우선 메인 소스 디렉토리의 `gdb' 하위 디렉토리로 이동해라(예를 들어, `gdb-/gdb') 그리고 타이핑해라.: make gdb.dvi GDB 설치 GDB는 GDB 설치 준비를 자동으로 해주는 configure 스크립트를 이용한다.; 그리고 gdb 프로그램을 컴파일하기 위해 make를 사용해라. (5) GDB 배포는 하나의 디렉토리에 GDB 설치에 필요한 모든 소스 코드가 포함되며, 보통 이름은 `gdb`에 버전 숫자가 붙어서 이루어 진다. 예를 들어, GDB 버전 배포물은 `gdb-' 디렉토리에 있다. 디렉토리에 포함된 것들: gdb-/configure (and supporting files) GDB 설정을 위한 스크립트와 모든 지원 라이브러리들 gdb-/gdb GDB 자체를 위한 특정 소스 gdb-/bfd Binary File Descriptor 라이브러리를 위한 소스 gdb-/include GNU include 파일들 gdb-/libiberty free software 라이브러리를 `-liberty' 위한 소스 gdb-/opcodes opcode 테이블과 역 어셈블러 라이브러리를 위한 소스 gdb-/readline GNU command-line 인터페이스를 위한 소스 gdb-/glob GNU 파일 이름 패턴-매칭 서브루틴을 위한 소스 gdb-/mmalloc GNU memory-mapped malloc 패키지를 위한 소스 GDB를 설정하고 컴파일하기 위한 가장 간단한 방법은 `gdb-version-number' 소스 디렉토리에서 configure를 하는 것이다. 이 예제에서는 `gdb-' 디렉토리 이다. 여러분이 이 디렉토리에 없다면 우선 `gdb-version-number' 디렉토리로 이동해라.; 그리고 configure를 실행해라. GDB가 돌아갈 플랫폼 식별자를 주어라. 예를 들어: cd gdb- ./configure host make where host는 GDB가 돌아갈 플랫폼을 식별하는 `sun4' 나 `decstation'와 같은 식별자이다. (여러분은 자주 host에서 그만둔다.; configure 는 여러분의 시스템을 시험하여 정확한 값을 찾아 낸다.) `configure host'를 실행하고 `bfd', `readline', `mmalloc', 그리고 `libiberty' 라이브러리들, 그리고 gdb 자체를 컴파일 하기 위해 make를 실행해라. 설정된 소스들과 바이너리들은 소스 디렉토리에 상응하는 곳에 있게 된다. configure 는 Bourne-shell (/bin/sh) 스크립이다.; 여러분 시스템이 만일 다른 쉘을 이용할때 이것이 자동으로 돼지 않는다면, 여러분은 명확히 sh를 실행해야 할지도 모른다. sh configure host 여러분이 `gdb-' 버전 소스 디렉토리에서와 같이 다중 라이브러리들과 프로그램 소스 디렉토리를 포함하는 디렉토리에서 configure 를 한다면, configure 는 모든 디렉토리 레벨 밑에서 설정 파일들을 만든다.(만일 그렇게 하지 않을려면, `--norecursion' 옵션을 주어라.). 여러분이 특정 하위 디렉토리만 설정하기를 원한다면 GDB 배포물에서 특정 하위 디렉토리에서 configure를 실행시킬수 있다. 그러나 경로는 확실히 지정해야 한다. 예를 들어, bfd 하위 디렉토리만 설정하기를 원하면: cd gdb-/bfd ../configure host 여러분은 어떤곳이든지 gdb 를 설치할수 있다; 고정된 경로를 가지고 있지 않다. 그러나, 여러분은 여러분의 경로(`SHELL' 환경 변수라 불린다) 에 있는 쉘이 공개적으로 읽기가 가능한지 확실히 해야 한다. GDB는 프로그램을 시작하기 위해 그 쉘을 사용한다는 것을 명심해라. - 몇몇 시스템들은 프로그램들이 읽기가 가능하지 않은 경우 자식 프로세스들을 디버깅하도록 GDB를 허용하지 않는다. 다른 디렉토리에서 GDB 컴파일 하기 여러분이 몇몇 호스트나 타겟 머신들을 위한 GDB 버전들을 실행하길 원한다면, 여러분은 각각의 호스트와 타겟의 조합을 위한 다른 gdb가 필요하다. configure는 소스 디렉토리에서보다, 각각의 하위 디렉토리에서 각 설정을 만들수 있도록 허용하여 쉽게 이것을 만들수 있도록 디자인 되어 있다. 여러분의 make 프로그램이 `VPATH' 를 처리할수 있다면(GNU make는 한다.), 이 디렉토리들 각각에 있는 make를 돌려 지정된 곳에 gdb 프로그램을 만든다. 각각의 디렉토리에 gdb 를 설치하기 위해서는, 소스를 발견하도록 지정하는 `--srcdir' 옵션을 주어 configure 를 해야 한다.(여러분은 또한 작업 디렉토리에서 configure 자체를 발견하기 위해 패스를 지정할 필요가 있다. configure 에 대한 경로가 `--srcdir' 에 대한 인자와 같다면, 여러분은, `--srcdir' 옵션을 뺄수 있다.; 당연히 그렇게 가정되어 있다.) 예를 들어, 여러분은 다음처럼 Sun 4를 위해 다른 디렉토리에서 GDB를 설치할수 있다.: cd gdb- mkdir ../gdb-sun4 cd ../gdb-sun4 ../gdb-/configure sun4 make configure 가 원격 소스 디렉토리를 사용하여 설정을 만들때, 이것은 소스 디렉토리내 트리와 같은 구조(그리고 같은 이름을 사용한다)를 가진 바이너리를 위한 트리를 만든다. 예를 들어, 여러분은 `gdb-sun4/libiberty' 디렉토리내에서 Sun 4 라이브러리 `libiberty.a' 를 발견할 것이고 GDB 자체는 `gdb-sun4/gdb' 에서 발견할 것이다. 가각의 디렉4토리에 여러개의 GDB 설정들을 만드는 가장 인기 있는 이유는 크로스-컴파일(GDB 는 한 머신에서 돌아간다--the host--- 반면에 디버깅 프로그램은 다른 머신에서 돌아간다--the target)을 위한 GDB를 설정하기 위해서이다. 여러분은 configure 를 위한 옵션 `--target=target' 를 주어 크로스-디버깅 타겟을 지정해야 한다. 여러분이 프로그램이나 라이브러리를 컴파일하기 위해 make 를 실행한다면, 여러분은 설정된 디렉토리내에서 실행해야 한다. - 여러분이 configure 를 할때 여러분이 있는 디렉토리가 무엇이든지 (또는 그것의 하위 디렉토리들중 하나) configure 가 각 소스 디렉토리에서 만드는 Makefile은 또한 재귀적으로 만들어진다. 여러분이 `gdb-' 같은 소스 디렉토리에서 make 를 한다면, 여러분은 관련 라이브러리들을 모두 컴파일 할수 있다. 그리고 GDB도 만들어 진다. 여러분이 각각의 디렉토리에 다중 호스트나 타겟에 관한 설정을 가지고 있다면, 병렬적으로 make 를 할수 있다. (예를 들어, 각각의 디렉토리들이 호스트들 각각에 마운트된 NFS인 경우); 이것들은 서로서로 간섭하지 않는다. 호스트와 타겟 이름 지정하기 configure 스크립트에서 호스트와 타겟을 위해 사용된 지정어들은 세 부분 이름 구조에 기반하고 있다. 그러나 몇몇 미리 정의된 앨리어스(별명)도 또한 지원된다. 완전한 이름 구조는 다음 패턴에서처럼 세개의 정보조각으로 인코드된다. architecture-vendor-os 예를 들어, 여러분은 host 인자로서 또는 --target=target 옵션에서 target 을 위한 값으로 sun4 를 사용할수 있다. 이것과 같은 완전한 이름은 `sparc-sun-sunos4'이다. GDB에 들어 있는 configure 스크립트는 지원되는 모든 호스트나 타겟 이름들 또는 앨리어스의 리스트들을 질의할수 있는 기능을 제공하지 않는다. configure는 단축명과 완전한 이름들을 대응시키기 위해 Bourne 쉘 스크립트 config.sub 를 호출한다. 여러분이 원한다면, 여러분은 해당 스크립트를 읽을수 있으며 단축명을 테스트하기 위해 이것을 사용할수 있다. -- 예를 들어: % sh config.sub sun4 sparc-sun-sunos4.1.1 % sh config.sub sun3 m68k-sun-sunos4.1.1 % sh config.sub decstation mips-dec-ultrix4.2 % sh config.sub hp300bsd m68k-hp-bsd % sh config.sub i386v i386-unknown-sysv % sh config.sub i786v Invalid configuration `i786v': machine `i786v' not recognized config.sub 는 GDB 소스 디렉토리에 있다.(`gdb-', 버전). configure 옵션들 다음은 GDB를 컴파일할때 유용한 configure 옵션들과 인자들에 대한 개요이다. configure 는 또한 여기에 리스트되지 않은 옵션들도 있다. configure에 대한 완전한 설명서인 `configure.info'의 `What Configure does' 부분을 참조해라. configure [--help] [--prefix=dir] [--srcdir=dirname] [--norecursion] [--rm] [--target=target] host 여러분은 원한다면 `--' 보다 `-' 한개를 이용하여 옵션들을 사용할수 있다.; 그러나 여러분은 `--' 를 사용한다면 옵션이름들을 단축할수 있다. --help configure 를 실행시킬수 있는 방법에 대한 간단한 요약을 보여준다. -prefix=dir `dir' 디렉토리 밑으로 프로그램들과 파일들을 설치하기 위해 소스를 설정한다. --srcdir=dirname 경고: 이 옵션은 VPATH 특징을 수행할수 있는 GNU make 나, 다른 make 를 요구한다. 이 옵션은 GDB 소스 디렉토리와 다른 디렉토리에 설정화일들을 만들때 사용한다. 다른 것들과 함께, 여러분은 다른 디렉토리에 동시에 여러개의 설정들을 하는데 이 옵션을 사용할수 있다. configure 는 현재 디렉토리에 있는 특정 파일에 설정들을 쓴다. 그러나 dirname 디렉토리에 소스를 사용하기 위해 그것들을 배치한다. configure 는 dirname 아래 소스 디렉토리와 병렬적으로 작업 디렉토리내에 디렉토리들을 만든다. --norecursion configure 가 실행되는 디렉토리에서만 설정된다.; 하위 디렉토리는 설정하지 않는다. --rm 설정동안 생긴 것들외의 파일들을 제거한다. --target=target 지정된 target 에서 돌아갈수 있는 크로스-디버깅 프로그램을 위한 GDB를 설정한다. 이 옵션이 없으면, GDB는 GDB 처럼 같은 머신(host)에서 돌아가는 프로그램으로 설정된다. 여기에는 이용할수 있는 모든 타겟들의 리스트를 만들 편리한 방법은 없다. host ... 지정된 host 에서 돌아갈수 있도록 GDB를 설정한다. 여기에는 이용할수 있는 모든 호스트들의 리스트를 만들 편리한 방법은 없다. configure 는 다른 GNU 툴들과 재귀적으로 설정될수 있도록 다른 옵션들을 받아들인다.; 그러나 이것들은 단지 GDB나 지원 라이브러리들에 영향을 주는 옵션들이다. Index Jump to: # - $ - . - / - : - @ - a - b - c - d - e - f - g - h - i - j - k - l - m - n - o - p - q - r - s - t - u - v - w - x - z - { # # # in Modula-2 $ $ $$ $_ $_ and info breakpoints $_ and info line $_, $__, and value history $__ $_exitcode $bpnum $cdir $cwd . . .esgdbinit `.gdbinit' .os68gdbinit .vxgdbinit / /proc : ::, :: @ @ a a.out and C++ abbreviation active targets add-shared-symbol-file add-symbol-file AMD 29K register stack AMD EB29K AMD29K via UDI arguments (to your program) artificial array assembly instructions, assembly instructions assignment attach, attach automatic display automatic thread selection awatch b b backtrace break break ... thread threadno break in overloaded functions breakpoint commands breakpoint conditions breakpoint numbers breakpoint on memory address breakpoint on variable modification breakpoint subroutine, remote breakpoints breakpoints and threads bt bug criteria bug reports bugs in GDB c c C and C++ C and C++ checks C and C++ constants C and C++ defaults C and C++ operators C++ C++ and object formats C++ exception handling C++ scope resolution C++ support, not in COFF C++ symbol decoding style C++ symbol display call call overloaded functions call stack calling functions calling make casts, to view memory catch catch exceptions cd cdir checks, range checks, type checksum, for GDB remote choosing target byte order clear clearing breakpoints, watchpoints COFF versus C++ colon, doubled as scope operator colon-colon command files, command files command line editing commands commands for C++ commands to STDBUG (ST2000) comment compilation directory Compiling complete completion completion of quoted strings condition conditional breakpoints configuring GDB confirmation connect (to STDBUG) continue continuing continuing threads control C, and remote debugging controlling terminal convenience variables core core dump file core-file CPU simulator crash of debugger current directory current thread cwd d d debugger crash debugging optimized code debugging stub, example debugging target define delete delete breakpoints delete display deleting breakpoints, watchpoints demangling detach device dir directories for source files directory directory, compilation directory, current dis disable disable breakpoints, disable breakpoints disable display disassemble display display of expressions do document documentation down down-silently download to H8/300 or H8/500 download to Hitachi SH download to Nindy-960 download to Sparclet download to VxWorks dynamic linking e eb.log EB29K board EBMON echo ECOFF and C++ editing ELF/DWARF and C++ ELF/stabs and C++ else Emacs enable enable breakpoints, enable breakpoints enable display end entering numbers environment (of your program) error on valid input examining data examining memory exception handlers, exception handlers exceptionHandler exec-file executable file exiting GDB expressions expressions in C or C++ expressions in C++ expressions in Modula-2 f f fatal signal fatal signals fg file finish flinching floating point floating point registers floating point, MIPS remote flush_i_cache focus of debugging foo fork, debugging programs which call format options formatted output Fortran forward-search frame, frame, frame frame number frame pointer frameless execution Fujitsu g g++ GDB bugs, reporting GDB reference card GDBHISTFILE gdbserve.nlm gdbserver getDebugChar GNU C++ GNU Emacs h h H8/300 or H8/500 download H8/300 or H8/500 simulator handle handle_exception handling signals hbreak help help target help user-defined heuristic-fence-post (MIPS) history expansion history file history number history save history size history substitution Hitachi Hitachi SH download Hitachi SH simulator i i i/o i386 i386-stub.c i960 if ignore ignore count (of breakpoint) INCLUDE_RDB info info address info all-registers info args info breakpoints info catch info display info f info files info float info frame, info frame info functions info line info locals info proc info proc id info proc mappings info proc status info proc times info program info registers info s info set info share info sharedlibrary info signals info source, info source info sources info stack info target info terminal info threads info types info variables info watchpoints inheritance init file init file name initial frame innermost frame inspect installation instructions, assembly, instructions, assembly Intel internal GDB breakpoints interrupt interrupting remote programs interrupting remote targets invalid input j jump k kill l l languages latest breakpoint leaving GDB linespec list listing machine instructions, listing machine instructions load filename log file for EB29K m m680x0 m68k-stub.c machine instructions, machine instructions maint info breakpoints maint print psymbols maint print symbols make mapped member functions memory models, H8/500 memory tracing memory, viewing as typed object memory-mapped symbol file memset MIPS boards MIPS remote floating point MIPS remotedebug protocol MIPS stack Modula-2 Modula-2 built-ins Modula-2 checks Modula-2 constants Modula-2 defaults Modula-2 operators Modula-2, deviations from Motorola 680x0 multiple processes multiple targets multiple threads n n names of symbols namespace in C++ negative breakpoint numbers New systag next nexti ni Nindy number representation numbers for breakpoints o object formats and C++ online documentation optimized code, debugging outermost frame output output formats overloading overloading in C++ p packets, reporting on stdout partial symbol dump patching binaries path pauses in output pipes pointer, finding referent print print settings printf printing data process image processes, multiple prompt protocol, GDB remote serial ptype putDebugChar pwd q q quit [expression] quotes in commands quoting names r raise exceptions range checking rbreak reading symbols immediately readline readnow redirection reference card reference declarations register stack, AMD29K registers regular expression reloading symbols remote connection without stubs remote debugging remote programs, interrupting remote serial debugging summary remote serial debugging, overview remote serial protocol remote serial stub remote serial stub list remote serial stub, initialization remote serial stub, main routine remote stub, example remote stub, support routines remotedebug, MIPS protocol remotetimeout repeating commands reporting bugs in GDB reset response time, MIPS debugging resuming execution RET retransmit-timeout, MIPS protocol return returning from a function reverse-search run Running running running 29K programs running and debugging Sparclet programs running VxWorks tasks rwatch s s saving symbol table scope search searching section select-frame selected frame serial connections, debugging serial device, Hitachi micros serial line speed, Hitachi micros serial line, target remote serial protocol, GDB remote set set args set assembly-language set check, set check set check range set check type set complaints set confirm set demangle-style set editing set endian auto set endian big set endian little set environment set gnutarget set height set history expansion set history filename set history save set history size set input-radix set language set listsize set machine set memory mod set mipsfpu set output-radix set print address set print array set print asm-demangle set print demangle set print elements set print max-symbolic-offset set print null-stop set print object set print pretty set print sevenbit-strings set print static-members set print symbol-filename set print union set print vtbl set processor args set prompt set remotedebug, set remotedebug set retransmit-timeout set rstack_high_address set symbol-reloading set timeout set variable set verbose set width set write set_debug_traps setting variables setting watchpoints SH sh-stub.c share shared libraries sharedlibrary shell shell escape show show args show check range show check type show commands show complaints show confirm show convenience show copying show demangle-style show directories show editing show endian show environment show gnutarget show height show history show input-radix show language show listsize show machine show mipsfpu show output-radix show paths show print address show print array show print asm-demangle show print demangle show print elements show print max-symbolic-offset show print object show print pretty show print sevenbit-strings show print static-members show print symbol-filename show print union show print vtbl show processor show prompt show remotedebug, show remotedebug show retransmit-timeout show rstack_high_address show symbol-reloading show timeout show user show values show verbose show version show warranty show width show write si signal signals silent sim simulator simulator, H8/300 or H8/500 simulator, Hitachi SH simulator, Z8000 size of screen source source path Sparc sparc-stub.c sparcl-stub.c Sparclet SparcLite speed ST2000 auxiliary commands st2000 cmd stack frame stack on MIPS stacking targets starting STDBUG commands (ST2000) step stepi stepping stopped threads stub example, remote debugging stupid questions switching threads switching threads automatically symbol decoding style, C++ symbol dump symbol names symbol overloading symbol table symbol-file symbols, reading immediately t target target amd-eb target array target bug target byte order target core target cpu32bug target ddb port target e7000 target est target exec target hms target lsi port target mips port target nindy target op50n target pmon port target remote target rom68k target sim, target sim target sparclite target st2000 target udi target vxworks target w89k tbreak TCP port, target remote terminal thbreak this thread apply thread breakpoints thread identifier (GDB) thread identifier (system) thread number thread threadno threads and watchpoints threads of execution threads, automatic switching threads, continuing threads, stopped timeout, MIPS protocol tty type casting memory type checking type conversions in C++ u u UDI udi undisplay unknown address, locating unset environment until up up-silently user-defined command v value history variable name conflict variable values, wrong variables, setting version number VxWorks vxworks-timeout w watch watchpoints watchpoints and threads whatis where while wild pointer, interpreting word completion working directory working directory (of your program) working language writing into corefiles writing into executables wrong values x x XCOFF and C++ z Z8000 simulator { {type} 각주 (1) `b'는 사용될수 없다. 왜냐하면 이들 형식 문자들은 x 명령어에 사용며, `b'는 "byte"를 나타낸다. 메모리 검사하기 섹션을 참조해라. (2) This is a way of removing one word from the stack, on machines where stacks grow downward in memory (most machines, nowadays). This assumes that the innermost stack frame is selected; setting $sp is not allowed when other stack frames are selected. To pop entire frames off the stack, regardless of machine architecture, use return; see section Returning from a function. (3) 만일 여러분이 다른 서비스와 충돌되는 포트 넘버를 선택한다면, gdbserver는 에러 메세지를 출력하고 종료된다. (4) 릴리즈 버전의 `gdb-/gdb/refcard.ps'. (5) 만일 여러분이 최근 버전의 GDB를 가지고 있다면, 소스에 있는 `README'를 봐라.; 우리는 이 매뉴얼을 발표했기 때문에 설치 절차를 갱신해야 한다. This document was generated on 30 May 1999 using the texi2html translator version 1.52.

Posted by 공간사랑

이전 1 ··· 182 183 184 185 186 187 188 ··· 279 다음


	by 공간사랑