From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5888 invoked by alias); 23 Sep 2013 00:14:19 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 5878 invoked by uid 89); 23 Sep 2013 00:14:19 -0000 Received: from mail-ie0-f181.google.com (HELO mail-ie0-f181.google.com) (209.85.223.181) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Mon, 23 Sep 2013 00:14:19 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.3.2 X-HELO: mail-ie0-f181.google.com Received: by mail-ie0-f181.google.com with SMTP id tp5so4958128ieb.26 for ; Sun, 22 Sep 2013 17:14:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=3rvMvOKmgAyZ0LKt19SEu1cLk/E5Ym2dMqoVsY4v/vs=; b=P7ZqQz4FOXlCBKvFIX8bXYbtgGII+YAPG5gjd8B2PDsvGMLQpQUO884/8BnYahRIqV Eere90LZJnmJUlIDE2BU9LahH+YxdeU153Oy2/2wV5zOjRr3mUwT5nTJe6OOD3OPmdS2 Bn1s48+lhKzK6ZwXUynnqVoK6YHyfqYl8sBX8OnO1iexJvTMTzwiRe8y/dA5QhXJj+/W EaxU0a2xEkPwRAePG0Pg2H83mUuUUQlW6tcfWfB5ao+U9FYJf7BCsMgm0Wj3H6fpZJuc jplAo2Qg2CPWL8bWR7uZsg6cekYAgpVv8H2wmLP/s0z8uKvQX79qdkffm2QqyuxXgfjP zaGg== X-Gm-Message-State: ALoCoQmx79p+dkCOtbJvD9/7xHYaZPc/sP3tAuH1GMULUPvDKlkrk9T/ExZcdNCHJ1LZXPSe8jmNvoq+8TZRyjrndl8XFYfzLqlyweDjKVlYLAEx3DcB7eseC/UkOrQEK/+38BXK7yqdG5jNkyceO0xug9mOWDXhMgwdxikihWQh5tAQr1mDOEHKP6Op4dYC1u+ogHSiE2KhgRuEQJlsVZXTGcPsNthtiA== MIME-Version: 1.0 X-Received: by 10.50.7.101 with SMTP id i5mr10473019iga.48.1379895256828; Sun, 22 Sep 2013 17:14:16 -0700 (PDT) Received: by 10.64.31.100 with HTTP; Sun, 22 Sep 2013 17:14:16 -0700 (PDT) In-Reply-To: <523E8D0A.2050205@codesourcery.com> References: <520B7F70.6070207@codesourcery.com> <1377663394-4975-1-git-send-email-yao@codesourcery.com> <1377663394-4975-4-git-send-email-yao@codesourcery.com> <521D7BCA.10806@codesourcery.com> <21051.32359.845429.92304@ruffy.mtv.corp.google.com> <523E8D0A.2050205@codesourcery.com> Date: Mon, 23 Sep 2013 00:14:00 -0000 Message-ID: Subject: Re: [RFC 3/3] Test on solib load and unload From: Doug Evans To: Yao Qi Cc: gdb-patches Content-Type: text/plain; charset=ISO-8859-1 X-IsSubscribed: yes X-SW-Source: 2013-09/txt/msg00805.txt.bz2 On Sat, Sep 21, 2013 at 11:24 PM, Yao Qi 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.