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: Yao Qi <yao at codesourcery dot com>
- To: Doug Evans <dje at google dot com>
- Cc: gdb-patches <gdb-patches at sourceware dot org>
- Date: Tue, 24 Sep 2013 10:30:57 +0800
- 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> <CADPb22Q-M4KtYi8xfJukf2SUN4Xxq+eACHaEvT2wK-+u2Zw3pw at mail dot gmail dot com>
On 09/23/2013 08:14 AM, Doug Evans wrote:
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.]
Doug,
Generating source is easy in this test case. However, I am not sure it
is easy to generate source for other perf test cases, like symbols and
types. Supposing we want to generate source files have 1 million
classes, with some hierarchies, the generation script can't be simple,
IMO. On the other hand, I don't know how representative the generated
program is, compared with the real large applications, such as
openoffice, clang, etc.
>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
They are not hard to generate.
- # ELF symbols
- # object files
- # types (e.g., # DWARF type units)
I am not familiar with type and symbols, but I assume we need some
scripts to generate source files having a large number of different
symbols and types, which looks hard.
- stack depth
It is not hard to generate either.
- # pretty-printers?
I am OK to add utilities to generate sources for shared libs and stack
depth, but I am still unable to find an approach to generate source
files for perf tests on symbols and types.
--
Yao (éå)