This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Need suggestions on how to test observer.c


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]