binutils-gdb/gdb/testsuite/TODO
Jim Kingdon d71511fbd3 * TODO: Add note about "handle all nostop".
* gdb.base/{sigall.c, sigall.exp}: New test.
	* gdb.base/Makefile.in: Add it.
1995-01-08 23:03:28 +00:00

206 lines
8.2 KiB
Plaintext
Raw Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

The highest priority item is not on this list: Fix bugs in the
existing testsuite, fix the GDB/compiler/shell/etc bugs which it
detects (particularly when they are hard to XFAIL), make it run
reliably without unexpected failures on the "standard" machines, etc.
This list exists largely as "tests we can add when we are ready to
risk destabilizing it again".
nodebug.exp--test printing variables.
Test printing of structures passed by value, for the 7th, 8th, and 9th
arguments (PR 1714). Test printing structure arguments of
2,4,6,8,12,16,and 20 bytes. Same for structure return of all those
sizes ("return", "finish", and call function).
Get crossload tests to use --enable-targets and reenable them.
corefile.exp:
1. Print variables from the core file (data and stack), and text
(from the exec file). This tests whether the corefile sections are
mapped to the right addresses.
2. Test what happens when we get a new exec file without explicitly
getting rid of the core file (we at least must avoid core dumps and such).
3. Test backtrace in corefile.exp.
4. Test ability to run program when there is a core target, then go
back to the core file when the program exits.
Test handling of floating point variables
1. float, double, or long double
2. in register or saved register or memory. Also the case where a
double is in two float registers and only one of them is saved.
3. print them or set them
4. (Alpha) integer (32 or 64 bit) in floating point register.
Print registers--"p $r5", "p sizeof ($r5)". Test that they print
appropriately (integer registers in decimal, registers which always
contain addresses (pc, probably sp and fp, maybe others) in hex,
floating point).
Test completer. There is a list of test cases in main.c in the gdb
source. Test these with TAB, M-?, and the "complete" command.
Test "info line" with all kinds of linespecs. Test that the last line
of the file works right.
weird.exp--test that unrecognized cross-reference types or
unrecognized visibility or virtual characters get skipped properly
(see stabs.texinfo).
Test C++ nested types (especially if PR 1954 is fixed; even if not
*some* things already should work even in the presence of nested
types). Test classes nested more than 9 levels deep (g++ mangles
these differently) (both a demangle test and some tests which also
test the compiler). Test calling a method of a class nested more than
9 levels (for gdb_mangle_name and demangling).
Test static member functions (C++). Test that "ptype" shows them
correctly, both before and after they have been converted from stub
methods. Test that we can call them.
Test printing complicated types, including functions, pointers to
arrays of pointers of functions, functions which return pointers to
functions, etc.
Test GDB expressions--test all operators (and overloaded operators for
C++). Test integer constants which are signed or unsigned int, long,
or long long. Test detection of overflow of an integer constant.
Here are a few integer constants to test (test they get the right
types): 5, 5LL, 5LuL, 5L6u (invalid), 5LU. Maybe things like
0x12345678, 0x87654321, etc., but their types depend on sizes of int,
long, etc.
Test that printing const-qualified versions of various types works.
In particular, on the sparc and probably other machines, "double" is
handled differently from most types because it requires more alignment
and thus goes in a different section (there is a gcc 2.4.5 bug with
"const double" on sparc).
Test that GDB's "source" command works and that things work if stdin
is redirected (to a file or a pipe). Test user defined command. Run
an inferior each of these ways (to test that inflow.c works). Test
that GDB works if the last line of stdin or a source'd file lacks a
newline.
Test that module__2do (for example) in a C program does not get
demangled.
Test that unmatched single quotes produce error messages, both in
expressions and linespecs.
Test "cd". "foo/bar/.." should get simplified to "foo". "/../.."
should not get simplified (for Mach). "/.." should not get simplified
(for other networked OSes; POSIX.1 section B.2.3.7). All these
examples should continue to work with trailing slashes.
Test scoping; here is a start
1 int i=2;
2 int j=3;
3 main()
4 {
5 int i;
6 for (i=600; i>0; i--)
7 print_line(i);
8 }
9
10 print_line(i)
11 int i;
12 {
13 h();
14 printf("%d\n",i);
15 }
16
17 h()
18 {
19 printf("In h...");
20 }
Set a breakpoint in h, and print i, print_line::i, and main::i. Set a
breakpoint in main (or don't run the program), and test that
print_line::i is an error. But if i were static, "p main::i" should
work even if the program is not being run.
Write a test for the reentracy bug with rs6000_struct_return_address
in rs6000-tdep.c.
Test "return" from dummy frames. Test "return" from non-innermost
frame. Test that "return" from a non-innermost frame restores
registers which are saved not in that frame but in a frame more inner
(I believe this currently works on few if any architectures).
FORTRAN common blocks (a.out and xcoff--weird.exp has the start of
one but it is not quite right as of 19 Nov 1993).
Test that "x" command sets $_ and $__. Test $_ in general.
Test that "p/a" works when given addresses in text, data, and bss
segments. Test that it works if program is compiled with or without
-g. Test that it works if preceding symbol is static or if it is
extern.
Given `char abc[] = "abc\0def";' test "x/s abc" followed by "x/s"
(should display "abc" followed by "def"). Test this works with no
error message even if this is the last thing in the section (tests
that val_print_string ignores an error if the error occurs after the
'\0').
Test ability to process NMAGIC a.out files.
Test shared libraries: "next" over printf, "step" into a function in
a shared library which has line number info, breakpoint in a function
in a shared library (either before or after the program is run and the
shared libraries are loaded--also maybe write a test where the PLT
will be in an unloaded state even though the shared library is loaded).
If there are two breakpoints in the same place, and exactly one of
them has its condition true, test that the correct breakpoint gets
printed.
Test "jump" including jump to a breakpoint (the latter will need an
xfail for UDI and probably VxWorks (PR 1786 for vxworks; PR 2416
contains some info for 29k).
Set a watchpoint on a local variable (to be interesting, make a few
calls, to be more interesting, make a recursive call). Test that it
gets disabled when leaving that scope.
Test calling a function, hitting a breakpoint in the called function,
calling another function, and hitting a breakpoint. Test backtrace
works in the presence of multiple dummy frames. Test that "continue"
will get you out of the inner called function, and "continue" again
will get you back to where you were when you called the first one.
Test special longjmp handling in wait_for_inferior (need to figure out
in detail what the proper behavior in each case is). Test longjmp to
a place where there is a breakpoint (such that
BPSTAT_WHAT_CLEAR_LONGJMP_RESUME_SINGLE happens). In general, test
interactions between longjmp and watchpoints, breakpoints, stepping,
call function, etc.
Test jumping right past a breakpoint (the case where wait_for_inferior
passes not_a_breakpoint to bpstat_stop_status). Might already be
tested by some of the sun3 tests. Probably want a .s test to avoid
compiler dependencies.
Test more obscure wait_for_inferior cases, expanding on the tests in
watchpoint.exp, signals.exp, etc.
Test "handle all nostop". Right now this is buggy--it (a) prints "?"
for "Unknown signal", (b) prints signal zero (bug or feature?), (c)
dumps core when it is done.
Test that the copyright year in the startup message matches the
current year (would produce a single spurious FAIL on old GDB's, but
probably still a good idea).
Test that prologue recognition, backtrace, printing locals, etc.,
still work in the presence of large frames (the point being that at
some point immediate fields in RISC instructions will overflow and
prologues will need to look different. For sparc, the immediate field
is 13 bits (signed), so I believe the threshold would be 4K bytes in a
frame).
(this is for editing this file with GNU emacs)
Local Variables:
mode: text
End: