From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <mec@shout.net>
Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm
Received: (qmail 15698 invoked from network); 9 Jan 2003 16:09:20 -0000
Received: from unknown (HELO duracef.shout.net) (204.253.184.12)
  by 209.249.29.67 with SMTP; 9 Jan 2003 16:09:20 -0000
Received: (from mec@localhost)
	by duracef.shout.net (8.11.6/8.11.6) id h09G96e01574;
	Thu, 9 Jan 2003 10:09:06 -0600
Date: Thu, 09 Jan 2003 16:09:00 -0000
From: Michael Elizabeth Chastain <mec@shout.net>
Message-Id: <200301091609.h09G96e01574@duracef.shout.net>
To: carlton@math.stanford.edu
Subject: Re: [rfc] plans for linespec.c
Cc: ezannoni@redhat.com, fnasser@redhat.com, gdb@sources.redhat.com,
   jimb@redhat.com
X-SW-Source: 2003-01/txt/msg00131.txt.bz2

David Carlton writes:
> Fair enough.  It's something I should get around to doing eventually
> for other reasons; maybe your nudging will move it up some.

Right.  I have to allocate my time between 'do stuff with tangible
gdb benefits' and 'do stuff that improves my own infrastructure'.
Sometimes I feel like I'm just infrastructuring my test bed too much.

> Speaking of which, I had the thought that maybe we could do unit tests
> of some of the innards of GDB by writing separate test programs that
> we link with -lgdb.  Something to think about.

That is a provocative idea.  I know Jim B wrote one symbol table test
that jumped through a bunch of hoops with the C source code in order
to populate the symbol table in a way that tickled a lookup bug.

On the gloomy side, the test suite can already spot problems faster than
I can file bug reports, and the bug reports are piling up faster than
people can fix them.

Michael C