Testsuite Organization Proposal

[Stan Shebs <shebs@cygnus.com>]

I'd like to propose a semi-formalization of the current testsuite
organization, basically just reflecting current practice, but with
enough precision to guide further additions.  The testsuite is key for
GDB developers; the breadth of functionality and platforms is now so
broad, in many cases, users won't discover regressions for months or
years after the change that caused them; while a testsuite run often
reveals mistakes right away.

First of all, testsuite organization mainly serves the purpose of
intelligibility; DejaGNU finds all the expect scripts wherever they're
placed.  But with around 6000 tests in all, it becomes important to
organize them sensibly.

gdb.base	This is the base testsuite.  The tests in it should
		apply to all configurations of GDB (but generic
		native-only tests may live here).  The test programs
		should be in a subset of C that is valid K&R, ANSI/ISO,
		and C++ (ifdefs are allowed).

gdb.<lang>	Language-specific tests for all languages besides C.

gdb.<platform>	Non-portable tests.  The tests are specific to a specific
		configuration (host or target), such as HP-UX or eCos.

gdb.<compiler>	Tests specific to a particular compiler.  There aren't
		currently any groups of tests in this category that
		couldn't just as sensibly be made platform-specific,
		but one could imagine a gdb.gcc, for tests of GDB's
		handling of GCC extensions.

gdb.<subsystem>	Tests that exercise a specific subsystem in more depth.
		For instance, gdb.disasm exercises various disassemblers,
		while gdb.stabs tests pathways through the stabs reader.

Please feel free to comment on this.  If everybody thinks this is great,
I'll add to the internals manual.

								Stan