This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC 3/3] Test on solib load and unload
- From: Yao Qi <yao at codesourcery dot com>
- To: Doug Evans <dje at google dot com>
- Cc: <gdb-patches at sourceware dot org>
- Date: Sun, 22 Sep 2013 14:24:10 +0800
- Subject: Re: [RFC 3/3] Test on solib load and unload
- Authentication-results: sourceware.org; auth=none
- References: <520B7F70 dot 6070207 at codesourcery dot com> <1377663394-4975-1-git-send-email-yao at codesourcery dot com> <1377663394-4975-4-git-send-email-yao at codesourcery dot com> <521D7BCA dot 10806 at codesourcery dot com> <21051 dot 32359 dot 845429 dot 92304 at ruffy dot mtv dot corp dot google dot com>
On 09/20/2013 06:44 AM, Doug Evans wrote:
> +standard_testfile .c
> +set executable $testfile
> +set expfile $testfile.exp
> +
> +# make check RUNTESTFLAGS='solib.exp SOLIB_NUMBER=1024'
SOLIB_NUMBER doesn't read very well.
How about NUM_SOLIBS?
I should mention the naming convention I used here before. It is
"TEST_PARAMETER". "SOLIB" is like a name space, and all variables used
in this test should be prefixed by "SOLIB_". I tried "." to replace
"_", but "." is not allowed to use.
If we write a test case on backtrace, and we need variable to control
the depth of bt, we can name it "BACKTRACE_DEPTH".
> +if ![info exists SOLIB_NUMBER] {
> + set SOLIB_NUMBER 128
> +}
> +
> +for {set i 0} {$i < $SOLIB_NUMBER} {incr i} {
> +
> + # Produce source files.
> + set libname "solib-lib$i"
> + set src [standard_temp_file $libname.c]
> + set exe [standard_temp_file $libname]
> +
> + set code "int shr$i (void) {return $i;}"
> + set f [open $src "w"]
> + puts $f $code
> + close $f
IWBN if the test harness provided utilities for generating source
files instead of hardcoding the generating of them in the test.
Parameters to such a set of functions would include things like the name
of a high level entry point (what one might pass to dlsym), the number
of functions in the file, the number of classes, etc.
IMO, it is not the perf test framework's responsibility to generate
source files and I am not sure the utilities like these can be reused
by other tests.
We can add a new proc gdb_produce_source with two parameters, NAME and
SOURCES. NAME is the file name and SOURCES is a list of lines of source
code we want to write to file NAME. For instance,
gdb_produce_source $src { "int shr$i (void) {return 0;}" }
It can be used here and replace some code in gdb.exp.
--
Yao (éå)