The testsuite is an important component of the GDB package. While it is always worthwhile to encourage user testing, in practice this is rarely sufficient; users typically use only a small subset of the available commands, and it has proven all too common for a change to cause a significant regression that went unnoticed for some time.
testsuite는 GDB 패키지의 중요한 컴포넌트이다. 이것이 사용자 테스트를 격려할정도의 가치는 있지만, 실제로는 충분하지는 않다.; 사용자들은 전형적으로 이용가능한 명령어 집합만을 사용하며 변화를 위한 일반적인것들은 얼마시간동안은 인식하지 못하는 중요한 후퇴를 야기한다.
The GDB testsuite uses the DejaGNU testing framework.
DejaGNU is built using Tcl and expect. The tests
themselves are calls to various Tcl procs; the framework runs all the
procs and summarizes the passes and fails.
GDB testsuite는 DejaGNU testing framework을 사용한다.
DejaGNU는 Tcl와 expect를 사용하여 만들어졌다.
그것들 테스트는 다양한 Tcl procs을 호출하는것이다;
framework은 모든 procs에서 돌아가며 전달할것을 요약하고 실패한다.
To run the testsuite, simply go to the GDB object directory (or to the
testsuite's objdir) and type make check. This just sets up some
environment variables and invokes DejaGNU's runtest script. While
the testsuite is running, you'll get mentions of which test file is in use,
and a mention of any unexpected passes or fails. When the testsuite is
finished, you'll get a summary that looks like this:
testsuite룰 돌리기 위해, GDB 객체 디렉토리(또는 testsuite objdir)로 가서
make check를 타이핑해라. 이것은 몇몇 환경 변수와 DejaGNU runtest 스크립트를 호출한다. testsuite를 돌리는 동안, 여러분은 어떤 test
파일이 사용중인지 예상치 못한 pass나 fail에 대한 내용을 얻을수 있다.
testsuite가 끝나면, 여러분은 다음과 같은 요약을 가진다.:
=== gdb Summary ===
# of expected passes 6016
# of unexpected failures 58
# of unexpected successes 5
# of expected failures 183
# of unresolved testcases 3
# of untested testcases 5
The ideal test run consists of expected passes only; however, reality conspires to keep us from this ideal. Unexpected failures indicate real problems, whether in GDB or in the testsuite. Expected failures are still failures, but ones which have been decided are too hard to deal with at the time; for instance, a test case might work everywhere except on AIX, and there is no prospect of the AIX case being fixed in the near future. Expected failures should not be added lightly, since you may be masking serious bugs in GDB. Unexpected successes are expected fails that are passing for some reason, while unresolved and untested cases often indicate some minor catastrophe, such as the compiler being unable to deal with a test program.
이상적인 test는 예상된 pass로만 구성되어 돌아간다.; 그러나 현실은 우리가 이러한 이상적인 테스트를 하도록 한다. 예상치 못한 failure는 GDB나 testsuite에서 실제 문제를 가리킨다. 예상된 실패는 여전히 실패지만, 결정된 것들은 그때 처리하기 너무 어렵다.; 예를 들어, test 경우는 AIX를 제외하고는 어디서든 작동하며 AIX 경우는 가까운 미래에 고쳐질것으로는 기대되지 않는다. 에상된 failure는 간단히 추가되어서는 안된다. 왜냐하면 여러분은 GDB내 심각한 버그를 mask하기 때문이다. 예상치 못한 성공은 몇몇 이유때문에 fail할것으로 예상된다. 반면 해석하지 못하거나 테스트되지 못한 경우는 test 프로글매을 다루지 못하는 컴파일러 같이 몇몇 큰 실패를 가리킨다.
When making any significant change to GDB, you should run the testsuite before and after the change, to confirm that there are no regressions. Note that truly complete testing would require that you run the testsuite with all supported configurations and a variety of compilers; however this is more than really necessary. In many cases testing with a single configuration is sufficient. Other useful options are to test one big-endian (Sparc) and one little-endian (x86) host, a cross config with a builtin simulator (powerpc-eabi, mips-elf), or a 64-bit host (Alpha).
GDB에 중요한 변경사항을 작업할때, 여러분은 예전으로 회복시키는 것 없이 확실히 하기 위해 변경사항 전후에 testsuite를 돌려야 한다. 사실 완전한 testing은 모든 지원 설정 사항과 다양한 컴파일러를 가진 testsuite를 돌려야만 얻을수 있다.; 그러나 이것은 실제로 필요한것 이상이다. 많은 경우, 단일 설정 사항을 가진 testing만으로도 충분하다. 다른 유용한 옵션들은 big-endian(Sparc)과 little-endian(x86) 호스트, builtin simulator(powerpc-eabi, mips-elf)를 가진 cross 설정 또는 64 비트 호스트(Alpha)에서 테스트 하는 것이다.
If you add new functionality to GDB, please consider adding tests for it as well; this way future GDB hackers can detect and fix their changes that break the functionality you added. Similarly, if you fix a bug that was not previously reported as a test failure, please add a test case for it. Some cases are extremely difficult to test, such as code that handles host OS failures or bugs in particular versions of compilers, and it's OK not to try to write tests for all of those.
만일 여러분이 GDB에 새로운 기능을 추가한다면, 역시 test 추가도 고려해라.; 이런 방법은 앞으로의 GDB hacker들이 여러분이 추가한 기능을 찾고 변경사항을 고치도록 해준다. 비슷하게, 만일 여러분이 test failure로 보고되지 않은 버그를 고쳤다면, 그 경우를 위한 test case도 추가해라. 호스트 OS failure나 특정 버전의 컴파일러 버그를 처리하는 코드 같이 몇몇 경우는 테스트하기 무척 어렵다. 그리고 이것들 모두를 위한 test를 쓸려고 하지 마라.
The testsuite is entirely contained in `gdb/testsuite'. While the
testsuite includes some makefiles and configury, these are very minimal,
and used for little besides cleaning up, since the tests themselves
handle the compilation of the programs that GDB will run. The file
`testsuite/lib/gdb.exp' contains common utility procs useful for
all GDB tests, while the directory `testsuite/config' contains
configuration-specific files, typically used for special-purpose
definitions of procs like gdb_load and gdb_start.
testsuite는 전체적으로 `gdb/testsuite'에 포함된다.
testsuite가 몇몇 makefile과 configury를 포함하지만, 이것들은 매우 작으며
지울때 외에는 거의 사용되지 않는다. 왜냐하면 test들 자체는 GDB를 돌릴 프로그램의
편집물을 처리하기 때문이다. 파일 `testsuite/lib/gdb.exp'는 모든 GDB
test에 유용한 procs 유틸리티를 포함하며, 디렉토리 `testsuite/config'는
gdb_load와 gdb_start처럼 특별한 목적의 procs에
사용되는 설정사항-의존적인 파일을 포함한다.
The tests themselves are to be found in `testsuite/gdb.*' and subdirectories of those. The names of the test files must always end with `.exp'. DejaGNU collects the test files by wildcarding in the test directories, so both subdirectories and individual files get chosen and run in alphabetical order.
test들 자체는 `testsuite/gdb.*'와 이것들의 하위 디렉토리에서 발견된다. test file의 이름은 항상 `.exp'로 끝나야 한다. DejaGNU는 test 디렉토리에서 wildcard로 test 파일들을 모으고, 하위 디렉토리와 각 파일들을 선택하고 알파벳 순서로 돌린다.
The following table lists the main types of subdirectories and what they are for. Since DejaGNU finds test files no matter where they are located, and since each test file sets up its own compilation and execution environment, this organization is simply for convenience and intelligibility.
다음 테이블은 하위 디렉토리의 주 타입과 무엇인지를 나열한 것이다. DejaGNU는 위치해 있는곳에 관계없이 test 파일들을 찾기 때문에, 그리고 각 테스트 파일은 자신의 편집물과 실행환경을 설정하기 때문에, 이 구성은 편리성과 명확성을 위한 것이다.
#ifdefs are allowed if necessary, for instance
for prototypes).
기본 testsuite. 이것내 test는 GDB 모든 설정 사항에 적용되어야 한다.
(그러나 일반적인 native-only test는 여기에 있다.)
test 프로그램은 K&R, ANSI/ISO, and C++ 같이 C의 부분집합이어야 한다.
(원형을 위해, 필요하다면 #ifdef는 허용된다.)
C이외의 어떤 언어 lang를 위한 언어-의존적인 test. 예를 들어 `gdb.c++'과 `gdb.java'.
비-호환 test. 이 test는 HP-UX나 eCos 같이 특별한 설정 사항(호스트나 타겟)을 위한 것이다. 예를 들어, HP-UX를 위해 `gdb.hp'.
특정 컴파일러에 의존적인 test. 이것을 쓸때(1999, 6월), 거기에는 플랫폼-의존적으로 만들수 없어서 이 카테고리내 어떠한 그룹의 test도 없었다. 그러나 GCC 확장을 위한 GDB 핸들링 테스트를 위해 `gdb.gcc'이 가능하다.
더 깊이 특정 GDB 하위 시스템을 위한 test. 예를 들어, `gdb.disasm'는 다양한 disassember를 다루며, 반면에 `gdb.stabs'는 stab 심볼 리터를 통해 테스트한다.
In many areas, the GDB tests are already quite comprehensive; you should be able to copy existing tests to handle new cases.
많은 영역에서, GDB test는 이미 꽤 포괄적이다.;여러부은 새로운 case를 처리하기 위해 현재 존재하는 test를 복사해야 한다.
You should try to use gdb_test whenever possible, since it
includes cases to handle all the unexpected errors that might happen.
However, it doesn't cost anything to add new test procedures; for
instance, `gdb.base/exprs.exp' defines a test_expr that
calls gdb_test multiple times.
여러분은 가능할때 gdb_test를 사용해야 한다.
왜냐하면 이것은 일어날수 있는 예상치 못한 모든 에러를 처리하는 경우를 포하하기
때문이다. 그러나 이것은 새로운 test 절차를 추가하는데 비용이 들지 않는다.;
예를 들어, `gdb.base/exprs.exp'는 gdb_test를 여러번 호출하는 test_expr를 정의한다.
Only use send_gdb and gdb_expect when absolutely
necessary, such as when GDB has several valid responses to a command.
GDB가 명령어에 대한 유효한 응답을 가질때 처럼, 필요할때만 send_gdb와 gdb_expect를 사용해라.
The source language programs do not need to be in a consistent style. Since GDB is used to debug programs written in many different styles, it's worth having a mix of styles in the testsuite; for instance, some GDB bugs involving the display of source lines would never manifest themselves if the programs used GNU coding style uniformly.
소스 언어 프로그램은 일관성 있는 스타일일 필요는 없다. GDB가 많은 다른 스타일로 쓰여진 프로그램을 디버깅하는데 사용되기 때문에, 그것은 testsuite에 스타일을 섞을 가치가 있다.; 예를 들어, 소스 라인 출력과 관련이 있는 몇몇 GDB 버그는 만일 프로그램이 GNU 코딩 스타일을 사용한다면 그것들을 결코 나타내지 않기 때문이다.
Go to the first, previous, next, last section, table of contents.