From: Pedro Alves <pedro@palves.net>
To: Jan Vrany <jan.vrany@labware.com>, gdb-patches@sourceware.org
Cc: lsix@lancelotsix.com
Subject: Re: [PATCH v2 2/2] ppc: recognize all program traps
Date: Tue, 30 Nov 2021 12:17:35 +0000 [thread overview]
Message-ID: <d03bd578-798a-ff4b-f8f9-9034a11a5738@palves.net> (raw)
In-Reply-To: <20211124130926.2412617-3-jan.vrany@labware.com>
On 2021-11-24 13:09, Jan Vrany via Gdb-patches wrote:
> +# Number of expected SIGTRAP's to get. This needs to be kept in sync
> +# with the source file.
> +set expected_traps 3
> +set keep_going 1
> +set count 0
> +
> +# Make sure we have a lower timeout in case GDB doesn't support a particular
> +# instruction. Such instruction will cause GDB to loop infinitely.
> +while {$keep_going} {
> + # Continue to next program breakpoint instruction.
> + gdb_test_multiple "continue" "trap instruction $count causes SIGTRAP" {
> + -re "Program received signal SIGTRAP, Trace/breakpoint trap.*$gdb_prompt $" {
> + pass $gdb_test_name
> +
> + # Advance PC to next instruction
> + gdb_test "set \$pc = \$pc + 4" "" "advance past trap instruction $count"
> +
> + incr count
> + }
> + # We've reached the end of the test.
> + -re "exited with code 01.*$gdb_prompt $" {
> + set keep_going 0
> + }
> + timeout {
> + fail $gdb_test_name
> + set keep_going 0
> + }
> + }
> +}
> +
This while loop will iterate forever if gdb_test_multiple trips on some internal match, like
some unexpected text out of gdb that ends with a prompt, or an internal error. The logic of
"keep_going" should be reversed so that the loop breaks if anything goes wrong. Also, the
last continue to "exited with code 01" doesn't itself issue a pass unlike the other continues,
which seems inconsistent. BTW, if we flip the logic, we no longer need the timeout check.
Something like this (completely untested):
~~~~~~~~~~~~
# Number of expected SIGTRAP's to get. This needs to be kept in sync
# with the source file.
set expected_traps 3
set count 0
set keep_going 1
# Make sure we have a lower timeout in case GDB doesn't support a particular
# instruction. Such instruction will cause GDB to loop infinitely.
while {$keep_going} {
set keep_going 0
# Continue to next program breakpoint instruction.
gdb_test_multiple "continue" "trap instruction $count causes SIGTRAP" {
-re "Program received signal SIGTRAP, Trace/breakpoint trap.*$gdb_prompt $" {
pass $gdb_test_name
# Advance PC to next instruction
gdb_test "set \$pc = \$pc + 4" "" "advance past trap instruction $count"
incr count
if {$count < $expected_traps} {
set keep_going 1
}
}
}
# Verify we stopped at the expected number of SIGTRAP's.
gdb_assert {$count == $expected_traps} "all trap instructions triggered"
# One last continue to reach the end of the test, to make sure we don't get
# another SIGTRAP.
gdb_test "continue" "exited with code 01.*" "continue to end"
~~~~~~~~~~~~
Some thing in the other file. Or you could merge the files, and make the exp file
set a different .S filename and different "expected_traps" depending on arch, to
avoid duplication.
BTW, I don't understand what the "Make sure we have a lower timeout" comment is referring
to -- I don't see anything changing the timeout.
BTW², seems strange to expect that the program exits with exit code 1 instead of 0 on a success run.
I can't write PPC assembly to save my life, but I don't see any "1", or writing to r3 in in
the assembly, so I guess that is assuming the value is already 1 on entry. I wonder whether that's a
good assumption in all environments.
next prev parent reply other threads:[~2021-11-30 12:17 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-23 15:42 [PATCH 1/2] ppc: use 'trap' ('tw, 31, 0, 0', 0x7fe00008) as breakpoint instruction Jan Vrany
2021-11-23 15:42 ` [PATCH 2/2] ppc: recognize all program traps Jan Vrany
2021-11-24 10:43 ` Lancelot SIX
2021-11-24 10:57 ` Lancelot SIX
2021-11-24 13:09 ` [PATCH v2 0/2] " Jan Vrany
2021-11-24 13:09 ` [PATCH v2 1/2] ppc: use 'trap' ('tw, 31, 0, 0', 0x7fe00008) as breakpoint instruction Jan Vrany
2021-11-27 6:45 ` Joel Brobecker
2021-11-29 11:50 ` Jan Vrany
2021-12-01 9:23 ` Joel Brobecker
2021-11-24 13:09 ` [PATCH v2 2/2] ppc: recognize all program traps Jan Vrany
2021-11-27 6:58 ` Joel Brobecker
2021-11-30 12:17 ` Pedro Alves [this message]
2021-12-01 13:52 ` Jan Vrany
2021-12-01 14:30 ` [PATCH v3 0/2] " Jan Vrany
2021-12-01 14:30 ` [PATCH v3 1/2] ppc: use "trap" ("tw, 31, 0, 0") as breakpoint instruction Jan Vrany
2021-12-04 10:16 ` Joel Brobecker
2021-12-01 14:30 ` [PATCH v3 2/2] ppc: recognize all program traps Jan Vrany
2021-12-04 10:18 ` Joel Brobecker
2021-12-07 23:30 ` Pedro Alves
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=d03bd578-798a-ff4b-f8f9-9034a11a5738@palves.net \
--to=pedro@palves.net \
--cc=gdb-patches@sourceware.org \
--cc=jan.vrany@labware.com \
--cc=lsix@lancelotsix.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).