From: Pedro Alves <palves@redhat.com>
To: Simon Marchi <simon.marchi@polymtl.ca>
Cc: Simon Marchi <simon.marchi@ericsson.com>, gdb-patches@sourceware.org
Subject: Re: [PATCH] Don't send queries to the MI interpreter
Date: Fri, 10 Feb 2017 17:12:00 -0000 [thread overview]
Message-ID: <bc3b0ad5-992e-5f92-cc8d-9e4591aa2e0a@redhat.com> (raw)
In-Reply-To: <e03e55ab52be7aa11fe7e17a7b920feb@polymtl.ca>
On 02/10/2017 04:52 PM, Simon Marchi wrote:
> On 2017-02-10 11:48, Pedro Alves wrote:
>> On 02/10/2017 04:36 PM, Simon Marchi wrote:
>>> We have a little problem in Eclipse CDT related to queries being sent on
>>> the MI channel. GDB sends queries on the MI stream and waits for an
>>> answer (y or n), but since CDT will never answer, it causes a deadlock.
>>>
>>> Note that this is only a problem when using MI as a side-channel
>>> (new-ui) on a dedicated tty. It doesn't happen if GDB's input/output
>>> streams are pipes, for example. In that case, the queries are
>>> auto-answered as they should.
>>
>> I think we could have a testsuite test for this, as the 'new-ui'-related
>> testcases create a pty for the secondary MI channel ("separate-mi-tty")?
>
> Right, I didn't think of making a test, I'll work on it. I'll try to
> find a query that's easier to trigger than the
> modify-memory-while-replaying one though.
I've run into these queries deep down in the record layer
in the past, and wondered about getting rid of them.
Particularly this one:
if (!yquery (_("Do you want to auto delete previous execution "
"log entries when record/replay buffer becomes "
"full (record full stop-at-limit)?")))
error (_("Process record: stopped by user."));
In order to query, the inferior is already temporarily stopped.
So why not just unconditionally error, and lets user tweak
"set record stop-at-limit" and continue if they want.
In this case, instead of:
query (_("Because GDB is in replay mode, changing the "
"value of a register will make the execution "
"log unusable from this point onward. "
"Change all registers?"));
we'd error here with something like:
Cannot change the value of a register in replay mode, it would
make the execution log unusable from this point onward. See whatnot.
and then if users really want to change memory, they would use
something like a "record discard" or "record commit" or some such
command that discards history leaving the inferior state as it
is right now (not sure there's a command that does that already.)
In scripts and maybe frontends, you'd use the existing
"set record memory-query off", renamed to
"set record allow-memory-write on" or some such.
Thanks,
Pedro Alves
next prev parent reply other threads:[~2017-02-10 17:12 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-10 16:37 Simon Marchi
2017-02-10 16:48 ` Pedro Alves
2017-02-10 16:52 ` Simon Marchi
2017-02-10 17:12 ` Pedro Alves [this message]
2017-02-10 17:44 ` Pedro Alves
2017-02-10 18:07 ` Pedro Alves
2017-02-10 18:36 ` Pedro Alves
2017-02-10 19:08 ` Simon Marchi
2017-02-10 19:23 ` Pedro Alves
2017-02-10 19:06 ` Simon Marchi
2017-02-10 19:20 ` Pedro Alves
2017-02-10 19:26 ` Simon Marchi
2017-02-10 19:32 ` Pedro Alves
2017-02-10 19:30 ` Pedro Alves
2017-02-10 19:03 ` Simon Marchi
2017-02-10 19:08 ` 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=bc3b0ad5-992e-5f92-cc8d-9e4591aa2e0a@redhat.com \
--to=palves@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=simon.marchi@ericsson.com \
--cc=simon.marchi@polymtl.ca \
/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