public inbox for gdb-cvs@sourceware.org help / color / mirror / Atom feed
From: Andrew Burgess <aburgess@sourceware.org> To: gdb-cvs@sourceware.org Subject: [binutils-gdb] gdb/testsuite: change mi_gdb_start to take a list of flags Date: Tue, 3 May 2022 09:48:58 +0000 (GMT) [thread overview] Message-ID: <20220503094858.76CCC3858427@sourceware.org> (raw) https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=43cef57a742bae20477bb2fbb306ab4c4167318c commit 43cef57a742bae20477bb2fbb306ab4c4167318c Author: Andrew Burgess <aburgess@redhat.com> Date: Wed Apr 27 18:45:47 2022 +0100 gdb/testsuite: change mi_gdb_start to take a list of flags After this previous commit I was thinking about the API of mi_gdb_start. I felt that the idea of passing flags as separate arguments and using 'args' to gather these into a list, though clever, was not an intuitive API. In this commit I modify mi_gdb_start so that it expects a single argument, which should be a list of flags. Thus, where we previously would have said: mi_gdb_start separate-mi-tty separate-inferior-tty We would now say: mi_gdb_start { separate-mi-tty separate-inferior-tty } However, it turns out we never actually call mi_gdb_start passing two arguments in this way at all. We do in some places do this: mi_gdb_start separate-inferior-tty But that's fine, a single string like this works equally well as a single item list, so this will not need updating. There is also one place where we do this: eval mi_gdb_start $start_ops where $start_ops is a list that might contains 0, 1, or 2 items. The eval here is used to expand the $start_ops list so mi_gdb_start sees the list contents as separate arguments. In this case we just need to drop the use of eval. I think that the new API is more intuitive, but others might disagree, in which case I can drop this change. There should be no change in what is tested after this commit. Diff: --- gdb/testsuite/gdb.mi/mi-exec-run.exp | 2 +- gdb/testsuite/lib/mi-support.exp | 24 ++++++++++++++++-------- 2 files changed, 17 insertions(+), 9 deletions(-) diff --git a/gdb/testsuite/gdb.mi/mi-exec-run.exp b/gdb/testsuite/gdb.mi/mi-exec-run.exp index ffbe6bcd36e..f8e6550850f 100644 --- a/gdb/testsuite/gdb.mi/mi-exec-run.exp +++ b/gdb/testsuite/gdb.mi/mi-exec-run.exp @@ -60,7 +60,7 @@ proc test {inftty_mode mi_mode force_fail} { lappend start_ops "separate-mi-tty" } - if [eval mi_gdb_start $start_ops] { + if [mi_gdb_start $start_ops] { return } diff --git a/gdb/testsuite/lib/mi-support.exp b/gdb/testsuite/lib/mi-support.exp index a231b8311b9..e578a7e6f9b 100644 --- a/gdb/testsuite/lib/mi-support.exp +++ b/gdb/testsuite/lib/mi-support.exp @@ -131,7 +131,13 @@ proc mi_create_inferior_pty {} { } } -proc mi_gdb_start_separate_mi_tty { args } { +# +# Like default_mi_gdb_start below, but the MI is created as a separate +# ui in a new tty. The global MI_SPAWN_ID is updated to point at the +# new tty created for the MI interface. The global GDB_MAIN_SPAWN_ID +# is updated to the current value of the global GDB_SPAWN_ID. +# +proc mi_gdb_start_separate_mi_tty { { flags {} } } { global gdb_prompt mi_gdb_prompt global timeout global gdb_spawn_id gdb_main_spawn_id mi_spawn_id @@ -139,8 +145,8 @@ proc mi_gdb_start_separate_mi_tty { args } { set separate_inferior_pty 0 - foreach arg $args { - if {$arg == "separate-inferior-tty"} { + foreach flag $flags { + if {$flag == "separate-inferior-tty"} { set separate_inferior_pty 1 } } @@ -183,6 +189,8 @@ proc mi_gdb_start_separate_mi_tty { args } { # # default_mi_gdb_start [FLAGS] -- start gdb running, default procedure # +# FLAGS is a list of flags, each flag is a string. +# # If "separate-inferior-tty" is specified, the inferior works with # it's own PTY. # @@ -193,7 +201,7 @@ proc mi_gdb_start_separate_mi_tty { args } { # tests on different hosts all using the same server, things can # get really slow. Give gdb at least 3 minutes to start up. # -proc default_mi_gdb_start { args } { +proc default_mi_gdb_start { { flags {} } } { global use_gdb_stub global GDB global INTERNAL_GDBFLAGS GDBFLAGS @@ -218,16 +226,16 @@ proc default_mi_gdb_start { args } { set separate_inferior_pty 0 - foreach arg $args { - if {$arg == "separate-mi-tty"} { + foreach flag $flags { + if {$flag == "separate-mi-tty"} { set separate_mi_pty 1 - } elseif {$arg == "separate-inferior-tty"} { + } elseif {$flag == "separate-inferior-tty"} { set separate_inferior_pty 1 } } if {$separate_mi_pty} { - return [eval mi_gdb_start_separate_mi_tty $args] + return [mi_gdb_start_separate_mi_tty $flags] } set inferior_pty no-tty
reply other threads:[~2022-05-03 9:48 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20220503094858.76CCC3858427@sourceware.org \ --to=aburgess@sourceware.org \ --cc=gdb-cvs@sourceware.org \ /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: linkBe 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).