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: Doug Evans <dje at google dot com>
- To: Yao Qi <yao at codesourcery dot com>
- Cc: gdb-patches <gdb-patches at sourceware dot org>
- Date: Sun, 22 Sep 2013 17:14:16 -0700
- 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> <523E8D0A dot 2050205 at codesourcery dot com>
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.