From: Tom Tromey <tromey@adacore.com>
To: Simon Marchi <simark@simark.ca>
Cc: Tom Tromey <tromey@adacore.com>, gdb-patches@sourceware.org
Subject: Re: [PATCH v2 8/9] Implement gdb.execute_mi
Date: Thu, 08 Jun 2023 14:16:03 -0600 [thread overview]
Message-ID: <87h6rhaews.fsf@tromey.com> (raw)
In-Reply-To: <3f4fa15a-29f0-f1bb-f824-fbe9d344c397@simark.ca> (Simon Marchi's message of "Mon, 29 May 2023 11:54:17 -0400")
Simon> There are not a lot of commands getting the current interpreter,
Simon> but -gdb-exit is one of them.
I looked at this a little bit today.
I found 4 places doing this:
struct mi_interp *mi = (struct mi_interp *) command_interp ();
A couple of these are, IMO, latent bugs.
For -gdb-exit in particular, it seems completely fine for me to simply
not print anything if the command interpreter is not an MI interpreter.
After all, gdb is about to exit, and the Python call isn't returning
anyway.
Some other spots should probably use gdb::checked_static_cast to find
bugs earlier.
Simon> The other places that get the current interpreter are mostly in the
Simon> observers that output notifications. So that got me wondering, what
Simon> should we do with any MI notification happening during the execution of
Simon> the MI command?
I still haven't looked into this part.
Tom
next prev parent reply other threads:[~2023-06-08 20:16 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-18 20:18 [PATCH v2 0/9] Implement the DAP "loadedSources" request Tom Tromey
2023-05-18 20:18 ` [PATCH v2 1/9] Use field_signed from Python MI commands Tom Tromey
2023-05-18 20:18 ` [PATCH v2 2/9] Use member initializers in mi_parse Tom Tromey
2023-05-18 20:18 ` [PATCH v2 3/9] Use accessor for mi_parse::args Tom Tromey
2023-05-18 20:18 ` [PATCH v2 4/9] Change mi_parse_argv to a method Tom Tromey
2023-05-18 20:18 ` [PATCH v2 5/9] Introduce "static constructor" for mi_parse Tom Tromey
2023-08-11 11:02 ` Andrew Burgess
2023-08-11 13:10 ` Tom Tromey
2023-08-11 15:06 ` Andrew Burgess
2023-05-18 20:18 ` [PATCH v2 6/9] Introduce mi_parse helper methods Tom Tromey
2023-05-18 20:18 ` [PATCH v2 7/9] Add second mi_parse constructor Tom Tromey
2023-05-18 20:18 ` [PATCH v2 8/9] Implement gdb.execute_mi Tom Tromey
2023-05-19 5:37 ` Eli Zaretskii
2023-05-29 15:54 ` Simon Marchi
2023-06-02 19:19 ` Tom Tromey
2023-06-08 20:16 ` Tom Tromey [this message]
2023-05-18 20:18 ` [PATCH v2 9/9] Implement DAP loadedSources request Tom Tromey
2023-05-23 19:46 ` [PATCH v2 0/9] Implement the DAP "loadedSources" request Tom Tromey
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=87h6rhaews.fsf@tromey.com \
--to=tromey@adacore.com \
--cc=gdb-patches@sourceware.org \
--cc=simark@simark.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).