Re: [PATCH 0/3 V2] GDB Performance testing

[Yao Qi <yao@codesourcery.com>]

On 09/25/2013 10:26 PM, Yao Qi wrote:
> Here are some points V2 doesn't address, and I'd like revisit them
> and consider them in the next iteration.
>
>   - Utilities to generate source files.  We need them to generate source
>     files to compose a reasonably sized program for perf testing.  However,
>     current test case doesn't require these utilities.
>   - Generated files, including source files, object files and executables
>     are not removed when the test is done, because the next run may skip
>     compilation step.
>
> The basic usages of performance testing are unchanged, like
>
> $ make check-perf
> $ make check-perf RUNTESTFLAGS="--target_board=native-gdbserver solib.exp"
> $ make check-perf RUNTESTFLAGS="solib.exp SOLIB_COUNT=1024"
>
> We can skip compilation step like this,
>
> $ make check-perf RUNTESTFLAGS='solib.exp GDB_PERFORMANCE_SKIP_COMPILE=yes'
>
> in default, compilation is not skipped.
>
> The skeleton of .exp is like this:
>
> load_lib perftest.exp
>
> if [skip_perf_tests] {
>      return 0
> }
>
> PerfTest::assemble {
>      compile {
>
>        PerfTest::compiled
>      }
>      setup_gdb {
>      }
> } {
>      run {
>      }
> }
>
> PerfTest::assemble is inspired by Dwarf::assemble.  It has three
> procedures, compile, setup_gdb and run.  Each test should fill in
> the body of these three procedures for its purpose.  If variable
> GDB_PERFORMANCE_SKIP_COMPILE exists, the procedure compile is not
> invoked.  If the test case uses pre-compiled program, it can be
> written like this:
>
> PerfTest::assemble {
>      setup_gdb {
>      }
> } {
>      run {
>      }
> }

Ping.  https://sourceware.org/ml/gdb-patches/2013-09/msg00894.html

-- 
Yao (齐尧)