GDB를 이용한 디버깅

GNU 소스-레벨 디버거

Fifth Edition, for GDB version

April 1998

Richard M. Stallman and Roland H. Pesch
초벌 번역 : 정강훈


차례


Copyright (C) 1988, 1989, 1990, 1991, 1992, 1993, 1994, 1995, 1996, 1997, 1998 Free Software Foundation, Inc.

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) 명령어를 사용하여 해당 서브루틴으로 들어간다. stepany 서브루틴에서 실행되기 위해 다음 라인으로 들어 간다. 그래서 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_lquotelen_rquote를 설정하는 마지막 두 라인으로 가서 이들 변수값을 검사하자.

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

len_lquotelen_rquote가 각각 lquoterquote의 길이라고 가정할때 그것은 확실히 이상하게 보인다. 우리는 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를 돌려 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)는 이 방법으로 반복되지 않는다; 이들 명령어는 문제를 야기할수 있고 반복을 원하지 않는 명령어들이다.

listx명령어는 여러분이 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 명령어 infoshow를 사용할수 있다. 각 명령어는 질의를 위해 많은 것을 제공한다; 이 매뉴얼은 적당한 문맥에서 각 명령어들을 소개한다. 색인에서 infoshow아래에 있는 리스트들은 모든 하위 명령어들을 가리킨다. 색인 섹션을 참조해라.

info
이 명령어(간단히 i)는 프로그램의 상태를 기술한다. 예를 들어, 여러분은 info args로 프로그램에 주어진 인자들을 볼수 있고, info registers를 사용하여 현재의 모든 레지스터들을 나열할수 있으며, info breakpoints으로 설정한 breakpoint들을 볼수 있다. 여러분은 help infoinfo 하위 명령어의 모든 리스트를 볼수 있다.
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를 제외하고)을 지정하거나 fileexec-file 명령어를 사용해서 지정해야 한다.(파일을 지정하기 위한 명령어들 섹션을 참조해라.)

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

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

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

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

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
환경 변수 varnamevalue로 설정한다. 이 값은 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 procprocfs를 지원하는 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는 다중 쓰레드 프로그램을 디버깅할수 있는 기능을 제공한다.

경고: 이 기능은 쓰레드를 지원하는 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는 다음 순서로 각 쓰레드를 출력한다.:
  1. GDB에 의해 대입된 쓰레드 넘버
  2. 타겟 시스템의 쓰레드 식별자(systag)
  3. 그 쓰레드를 위한 현재 스택 프레임 요약
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. argsbreak 명령어와 같으며, breakpoint는 같은 방법으로 설정된다. 그러나 breakpoint는 자동적으로 프로그램이 한번 멈춘 다음에 지워진다. breakpoints disable하기 섹션을 참조해라.
hbreak args
하드웨어-지원 breakpoint를 설정한다. argsbreak 명령어와 같으며 breakpoint는 같은 방법으로 설정된다. 그러나 breakpoint는 하드웨어 지원을 요구하며 몇몇 하드웨어 타겟은 이러한 지원을 하지 않는다. 이 명령어의 주요 목적은 EPROM/ROM 코드 디버깅이며, 여러분은 명령어를 바꾸는것 없이 명령어에 breakpoint를 설정할수 있다. 이 명령어는 SPARClite DSU가 제공하는 새로운 trap-발생시 사용될수 있다. DSU는 프로그램이 몇몇 데이터나 레지스터를 디버깅하기 위해 할당된 명령어 주소를 접근할때 trap을 발생한다. 그러나 하드웨어 breakpoint 레지스터는 두개의 데이터 breakpoint를 가지며 GDB는 두개 이상이 사용된다면 이 명령어를 거절한다. 새로운 것으로 설정하기 전에 사용되지 않는 하드웨어 breakpoint를 delete 하거나 disable 한다. Break conditions 섹션을 참조해라.
thbreak args
한번 멈추는것이 가능하도록 하드웨어-지원 breakpoint를 설정한다. argshbreak 명령어와 같으며 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내에 예외 처리를 위해 몇몇 제한들이 있다.:

가끔 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 breakinfo watch를 사용해라.

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

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

disable [breakpoints] [bnums...]
지정된 breakpoint를 Disable 시킨다--만일 어떤것도 리스트되지 않았다면, 모든 breakpoit가 해당된다. disabled breakpoint는 효과는 없지만 잊혀지지는 않는다. ignore-count, condition과 같은 옵션과 명령어들은 breakpoint가 enable될때 다시 기억된다. 여러분은 disdisable를 축약할수 있다.
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 넘버 bnumcount로 설정한다. 다음 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 또는 실행을 다시 시작 시키는 다른 명령어를 사용해라.

