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

Yao Qi
2013-10-06T01:44:09Z

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 (é½å°§)