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는 여러분이 버그를 잡도록 도와주는 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는 여러분이 이러한 자유를 가진다는 라이센스이고 여러분은 이러한 자유를 그밖의 다른 사람에게서 제한할수 없다.
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에 관한 것을 읽기 위해 여가시간에 이 매뉴얼을 사용할수 있다. 그러나, 약간의 명령어들로만으로도 디버거 사용을 시작하는데 충분하다. 이 장은 이들 명령어들에 대해 기술한다.
이 예제 세션에서, 우리는 주위 출력과 쉽게 구별하기 위해 다음처럼 사용자 입력을 강조한다: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는 여러분이 종료(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
-exec file
-e file
-se file
-core file
-c file
-c number
attach 명령어처럼 프로세스 ID number를 연결해라.
(만일 number 이름의 코어-덤프 포맷 파일이 없다면,
이것은 `-c'에서 읽기 위한 코어 덤프로써 파일을 지정한 경우처럼)
-command file
-x file
-directory directory
-d directory
-m
-mapped
mmap를 통해 시스템에서 이용할
수 있다면, 여러분은 현재 디렉토리에서 여러분의 프로그램을 다시 재사용할수 있는
파일에 심볼들을 쓸수 있는 옵션을 사용할수 있다. 만일 여러분이 디버깅하는
프로그램이 `/tmp/fred'라 불린다면, 대응된 심볼 파일은 `./fred.syms'이다.
앞으로 GDB 디버깅 세션들은 이 파일의 존재를 확인하며 실행 프로그램에서 심볼
파일을 읽기보다 이 파일에서 심볼 정보를 빠르게 대응시킨다.
`.syms'파일은 GDB가 돌아가고 있는 호스트 머신에 의존한다. 이것은 내부
GDB 심볼 테이블의 정확한 이미지를 가진다. 이것은 크로스 다중 호스트 플랫폼에서
공유 될수 없다.
-r
-readnow
-mapped와 -readnow 옵션은 전형적으로 완전한 심볼
정보를 포함하는 `.syms' 파일을 만들기 위해 결합된다.
(정보를 위해서 파일을 지정하기 위한 명령어들를
참조해라.)
앞으로의 사용을 위해 파일 `.syms'는:
gdb -batch -nx -mapped -readnow programname
여러분은 다양한 선택 모드에서 GDB를 돌릴수 있다--예를 들어, 배치모드나 조용한 모드
-nx
-n
-quiet
-q
-batch
0 상태로 종료된다.
만일 에러가 명령어 파일안에 있는 GDB명령어를 실행하는 동안 일어난다면 0이 아닌
상태로 종료된다.
배치 모드는 다운로드나 다른 컴퓨터에서 프로그램을 돌리기 위한 필터로써 GDB를
돌리는데 유용하다.; 더 유용하게 만들기 위해서 메세지가 배치모드에서 돌아갈때는
나타나지 않는다.
(보통 GDB제어하에서 돌아가는 프로그램이 끝날때 나타난다.)
Program exited normally.
-cd directory
-fullname
-f
-b bps
-tty device
quit
quit(간단히 q)를 사용해라.
또는 EOF 문자(보통 C-d)를 타이핑해라.
만일 여러분이 expression를 제공하지 않는다면, GDB는 정상적으로
종료될 것이다; 그렇지 않으면 에러 코드로써 expression의 결과를
사용하고 종료할 것이다.
인터럽트(자주 C-c)는 GDB에서 나가지 않지만 처리중인 GDB명령 작동을 끝내며 GDB 명령어 레벨로 돌아온다. 어떤때든지 인터럽트 문자를 타이핑하는것은 보장된다. 왜냐하면 GDB는 안전한 시간이 될때까지 효과를 가지도록 허용하지 않기 때문이다.
만일 여러분이 연결된 프로세스나 디바이스를 제어하기 위해 GDB를 사용한다면,
여러분은 detach명령어를 가지고 놓아주어야 한다.
(이미 돌고 있는 프로세스 디버깅하기섹션을
참조해라.)
만일 여러분이 디버깅 세션동안 경우에 따라 shell 명령어를 실행할 필요가 있다면,
GDB를 나가거나 일시중지할 필요가 없다; 여러분은 단지 shell 명령어를
사용할수 있다.
shell command string
SHELL는 기동될 shell을
결정한다. 그렇지 않으면 GDB는 /bin/sh를 사용한다.
make는 개발 환경에서 자주 필요하다.
여러분은 GDB에서 이 목적을 위해 shell명령어를 사용할 필요가 없다:
make make-args
make 프로그램을 실행해라.
이것은 `shell make make-args'와 같다.
여러분은 축약형이 모호하지 않다면 명령어 이름의 처음 몇자로 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
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
show copying
show warranty
여러분이 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
run 명령어를 사용해라.
여러분은 우선 프로그램 이름(VxWorks를 제외하고)을 지정하거나 file
나 exec-file 명령어를 사용해서 지정해야 한다.(파일을 지정하기 위한 명령어들 섹션을 참조해라.)
만일 여러분이 프로세스를 지원하는 실행 환경하에서 프로그램을 돌린다면,
run은 하위 프로세스를 만들고, 그 프로세스가 여러분의
프로그램하에서 돌아가도록 만든다.
(프로세스가 없는 환경에서, run은 프로그램을 시작하기 위해
이동한다.)
프로그램의 실행은 상위 프로세스에서 받은 정보에 의해 영향을 받는다. GDB는 이 정보를 제공하기 위한 방법을 제공하며, 여러분은 프로그램을 시작하기 전에 해야 한다.(여러분은 프로그램을 시작한 후 바꿀수 있지만, 그런 변화는 프로그램을 시작하는 다음 번부터 영향을 준다.) 이 정보는 4개의 범주로 나누어 진다.
run 명령어의 인자로써 프로그램에 주기 위한 인자를 지정한다.
만일 shell을 여러분의 타겟에서 이용할수 있다면, shell은 인자를 전달하기 위해
사용되며 여러분은 인자를 기술할때 편하게(wildcard 확장이나 변수 치환) 사용할수
있다. Unix 시스템에서, 여러분은 SHELL 환경 변수에서 사용된
shell을 제어할수 있다. 프로그램 인자들 섹션을
참조해라.
set environment 와
unset environment를 사용할수 있다.
프로그램 환경섹션을 참조해라.
cd명령어를 사용하여 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
environment는 환경 변수들하고 값들로 이루어진다. 환경 변수들은 여러분의 사용자 이름, 홈 디렉토리, 터미널 타입 그리고 돌리는 프로그램의 탐색 경로등을 기록한다. 보통 여러분은 shell에서 환경 변수를 설정한다. 그리고 여러분이 돌리는 다른 프로그램 모두에 의해 상속된다. 디버깅때, 다시 GDB를 시작 하는것 없이 수정된 환경 변수로 여러분의 프로그램을 돌리는데 유용하다.
path directory
PATH 환경 변수(실행을 위한 탐색
경로)앞에 directory를 추가한다.
여러분은 `:'나 whitespace로 분리되는 몇몇 디렉토리 이름을
지정해야 한다.
만일 directory가 경로에 이미 있다면, 앞으로 이동시키고 빨리 찾게
된다.
여러분은 GDB가 경로를 탐색할때 현재 작업 디렉토리가 무엇인지를 참조하기 위해
`$cwd'를 사용할수 있다.
만일 여러분이 `.'를 사용한다면, 그것은 여러분이 path
명령어를 실행하는 디렉토리를 가리킨다. GDB는 탐색 경로에 directory를
추가하기 전에 directory 인자(현재 경로를 가지고 있는)에 있는
`.'를 바꾼다.
show paths
PATH 환경 변수)
show environment [varname]
env로써
environment를 축약할수 있다.
set environment varname [=] value
set env USER = fooUnix 프로그램에게 사용자의 이름은 `foo'이라고 말하는 것이다. (`='근처의 스페이스는 여기서 명확히 사용되었다; 그들은 실제로 요구되지는 않는다.)
unset environment 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
pwd
기본적으로, GDB에서 여러분이 돌리는 프로그램은 GDB가 사용하는 같은 터미널에 입력과 출력을 한다. GDB는 터미널을 여러분과 대화하기 위한 모드로 바꾼다. 그러나 GDB는 프로그램이 사용하는 터미널 모드를 기록한뒤 여러분이 프로그램을 다시 돌릴때 다시 바꾼다.
info terminal
여러분은 run 명령어시 가지는 shell 리다이렉션을 사용하여
프로그램의 입력과 추력을 리다이렉션 할수 있다.
예를 들어,
run > outfile
프로그램을 시작하면, 출력을 `outfile'으로 돌린다.
프로그램의 입력과 출력을 지정하기 위한 또 다른 방법은 tty
명령어이다. 이 명령어는 인자로 파일 이름을 가지며 다음 run
명령어시 기본적으로 이 파일을 사용한다. 또한 이것은 다음 run 명령어를 위해,
자식 프로세스를 위한 터미널 제어를 리셋한다.
예를 들어,
tty /dev/ttyb
연속적인 run 명령어를 가지고 시작하는 프로세스들은 터미널
`/dev/ttyb'에 입력과 출력을 하며 제어 단말기로써 이것을 사용한다.
run에서의 명백한 리다이렉션은 tty 명령어를 무효화
시키고 입출격 장치에서 효과을 가진다. 그러나 제어 단말기에서난 효과가 없다.
여러분이 tty명령어나 run명령어에서 입력을 리다이렉션 시킬때,
여러분의 프로그램를 위한 입력만이 영향을 받는다. GDB에서의 입력은 여전히 단말기에서 나온다.
attach process-id
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
detach 명령어를 사용해야 한다. 프로세스를 떼어내도 실행은 계속된다. detach 명령어 후, 프로세스와 GDB는 완전히 독립적이되며 여러분은
다른 프로세스를 attach 시키거나 run로 프로세스를
시작할수 있다. 여러분이 명령어 실행후 다시 RET를 누른다면
detach는 반복되지 않는다.
여러분이 GDB를 나가거나 부착시킨 프로세스를 가지고 있는 동안 run
명령어를 사용하면, 여러분은 그 프로세스를 죽여야 한다. 기본적으로, GDB는
여러분이 이것들 중 하나를 했는지를 확신하기 위해 질의한다.; 여러분은 set
confirm명령어를 사용하여 확실히 할 필요가 있는지 없는지를 제어할수
있다.(경고 옵션들과 메세지들 섹션을
참조해라.)
kill
만일 여러분이 돌아가고 있는 프로그램 대신 코어 덤프를 디버깅하려고 한다면 이 명령어는 유용하다. 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
info proc 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) 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
(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
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는 그게 다시 가능하게 될때까지 프로그램에 영향을 주지 않는다.
Breakpoint는 break 명령어(간단히 b)로 설정한다.
디버거 편리 변수 `$bpnum'는 여러분이 가장 최근 설정한 breakpoint의
수를 기록한다; 여러분이 편리변수 가지고 할수 있는 것이 무엇인지를 토론하길 원한다면 편리 변수 섹션을 참조해라.
여러분은 breakpoint가 어디인지를 말하기 위해 여러가지 방법을 사용할수 있다.
break function
break +offset
break -offset
break linenum
break filename:linenum
break filename:function
break *address
break
break는 선택된 스택 프레임에서 실행되고
있는 다음 명령어에 breakpoint를 설정한다.(스택 검사하기 섹션을 참조해라.) 선택된 프레임에서, 이것은 제어가 그 프레임으로 돌아오자
마자 프로그램을 멈추도록 만든다. 이것은 선택된 프레임 내 프레임에서 finish 명령어에 의한 결과와 비슷하다.--이 finish는 breakpoint를
활성화 시켜 놓지 않는다는것을 제외하고.
만일 여러분이 가장 내부 프레임에 인자 없이 break를 사용한다면,
GDB는 현재 위치에 도달하는 다음번에 멈춘다; 이것은 루프내에서 유용하다.
GDB는 보통 실행을 계속할때 적어도 한개의 명령어가 실행될때까지 breakpoint를
무시한다. 만일 이것을 하지 않는다면, 여러분은 breakpoint를 disable 시키는것
없이 brekapoint를 빠르게 처리할수 없다.
이 규칙은 프로그램이 멈출때 breakpoint가 이미 존재하든지 안하든지 적용된다.
break ... if cond
tbreak args
break 명령어와 같으며, breakpoint는 같은 방법으로
설정된다. 그러나 breakpoint는 자동적으로 프로그램이 한번 멈춘 다음에 지워진다.
breakpoints disable하기 섹션을 참조해라.
hbreak args
break 명령어와
같으며 breakpoint는 같은 방법으로 설정된다. 그러나 breakpoint는 하드웨어 지원을
요구하며 몇몇 하드웨어 타겟은 이러한 지원을 하지 않는다.
이 명령어의 주요 목적은 EPROM/ROM 코드 디버깅이며, 여러분은 명령어를 바꾸는것
없이 명령어에 breakpoint를 설정할수 있다. 이 명령어는 SPARClite DSU가 제공하는
새로운 trap-발생시 사용될수 있다.
DSU는 프로그램이 몇몇 데이터나 레지스터를 디버깅하기 위해 할당된 명령어 주소를
접근할때 trap을 발생한다. 그러나 하드웨어 breakpoint 레지스터는 두개의 데이터
breakpoint를 가지며 GDB는 두개 이상이 사용된다면 이 명령어를 거절한다.
새로운 것으로 설정하기 전에 사용되지 않는 하드웨어 breakpoint를 delete 하거나
disable 한다. Break conditions 섹션을 참조해라.
thbreak args
hbreak 명령어와 같으며 breakpoint는 같은 방법으로
설정된다. 그러나, tbreak 명령어처럼, breakpoint는 자동적으로 프로그램이
처음 멈춘다음에 지워진다. 또한, hbreak 처럼, breakpoint는 하드웨어
지원을 요구하며 몇몇 타겟 하드웨어는 이러한 지원을 하지 않는다.
breakpoints disable하기 섹션을 참조해라.
또한, Break 조건들 섹션을 참조해라.
rbreak regex
break 명령어로 설정된 breakpoint처럼 처리된다.
여러분이 그것을 지우고, disable하거나 다른 breakpoint처럼 조건적인 같은 방법으로
만들수 있다.
C++ 프로그램을 디버깅할때, rbreak는 어떤 특정 클래스의 멤버가 아닌
오버로딩된 함수에 breakpoint를 설정할때 유용하다.
info breakpoints [n]
info break [n]
info watchpoints [n]
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
breakpoint
watchpoint
longjmp
longjmp 호출을 통해 정확한 stepping을 처리하기 위해 사용된 내부 breakpoint
longjmp resume
longjmp의 타겟에 내부 breakpoint
until
until 명령어에 의해 사용되는 임시 내부 breakpoint.
finish
finish 명령어에 의해 사용되는 임시 내부 breakpoint.
여러분이 변화가 일어날곳을 예상하는것 없이 표현식 값이 바뀔때마다 실행을 멈추고자 하면 watchpoint를 사용할수 있다.
Watchpoint는 현재 다른 breakpoint보다 더 천천히 2배의 규모로 실행된다. 그러나 이것은 프로그램의 어느 부분이 잘못되었는지 실마리를 잡지 못할때 에러를 잡기 위한 충분한 가치가 있다.
watch expr
watch 명령어로,
rwatch 명령어로,
또는 awatch 명령어로 두개의 watchpoint를 설정할수 있다.
그러나 여러분은 한 명령어아 다른 이름으로 다른 명령어로 한개의 watchpoint를 설정할수
없다.
만일 여러분이 watchpoint를 섞는다면 명령어는 거절될 것이다.
새로운 것으로 설정하기전에 사용되지 않은 watchpoint 명령어를 지우거나 disable해라.
rwatch expr
rwatch 명령어로
설정되어야 한다.
awatch expr
awatch 명령어로
설정되어야 한다.
info watchpoints
info break와 같다.
경고: 멀티-쓰레드 프로그램에서, watchpoint는 그 유용성이 제한된다. 현재 watchpiont 수행에서, GDB는 단일 쓰레드의 표현식 값만을 볼수 있다. 만일 여러분이 표현식이 현재 쓰레드의 활성화(그리고 만일 여러분이 어떤 다른 쓰레드도 현재 쓰레드가 될수 없다고 확신한다면)때문에 바뀐다고 확신한다면, 여러분은 보통때처럼 watchpoint를 쓸수 있다. 그러나, GDB는 현재 쓰레드가 아닌 쓰레드의 활성화가 표현식을 바꿀 때 인식하지 못한다.
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를 사용할수 있다.
breakpoint나 watchpoint가 작업을 마치고 더이상 거기에서 멈추길 원하지 않는다면 삭제하는것이 가끔 필요하다. 이것을 breakpoint 지우기라고 한다. 삭제된 breakpoint는 더이상 존재하지 않는다; 잊혀진다.
clear명령어로 여러분은 프로그램에 있는곳에 따라 breakpoint를
지울수 있다. delete명령어로 여러분은 breakpoint넘버를 지정하여
개개의 breakpoint나 watchpoint를 지울수 있다.
예전것을 위해 brekapoint를 지울 필요는 없다. GDB는 여러분이 실행 주소를 바꾸지 않고 실행을 계속할 경우 실행의 처음 명령어에 있는 breakpoint를 자동적으로 무시한다.
clear
clear function
clear filename:function
clear linenum
clear filename:linenum
delete [breakpoints] [bnums...]
set confirm off를
설정하지 않았다면 GDB는 확인을 요구한다.) 여러분은 d로 명령어를
축약할수 있다.
breakpoint나 watchpoint를 지우기 보다, 여러분은 그것들을 disable 시키는 것이 더 좋다. 이것은 마치 지워진것처럼 breakpoint가 작동하지 않도록 만든다. 그러나 breakpoint에 대한 정보를 기억한다. 그래서 여러분은 나중에 다시 그것을 enable 시킬수 있다.
여러분은 옵션으로 인자로 하나나 그 이상의 breakpoint를 지정하여, enable, disable 명령어로 breakpoint와 watchpoint를 disable, enable
시킬수 있다. 만일 여러분이 사용하고 있는 넘버를 알지 못한다면, breakpoint나
watchpoint의 리스트를 보기 위해 info break나 info watch를 사용해라.
breakpoint나 watchpoint는 4가지의 다른 가능 상태를 가지고 있다.
break로 설정한 breakpoint
는 이상태로 시작한다.
tbreak를 가지고 설정된 breakpoint는 이 상태로 시작한다.
여러분은 breakpoint와 watchpoint를 enable, disable 시키기 위해 다음 명령어를 사용할수 있다:
disable [breakpoints] [bnums...]
dis로 disable를 축약할수 있다.
enable [breakpoints] [bnums...]
enable [breakpoints] once bnums...
enable [breakpoints] delete bnums...
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
condition을 사용할때, GDB는 즉시 문법이 맞는지를 위해
expression를 검사한다. 그리고 심볼들이 여러분의 breakpoint의 문맥에
참조를 가지고 있는지를 결정한다. GDB는 실제 condition명령어가
주어질때마다 expression을 평가하지 않는다.
Expressions 섹션을 참조해라.
condition bnum
breakpoint 조건의 특별한 경우는 breakpoint가 어떤 넘버의 카운트에 도착할때만 멈추는 경우이다. 이것은 매우 유용해서 breakpoint의 ignore count를 사용하여 그것을 할수 있다. 모든 breakpoint는 정수로써 ignore count를 가지고 있다. 경우의 대두분에서, ignore count는 0이고 그래서 효과가 없다. 그러나 여러분의 프로그램이 ignore count가 양수인 breakpoint에 도착한다면, 프로그램은 멈추는 대신 ignore count를 하나 줄이고 계속한다. 결과적으로 ignore count 값이 n이라면, breakpoint는 여러분의 프로그램이 도착할 다음번 n에서는 멈추지 않는다.
ignore bnum count
continue를
사용할때, 여러분은 ignore사용대신 continue에 인자로써 직접 ignore count를 지정 할수 있다.
계속과 단계(stepping)섹션을 참조해라.
만일 breakpoint가 양수의 ignore count와 조건들 가진다면, 조건은 검사되지 않는다.
일단 ignore count가 0에 도달하면, GDB는 조건 검사를 다시 시작한다.
여러분은 매번 감소하는 편리변수를 사용하여 `$foo-- <= 0' 같은
조건을 가지고 ignore count의 효과를 볼수 있다.
편리 변수들섹션을 참조해라.
breakpoint 때문에 프로그램의 실행을 멈출때 breakpoint(또는 watchpoint) 명령어들을 사용할수 있다. 예를 들어, 여러분은 어떤 표현식이나 활성화된 다른 breakpoint의 값을 출력하길 원할지 모른다.
commands [bnum]
... command-list ...
end
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
몇몇 프로그래밍 언어(주로 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]
ignore와 같다.(Break 조건들 섹션을 참조해라.)
인자 ignore-count는 프로그램이 breakpoint 때문에 중지할때만 의미가
있다. 다른때, continue를 위한 인자들은 무시된다.
c와 fg는 편위를 위해서만 제공되며 continue와 정확히 같은 행동을 한다.
다른 위치에서 실행을 다시 시작하기 위해, 여러분은 호출 함수로 다시 가기 위해
return(함수에서 리턴
섹션을 참조해라.)을 사용할수 있다.; 또는 프로그램의 임의의 위치로 가기 위해
jump(다른 주소에서 계속하기섹션을 참조해라.)를 사용해라.
stepping을 사용하는 전형적인 기술은 함수의 시작이나 문제가 있는 프로그램 섹션에 breakpoint(Breakpoints, watchpoints, 그리고 exceptions 섹션을 참조해라.)를 설정하는 것이다. 그리고 breakpoint에서 멈출때까지 프로그램을 돌리고 의심스러운 위치에서 step을 밝아가고 프로그램에 문제가 발생할때까지 흥미가 있는 변수를 검사하는 것이다.
step
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
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
break에서 받아들일수 있는 인자
형태이다.(Setting breakpoints 섹션을 참조해라.)
명령어 형태는 breakpoint를 사용한다. 그래서 인자가 없을경우 until
빠르다.
stepi
si
step처럼 반복 횟수이다.
nexti
ni
next처럼 반복수이다.
신호는 프로그램내 발생하는 비동기적 사건이다. OS는 가능한 종류의 신호를
정의하며 각 종류의 이름과 숫자를 준다. 예를 들어, Unix에서 SIGINT는 여러분이 인터럽트를 타이핑(C-c)할때 프로그램이 갖는 신호이다.;
SIGSEGV는 사용할수 있는 메모리 영역 이외의 장소를 참조할때 프로그램이 갖는 신호이다.; SIGALRM는 alarm 클럭 타이머가 꺼질때 생긴다.
(만일 여러분의 프로그램이 알람을 가진경우에만)
SIGALRM을 포함한 몇몇 신호들은 프로그램 함수들중 일부분이다.
SIGSEGV 처럼, 다른것들은 에러를 가리킨다.; 이들 신호는 미리 이들
신호를 처리하는 다른 방법을 지정하지 않았다면 치명적(프로그램은 즉시 죽는다)이다. SIGINT는 프로그램에서 에러를 가리키는것은 아니지만
보통 치명적이어서 프로그램을 죽이기 위한 인터럽트의 목적으로 실행한다.
GDB는 프로그램내 신호의 발생을 발견할 능력이 있다. 여러분은 신호의 종류 마다 해야할것을 미리 GDB에게 말할수 있다.
보통, GDB는 에러신호가 발생할때마다 즉시 프로그램을 멈추게 하기 위해서
SIGALRM과 같은 에러가 아닌 신호들은 무시하도록 설정한다.
(프로그램의 함수내 역할을 방해하지 않는 한)
여러분은 handle명령어를 가지고 이들 설정을 바꿀수 있다.
info signals
info handle는 info signals에 대한 별명이다.
handle signal keywords...
handle 명령어에 의해 허용되는 키워드는 줄일수 있다.
완전한 이름은:
nostop
stop
print 키워드
를 암시한다.
print
noprint
nostop 키워드 를 암시한다.
pass
nopass
신호가 프로그램을 멈출때, 신호는 여러분이 continue할때까지 볼수 없다.
만일 pass가 그때 신호의 영향하에 있다면 프로그램은 신호를 볼수 있다.
즉, GDB가 신호를 보고한후 여러분이 continue할때 프로그램이 신호를 볼수 있는지
없는지를 제어하기 위해 pass나 nopass 명령어와 함께
handle을 사용할수 있다.
여러분은 또한 프로그램이 신호를 보는걸 막기 위해서나 볼수 없는 신호를 보도록 하거나 어떤때든지 신호을 주도록 하기 위해 signal 명령어를 사용할수 있다. 예를 들어, 프로그램이 메모리 참조 에러때문에 멈춘다면, 여러분은 더 실행
되길 원해서 정확한 값을 에러 변수에 넣고 continue할수 있다.;그러나 프로그램은
아마 신호를 보자 마자 치명적 신호의 결과처럼 즉시 죽을 것이다. 이것을 막기 위해, 여러분은 `signal 0'을 가지고 계속해야 한다. 프로그램에 신호 주기 섹션을 참조해라.
여러분이 다중 쓰레드를 가질때(다중 쓰레드 프로그램 디버깅하기 섹션을 참조해라.), 여러분은 모든 쓰레드나 특정 쓰레드에 breakpoint를 설정할지 안할지를 선택할수 있다.
break linespec thread threadno
break linespec thread threadno if ...
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
버전 이다.
backtrace는 여러분의 프로그램이 어떻게 돌아간는지에 대한 요약이다. 현재 실행되는 프레임(프레임 0)에서 시작하여 호출자(프레임 1)가 뒤따라오고 그리고 스택위에 있는 많은 프레임을 위해 프레임당 한라인을 보여준다.
backtrace
bt
backtrace n
bt n
backtrace -n
bt -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
main 이다.
frame addr
f addr
frame 는 임의의 프레임을 선택하기 위해 2개의
주소가 필요하다.; 프레임 포인터와 스택 포인터.
MIPS와 Alpha 아키텍쳐에서도 2개의 주소가 필요하다: 스택 포인터와 프로그램 카운터.
29k 아키텍쳐에서는 3개의 주소가 필요하다: 레지스터 스택 포인터, 프로그램 카운터,
그리고 메모리 스택 포인터.
up n
down 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
frame 명령어에서 기술한 같은 종류의 주소를 요구한다.(몇몇 아키텍쳐를 위해 1개 이상).
프레임 선택하기. 섹션을 참조해라.
info args
info locals
info catch
up, down frame 명령어들); 그리고 info catch 를 타입핑해라.
Breakpoints 와 예외 섹션을 참조해라.
MIP 기반 컴퓨터는 특이한 스택 프레임을 사용한다. 이것은 가끔 함수 시작을 발견하기 위해 객체 코드에서 뒤로 찾도록 GDB 를 요구한다.
응답 시간(특히 GDB가 탐색을 위해 탐색 라인을 느리게 제한하는 내장형 응용프로그램에서)을 향상시키기 위해, 여러분은 다음 명령어들중 하나를 사용하여 탐색의 크기를 제한하길 원할지도 모른다.:
set heuristic-fence-post limit
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
list 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
list first,last
list ,last
list first,
list +
list -
list
여기에 단일 소스 라인을 지정하는 방법이 있다--모든 종류의 linespec
number
+offset
list 명령어에서 두번째 linespecs처럼 사용될때, 이것은 처음
linespec에서 아래쪽으로 offset 라인을 지정한다.
-offset
filename:number
function
filename:function
*address
정규식 표현식을 위해 현재 소스 파일 탐색을 위해 두개의 명령어가 있다.
forward-search regexp