From: Joel Brobecker <brobecker@adacore.com>
To: Pierre Muller <pierre.muller@ics-cnrs.unistra.fr>
Cc: gdb-patches@sourceware.org
Subject: Re: [RFA] Testcase for bug report 11531
Date: Fri, 23 Apr 2010 17:29:00 -0000 [thread overview]
Message-ID: <20100423172933.GO19194@adacore.com> (raw)
In-Reply-To: <000301cae303$d6d068b0$84713a10$@muller@ics-cnrs.unistra.fr>
> +# Do not use run_to main
> +# as this sets a breakpoint at main.
> +# If the breakpoint is at the same instruction as the
> +# watchpoint value assignment
> +# you can fall into the problem of the stepping over the breakpoint
> +# location that can also trigger a watchpoint miss
> +# This is not the problem reported here.
> +
> +gdb_test "start" ".*Temporary breakpoint.*"
Unfortunately, this does not work when testing with the remote protocol.
Do use "runto", but use "*main" instead of "main", or something like
that. That way, you should always stop before the instruction that
causes the watchpoint to trigger.
> +gdb_test "next" \
> + "Old value = 0.*New value = 5.*" \
> + "watchpoint variable triggers at next"
> +
> +gdb_test "continue" \
> + "Old value = .*New value = 78.*" \
> + "watchpoint variable triggers at continue"
This is a bit on the paranoid side, but can we use end-of-line
expressions rather than ".*" to match the line break? For instance,
I often use:
set eol "\[\r\n\]+"
gdb_test "next" \
"Old value = 0${eol}New value = 5${eol}" \
"watchpoint variable triggers at next"
It's unlikely that you'll have any other number than zero if the
leading digit is zero - but conceivably, we could print the new
value as 55 and still pass the test...
I did suggest at one time to provide a routine that takes a list of
regexp strings, and builds a regexp string joined with the typical
new-line regexp. That way, I could write the test as follow:
test_gdb_complete "pck" \
[multi_line "(p pck\\.ad\[sb\])?" \
"(p pck\\.ad\[sb\])?" \
"p pck.external_identical_one" \
"p pck.inner.inside_variable" \
"p pck.local_identical_one" \
"p pck.local_identical_two" \
"p pck.my_global_variable" \
"p pck.proc" ]
Daniel made another suggestion, which I needed time to investigate
and yet never did :-(.
--
Joel
next prev parent reply other threads:[~2010-04-23 17:29 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-23 16:41 Pierre Muller
2010-04-23 17:29 ` Joel Brobecker [this message]
2010-04-23 18:16 ` Pedro Alves
2010-04-23 18:25 ` Joel Brobecker
2010-04-24 15:13 ` [RFA- v2] Testcase for bug report 11531 and fix for Solaris Pierre Muller
2010-04-25 13:20 ` Joel Brobecker
2010-04-26 11:24 ` [RFA- v3] " Pierre Muller
2010-04-26 16:49 ` Joel Brobecker
2010-04-26 20:50 ` Pierre Muller
2010-04-25 20:10 ` [RFA- v2] " Pedro Alves
2010-04-26 10:55 ` [RFA- v2] Remove CANNOT_STEP_HW_WATCHPOINTS related code (was fix for bug 11531) Pierre Muller
2010-04-26 11:26 ` Pedro Alves
2010-04-26 11:50 ` Pierre Muller
2010-04-26 11:56 ` Pedro Alves
2010-04-26 12:03 ` Pierre Muller
2010-04-26 11:29 ` Mark Kettenis
2010-04-26 11:52 ` Pierre Muller
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=20100423172933.GO19194@adacore.com \
--to=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
--cc=pierre.muller@ics-cnrs.unistra.fr \
/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