[RFC 3/3] Test on solib load and unload

[Doug Evans]

On Sat, Sep 21, 2013 at 11:24 PM, Yao Qi <yao@codesourcery.com> wrote:
> 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.

Ah.
SOLIB_NUMBER still reads bad enough to me that I'm hoping we can agree
on a different name.
SOLIB_COUNT?

>>   > +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.

I think it is the test framework's responsibility to provide the utilities to.
Large tests (of the size we need to collect data for) are best not
written by hand, and if we're going to machine generate source, I
would rather such generators come from the framework than always be
hardcoded into every such test.  [Obviously some tests may have unique
needs though.]

> 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.

Here's an incomplete list of some of the axes we need to test (in random order):
- # threads
- # shared libs
- # ELF symbols
- # object files
- # types (e.g., # DWARF type units)
- stack depth
- # pretty-printers?

We need more than just gdb_produce_source.