From: Simon Marchi <simon.marchi@ericsson.com>
To: Tom Tromey <tromey@redhat.com>
Cc: <gdb-patches@sourceware.org>
Subject: Re: [PATCH v2] Fix argument passing in mi_run_cmd_full
Date: Tue, 20 May 2014 22:24:00 -0000 [thread overview]
Message-ID: <537BD614.5030600@ericsson.com> (raw)
In-Reply-To: <537B8561.6010603@ericsson.com>
On Tue 20 May 2014 12:40:01 PM EDT, Simon Marchi wrote:
> On Mon 19 May 2014 03:39:09 PM EDT, Tom Tromey wrote:
>>>>>>> "Simon" == Simon Marchi <simon.marchi@ericsson.com> writes:
>>
>> Simon> 2014-05-13 Simon Marchi <simon.marchi@ericsson.com>
>> Simon> * lib/mi-support.exp (mi_run_cmd_full): Set arguments by calling
>> Simon> "-exec-arguments" or "set args" before running the inferior.
>>
>> This patch causes a test failure here:
>
> Ehh, that's what I get for not re-running the testsuite, even after a
> year. I will send something soon about that.
mi-start.exp passes "--start" to mi_run_cmd, which is intended to be an argument to -exec-run. My understanding was that the parameter "args" of mi_run_cmd_full was for arguments to pass to the test program (hence, my patch). A quick grep shows that mi-start.exp is the only place where arguments are actually passed to mi_run_cmd. At the time the patch was written, nowhere in the test suite were parameters passed to mi_run_cmd, so I just assumed that this was the intended behavior. I ended up not even using this fix, since Pedro suggested that to modify the behavior of a test program, I should stop at a breakpoint and modify the value of a global variable instead.
Perhaps the original behavior was not bad after all: $args is passed to the command used to run the program, "run" or "-exec-run", depending on the value of $use_mi_command. Therefore, the meaning/semantic of the $args parameter changes based on the value of $use_mi_command: arguments passed to the test program if false, arguments to -exec-run (such as --start) if true. If you use MI and want to pass arguments to the test program, then you need to manually call -exec-arguments before (or a helper proc could be created for that). If documented properly, I think this way is good.
If we decide to stay with the current behavior where $args always means the arguments to pass to the test program, then we'll need to add a separate parameter to mi_run_cmd_full, mi_run_cmd and mi_run_with_cli to convey the arguments to pass to the run command (to be able to pass the --start). This makes things a little bit messy:
proc mi_run_cmd {args}
will become
proc mi_run_cmd {test_program_args run_command_args}
which means that most calls to mi_run_cmd will have to be changed from
mi_run_cmd
to
mi_run_cmd "" ""
because of the special vararg-like meaning of the parameter named "args".
In my opinion, I think the old behavior was fine, it just needs to be documented better (clarify what $args means in the mi_run_* procedures).
I would like to hear what you think about this.
Thanks,
Simon
next prev parent reply other threads:[~2014-05-20 22:24 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-13 21:47 Simon Marchi
2014-05-15 18:40 ` Tom Tromey
2014-05-15 19:47 ` Simon Marchi
2014-05-19 19:39 ` Tom Tromey
2014-05-20 16:40 ` Simon Marchi
2014-05-20 22:24 ` Simon Marchi [this message]
2014-05-21 8:46 ` 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=537BD614.5030600@ericsson.com \
--to=simon.marchi@ericsson.com \
--cc=gdb-patches@sourceware.org \
--cc=tromey@redhat.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