Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Joel Brobecker <brobecker@adacore.com>
To: Nick Roberts <nickrob@snap.net.nz>
Cc: Eli Zaretskii <eliz@gnu.org>, gdb-patches@sources.redhat.com
Subject: Re: [PATCH] New annotation for threads
Date: Tue, 20 May 2008 15:27:00 -0000	[thread overview]
Message-ID: <20080520035226.GA4669@adacore.com> (raw)
In-Reply-To: <18479.62120.536436.427524@kahikatea.snap.net.nz>

> 2008-05-18  Nick Roberts  <nickrob@snap.net.nz>
> 
> 	* annotate.c (annotate_new_thread): New function for new-thread
> 	annotation.
> 
> 	* annotate.h: (annotate_new_thread): New extern.
> 
> 	* thread.c (add_thread_with_info): Use it.
> 
> 	* Makefile.in (thread.o): Add dependency on annotate.h.

(note sure if the empty lines between each entry was intended - just
make sure to remove them when entering this in the ChangeLog).

I'm not terribly happy about this, but that's nonetheless a reasonable
compromise. So this part is OK.

> 2008-05-18  Nick Roberts  <nickrob@snap.net.nz>
> 
> 	* gdb.base/annota1.exp: Test for new annotation.

I have a few questions regarding this part:

> +set testfile "watch_thread_num"
> +set srcfile ${testfile}.c
> +set binfile ${objdir}/${subdir}/${testfile}
> +set gdb_prompt $old_gdb_prompt
> +
> +if { ![get_compiler_info ${binfile}] && [gdb_compile_pthreads "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable {debug nowarnings}] == "" } {
> +
> +    gdb_exit
> +    gdb_start
> +    gdb_reinitialize_dir $srcdir/$subdir
> +    gdb_load ${binfile}
> +    if { ![runto main] } then {
> +	fail "run to main"
> +	return

I think this will cause the test to exit before you had a chance
to restore the gdb_prompt.  I suggest you put the entire block
of code inside a function, and then call that function at the end
of the script.  That way, you can write the body of the function
as if it was its own script (the practice is to "if gdb_compile != ""
then return..." so that you don't need increasing levels of nesting.
but that's very minor, I don't mind the way you wrote it)

Another alternative would be to have a new specific script. It wouldn't
be any more work at all, and might be cleaner (although, you still do
have to be careful about the gdb_prompt).

> +    send_gdb "set annotate 2\n"
> +    gdb_expect {
> +	-re "set annotate 2\r\n$gdb_prompt$" {}
> +    }
> +
> +    send_gdb "next 2\n"
> +    gdb_expect {
> +	-re ".*\032\032new-thread" {
> +	    pass "new thread"
> +	}
> +	timeout { fail "new thread (timeout)" }
> +    }

I think you should be able to use gdb_test in this case, no?
I realize that you are only repeating the practice that is currently
used throughout the file, but we're trying to avoid the send_gdb/
gdb_expect sequence whenever we can, and use either gdb_test or
gdb_test_multiple.  For one thing, both already handle the various
error conditions, including the timeout.

-- 
Joel


  parent reply	other threads:[~2008-05-20  3:53 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-18 16:06 Nick Roberts
2008-04-29  4:47 ` Joel Brobecker
2008-04-29 14:19   ` Nick Roberts
2008-05-01 18:18     ` Joel Brobecker
2008-05-01 18:44       ` Daniel Jacobowitz
2008-05-01 23:31       ` Nick Roberts
2008-05-01 23:37         ` Joel Brobecker
2008-05-02  0:07           ` Nick Roberts
2008-05-02  5:50             ` Joel Brobecker
2008-05-02 10:41             ` Eli Zaretskii
2008-05-17 15:51               ` Nick Roberts
2008-05-17 19:15                 ` Stan Shebs
2008-05-17 21:18                 ` Eli Zaretskii
2008-05-18  3:20                   ` Bob Rossi
2008-05-18  9:11                     ` Bob Rossi
2008-05-18 17:44                     ` Eli Zaretskii
2008-05-19  8:48                       ` Joel Brobecker
2008-05-19  9:09                   ` Nick Roberts
2008-05-19  9:44                     ` Eli Zaretskii
2008-05-19 12:39                 ` Nick Roberts
2008-05-19 13:23                   ` Eli Zaretskii
2008-05-20 15:27                   ` Joel Brobecker [this message]
2008-05-20 16:10                     ` Nick Roberts
2008-05-20 16:43                       ` Nick Roberts
2008-05-20 18:09                         ` Joel Brobecker
2008-05-21  3:55                           ` Nick Roberts
2008-05-21  7:22                             ` Joel Brobecker
2008-05-20 22:21                     ` Eli Zaretskii
2008-05-20 22:54                       ` Joel Brobecker
2008-05-21  3:26                         ` Eli Zaretskii
2008-05-21  9:33                           ` Joel Brobecker
2008-05-21 15:11                             ` Nick Roberts
2008-05-21 15:14                               ` Joel Brobecker

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=20080520035226.GA4669@adacore.com \
    --to=brobecker@adacore.com \
    --cc=eliz@gnu.org \
    --cc=gdb-patches@sources.redhat.com \
    --cc=nickrob@snap.net.nz \
    /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