Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Tom Tromey <tromey@redhat.com>
To: Yao Qi <yao@codesourcery.com>
Cc: <gdb-patches@sourceware.org>
Subject: Re: [PATCH 4/4] Test on solib load and unload
Date: Fri, 01 Nov 2013 20:35:00 -0000	[thread overview]
Message-ID: <87eh6zyi6j.fsf@fleche.redhat.com> (raw)
In-Reply-To: <1383291300-13917-5-git-send-email-yao@codesourcery.com> (Yao	Qi's message of "Fri, 1 Nov 2013 15:35:00 +0800")

>>>>> "Yao" == Yao Qi <yao@codesourcery.com> writes:

Yao> This patch is to add a test case to on the performance of GDB handling
Yao> load and unload of shared library.

A few Tcl nits on this patch...

Yao> +	    gdb_produce_source $src { "int shr$i (void) {return 0;}" }

This bit is weird.  Combined with the definition of gdb_produce_source:

Yao> +proc gdb_produce_source { name sources } {
Yao> +    set index 0
Yao> +    set f [open $name "w"]
Yao> +
Yao> +    while { ${index} < [llength ${sources}] } {
Yao> +	set line [lindex ${sources} ${index}]
Yao> +	set index [expr ${index} + 1]
Yao> +
Yao> +	set line [uplevel list $line]
Yao> +	puts $f $line
Yao> +    }
Yao> +    close $f
Yao> +}

I don't see why this "uplevel list" stuff is needed.
Just have the caller pass in the text to write to the file.
The substitutions can be done there.

There also doesn't seem to be a need for "sources" to be a list.
Just make it one big string and let the caller work it out.


Yao> +	    # Compile.
Yao> +	    if { [gdb_compile_shlib $src $exe {debug}] != "" } {
Yao> +		untested "Couldn't compile $src."
Yao> +		return -1

This returns a value but I think the caller doesn't use it.
This isn't a bug, but it does mean some head-scratching later on, and of
course this will inevitably be copied into all the other perf tests...

That said I think this probably *should* return a value and I'll comment
on the other patch.

Tom


  reply	other threads:[~2013-11-01 20:35 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-01  7:36 [PATCH 0/4 V4] GDB Performance testing Yao Qi
2013-11-01  7:36 ` [PATCH 1/4] New make target 'check-perf' and new dir gdb.perf Yao Qi
2013-11-01  7:36 ` [PATCH 3/4] Mention perf test in testsuite/README Yao Qi
2013-11-01  7:36 ` [PATCH 2/4] Perf test framework Yao Qi
2013-11-01 19:43   ` Doug Evans
2013-11-01 20:46   ` Tom Tromey
2013-11-02  2:42     ` Yao Qi
2013-11-04 16:27       ` Tom Tromey
2013-11-06  5:30         ` Yao Qi
2013-11-01  7:36 ` [PATCH 4/4] Test on solib load and unload Yao Qi
2013-11-01 20:35   ` Tom Tromey [this message]
2013-11-02  2:50     ` Yao Qi
2013-11-04 17:37       ` Tom Tromey
2013-11-06  6:42 ` [PATCH 0/4 V4] GDB Performance testing Yao Qi
  -- strict thread matches above, loose matches on Subject: below --
2013-10-16  7:10 [PATCH 0/4 V3] " Yao Qi
2013-10-16  7:10 ` [PATCH 4/4] Test on solib load and unload Yao Qi
2013-10-25  7:17   ` Doug Evans

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87eh6zyi6j.fsf@fleche.redhat.com \
    --to=tromey@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=yao@codesourcery.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox