Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@mvista.com>
To: gdb@sources.redhat.com
Cc: fnasser@redhat.com
Subject: Re: RFC: Additional testsuite alternative
Date: Thu, 26 Sep 2002 11:21:00 -0000	[thread overview]
Message-ID: <20020926182132.GA26853@nevyn.them.org> (raw)
In-Reply-To: <20020916192546.GA6174@nevyn.them.org>

Does anyone have any reaction to this?  Fernando, how would you feel
about adding the harness for this to the testsuite?

The background is that I'm probably going to change the behaviour (and
definitely going to increase the visibility) of c_print_type, so I want
to have some unit tests written for it first.

On Mon, Sep 16, 2002 at 03:25:46PM -0400, Daniel Jacobowitz wrote:
> 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 <source> <binfile> <type> <options>
> 
> Works just like a call to gdb_compile, but the source is relative to the
> location of the .x file.
> 
> #runto <function>
> 
> 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
> 

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer


  reply	other threads:[~2002-09-26 18:21 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-09-16 12:25 Daniel Jacobowitz
2002-09-26 11:21 ` Daniel Jacobowitz [this message]
2002-09-26 12:51   ` David Carlton
2002-09-26 13:22   ` Fernando Nasser
2002-09-26 13:25     ` Daniel Jacobowitz
2002-09-26 14:05   ` Jim Blandy
2002-09-26 14:09     ` Daniel Jacobowitz
2002-09-26 13:47 ` Andrew Cagney
2002-09-26 13:57   ` Daniel Jacobowitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20020926182132.GA26853@nevyn.them.org \
    --to=drow@mvista.com \
    --cc=fnasser@redhat.com \
    --cc=gdb@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox