[RFC 3/3] Test on solib load and unload
Yao Qi
yao@codesourcery.com
Sun Sep 22 06:25:00 GMT 2013
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 (é½å°§)
More information about the Gdb-patches
mailing list