실행을 시작하는 명령어후, 명령어 리스트내 다른 명령어들은 무시된다. 이것은 여러분이 실행을 다시 시작하는 때(단순히 nextstep일때조차)에, 여러분이 다른 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를 위한 인자들은 무시된다. cfg는 편위를 위해서만 제공되며 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으로 축약할수 있다. 인자 countstep처럼 반복 횟수이다. 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
지정된 위치에 도착하든지 현재 스택 프레임이 반환될때까지 프로그램 실행을 계속한다. locationbreak에서 받아들일수 있는 인자 형태이다.(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 handleinfo 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할때 프로그램이 신호를 볼수 있는지 없는지를 제어하기 위해 passnopass 명령어와 함께 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 프레임만을 출력한다.

이름 whereinfo 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.c993 라인에서 멈추었다는 것을 가리킨다.

프레임 선택하기

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

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에서, 이것은 안쪽 프레임쪽으로, 낮은 프레임 수쪽으로 , 가장 최근에 만들어진 프레임쪽으로 나아간다. 여러분은 downdo 로 간단히 할수 있다.

이들 명령어들 모두는 프레임을 설명하는 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
이들 두 명령어는 updown의 변종이다.; 그들은 새 프레임을 출력하지 않고 조용히 작업하는것이 다르다. 이들 명령어는 출력이 필요 없고 혼란스럽게 출력되는 때에 사용하기 위한 것이다.

프레임에 관한 정보

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

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가 출력하는 라인 넘버를 출력한다.

RETlist 명령어를 반복하는 것은 해당 인자를 무시하는것이 된다. 그래서 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는 가끔 잘못된 버전의 소스를 발견하여 혼란을 야기할수도 있다. 여러분은 다음처럼 상황을 바로 잡을수 있다:

  1. 소스 경로를 깨끗하게 하기 위해 인자 없이 directory를 사용해라.
  2. 여러분이 원하는 소스 경로에 디렉토리를 다시 인스톨하기 위해 적당한 인자를 주어 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
이 명령어는 disassemblex/i 명령어를 통해 프로그램을 역어셈블할때 사용하기 위한 명령어를 선택한다. 이 명령어는 한개 이상의 네이티브 명령어 집합을 가지고 있는 아키텍쳐에서 유용하다. 현재 Intel x86 패밀리를 위해서만 정의되어 있다. 여러분은 i386i8086instruction-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 주위에 있는지에 상관없이 허용된다.

프로그램 변수들

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

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

또는

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

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진수) 이다. 기본 값은 여러분이 xprint를 사용할때마다 바뀐다.
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

이 디스플레이는 항목 수, 표현식 그리고 현재 값을 보여준다. 여러분이 xprint 을 사용하여 여러 요구를 디스플레이 하듯이, 여러분은 여러분이 원하는 출력 형식을 지정 할수 있다. ; 사실, display 는 여러분의 형식 지정에 따라서 printx 를 사용할지를 결정한다. -- 여러분이 단위 크기를 지정하거나 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 값 히스토리에 저장된다. 이것은 다른 표현식에서 이 값들을 사용하길 허용한다. 값들은 심볼 테이블이 다시 읽혀지거나 버려질때까지 유지된다.(예로 filesymbol-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 lineinfo 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로 만들었지만 다른 언어로 쓰여진 cfrontf2c같은 프로그램을 사용할때 가장 일반적인 문제이다. 그 경우, 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'를 사용해라. 여기서 langcmodula-2같은 언어 이름이다. 지원 언어의 리스트를 보고 싶으면, `set language'를 타이핑해라.

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

print a = b + c

위 명령어는 여러분이 의도한 대로 되지 않는다. C에서, 이것은 bc를 더하고 결과를 a에 놓는다. 출력 결과는 a 값이된다. Modula-2에서, 이것은 ab+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는 intstruct 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++을 위해, 다음 정의들이 있다:

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

,
컴마나 순차 연산자. 컴마로 분리되어 나열된 표현식은 왼쪽에서 오른쪽으로 평가된다.
=
대입. 대입 표현식 값은 대입된 값이다. 스칼라 타입으로 정의되어 있다.
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는 두개를 같은것으로 간주하며, 저장된 타입의 정보에 기반하여 역참조 포인터인지 어떤지를 선택한다. structunion 데이터에서 정의된다.
[]
배열 인덱스. a[i]*(a+i)처럼 정의된다. ->과 연산순위가 같다.
()
함수 파라미터 리스트. ->과 연산순위가 같다.
::
C++ 범위 연산자. struct, union, 그리고 class 타입에서만 정의된다.
::
더블 콜론 또한 GDB 범위 연산자로 표시된다. (Expressions 섹션을 참조해라.). 위의 ::과 연산순위가 같다.

C , C++ 상수들

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