From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22565 invoked by alias); 16 Sep 2002 19:25:48 -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 22557 invoked from network); 16 Sep 2002 19:25:48 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 16 Sep 2002 19:25:48 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17r2RJ-0002UG-00 for ; Mon, 16 Sep 2002 15:25:49 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17r1VC-000472-00 for ; Mon, 16 Sep 2002 15:25:46 -0400 Date: Mon, 16 Sep 2002 12:25:00 -0000 From: Daniel Jacobowitz To: gdb@sources.redhat.com Subject: RFC: Additional testsuite alternative Message-ID: <20020916192546.GA6174@nevyn.them.org> Mail-Followup-To: gdb@sources.redhat.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.1i X-SW-Source: 2002-09/txt/msg00210.txt.bz2 OK, the files were on a different machine, so this wasn't a couple minutes after I promised it this morning. Can't win 'em all. I very much admire the way GCC's testsuite works. You don't have to write code for new tests; you can just drop them in. Binutils has a two-file version (GCC's is all one-file, using the DejaGNU "dg" harness) that's comparable. GDB testing is more complicated, but I think that for a significant number of tests we can get the same result. Some more complex tests will still want to be their own .exp files, of course. Here's how what I've implemented so far looks. Source file two.cc: === struct OneStruct { int simple; }; struct OneStruct StrOne; const struct OneStruct *ConstStrOnePtr; int FunctionWithPtrs (const struct OneStruct *one, const int *two) { return 0; } int main () { return 0; } === Source file two.x: === #compile two.cc two.exe executable debug #runto main #test "ptype StrOne" type = class OneStruct { public: int simple; [synthetic OneStruct]} #test "ptype ConstStrOnePtr" type = const class OneStruct { public: int simple; [synthetic OneStruct]} \* === Lines starting with "#[a-z]" are commands. The ones we have so far (since they were all I needed for the test I was writing at the time :) are: #compile Works just like a call to gdb_compile, but the source is relative to the location of the .x file. #runto Calls either runto or runto_main depending on the argument. #test [-const] "command" Sends "command" to GDB and watches for the response, which is a series of lines not starting with #. If -const is specified then consts (volatiles, etc.) will be left alone; otherwise they are made optional iff the debug format is stabs. Later I'll refine it to "iff the debug format is stabs and the compiler does not produce const type qualifiers in its stabs". The string [synthetic ClassName] is special and expands to a regex (iff stabs) that matches the synthesized constructors and assignment operator that GCC emits when using stabs (simplisticly; it's not meant to be perfect, just to reduce clutter in testing simple structures, and I haven't thought of a way to properly prevent the synthesized methods from showing up. I think I just did, though, and if it works this construct will die.) Obviously the syntax isn't complete. It doesn't support comments yet but that's easy. It's not set in stone; I'd kind of like to use something other than '#' so that I can use '#' for comments. Maybe '%'? The general intention is that this makes it easier to write tests, and drastically easier to read them and figure out what the expected output is. Thoughts? Is this interesting to anyone else? -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer