This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Need suggestions on how to test observer.c
- From: David Carlton <carlton at math dot stanford dot edu>
- To: Joel Brobecker <brobecker at gnat dot com>
- Cc: gdb at sources dot redhat dot com
- Date: 11 Mar 2003 12:31:04 -0800
- Subject: Re: Need suggestions on how to test observer.c
- References: <20030310224356.GG972@gnat.com>
On Mon, 10 Mar 2003 14:43:56 -0800, Joel Brobecker <brobecker at gnat dot com> said:
> The ideal solution would be to use this little program as the unit-test
> driver, and have a dejagnu testcase check its output. Unfortunately,
> this program would of course depend on observer.o, which depends on
> utils.o which depends on [... etc]. Not easy to put in place. One
> possible approach would be to link the test program against libgdb.a
> and dependents. In fine, we would more or less link the test program
> with the same command as for gdb itself. This is a rather brutal approach,
> but this should be easy to use to generate other unit-test drivers.
> This would require a large change in the testsuite Makefiles, and
> I haven't looked at how this could be done.
I agree that GDB should have more unit tests, and the idea of linking
libgdb.a was the best idea I could come up with. Some difficulties
that might arise:
* Getting the Makefiles to work. Probably not too hard, but who
knows.
* Making sure that we can generate output that dejagnu likes. dejagnu
actually comes with a header file dejagnu.h that could be helpful
here (though that might be a C++-only thing; I'm not sure).
* Would linking against libgdb.a take a long time? If so, that would
pose problems. On the other hand, if the alternative is to run GDB
on itself, then that's not the speediest thing to do either.
* And, of course, GDB isn't always modular enough to make writing unit
tests easy, but there's not much we can do about that.
David Carlton
carlton at math dot stanford dot edu