From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16337 invoked by alias); 11 Mar 2003 20:31:16 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 16330 invoked from network); 11 Mar 2003 20:31:15 -0000 Received: from unknown (HELO jackfruit.Stanford.EDU) (171.64.38.136) by 172.16.49.205 with SMTP; 11 Mar 2003 20:31:15 -0000 Received: (from carlton@localhost) by jackfruit.Stanford.EDU (8.11.6/8.11.6) id h2BKV4j18076; Tue, 11 Mar 2003 12:31:04 -0800 X-Authentication-Warning: jackfruit.Stanford.EDU: carlton set sender to carlton@math.stanford.edu using -f To: Joel Brobecker Cc: gdb@sources.redhat.com Subject: Re: Need suggestions on how to test observer.c References: <20030310224356.GG972@gnat.com> From: David Carlton Date: Tue, 11 Mar 2003 20:31:00 -0000 In-Reply-To: <20030310224356.GG972@gnat.com> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-03/txt/msg00165.txt.bz2 On Mon, 10 Mar 2003 14:43:56 -0800, Joel Brobecker 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@math.stanford.edu