This is the mail archive of the
mailing list for the GDB project.
Re: [RFA] Testsuite: Change match_max for current also
- From: Joel Brobecker <brobecker at adacore dot com>
- To: Pierre Muller <muller at ics dot u-strasbg dot fr>
- Cc: gdb-patches at sourceware dot org
- Date: Fri, 2 Oct 2009 16:20:11 -0700
- Subject: Re: [RFA] Testsuite: Change match_max for current also
- References: <firstname.lastname@example.org>
> In annota1.exp, I found that:
> verbose "match_max local is: [match_max]"
> verbose "match_max default is: [match_max -d]"
> # This is necessary because a 2000 buffer is not enought to get
> # up to the prompt ad the test gets a timeout.
> match_max 3000
> verbose "match_max now is: [match_max]"
Yeah - wild guess is that this was done before the match_max value
got unilaterally increased by default_gdb_init.
> PS1: If this is approved, we should also
> consider what to do about the three tests
> that set another value of match_max
> (lower than the 30000).
We should simply remove them, since this is now handled automatically.
> PS2: calling 'match_max -d 30000' several times is a waste of time, as
> long as nothing changes that default value in any of the tests, should
> it rather be extracted out of default_gdb_init, so that it get
> executed only once?
I'd say: Only if the optimization provides noticeable performance
benefits. Another wild guess is that it is not noticeable, but if
you can measure it, and it doesn't increase code complexity too much,
sure. Of, if it does not increase code complexity at all, then by
I was actually wondering if we needed to change the default value
at all. Just keep resetting the match_max value to the current
default, or even to 30000, if we eliminate setting the default
> 2009-10-02 Pierre Muller <email@example.com>
> * lib/gdb.exp (default_gdb_init): Set current value of match_max
> to default.
In the meantime, this looks fine to me.