From: Daniel Jacobowitz <drow@false.org>
To: Andrew STUBBS <andrew.stubbs@st.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: MI problem
Date: Fri, 18 Nov 2005 17:12:00 -0000 [thread overview]
Message-ID: <20051118155426.GB9846@nevyn.them.org> (raw)
In-Reply-To: <437CD72D.70104@st.com>
Any MI folks listening?
On Thu, Nov 17, 2005 at 07:17:01PM +0000, Andrew STUBBS wrote:
> mi_load_progress is actually called through the function pointer
> deprecated_show_load_progress.
>
> The problem appears to be that the program is finding it's way into the
> MI through deprecated_show_load_progress when uiout is not set as expected.
Yes, this is the problem.
> The problem only occurs in -i=mi (no number) and -i=mi1 because
> mi_load_progress does not do anything in other versions. Strangely -i=mi
> is supposed to be the same as -i=mi2, but it isn't in this respect.
It looks like this is a mistake. I believe that when that check was
added, there were only MI and MI1. When the version was bumped, it was
left behind.
So should we fix it, or leave it disabled?
On a related note I would have expected current_interp_named_p to
return false while executing a program in the CLI interpreter.
interpreter_exec_cmd always sets the current interpreter. But
that is only the CLI implementation of interpreter-exec. The MI
implementation doesn't do this.
I'm always confused in the twisty maze of interpreters. I think we
can't ditch this broken behavior until we're done with "the CLI hack"
(CLI commands printing out MI format output because there is no
equivalent MI command). That'd be a good project for someone.
> I attach a patch which fixes both the crash and the inconsistency. I
> have tested it and got no unexpected failures. Of course I doubt the
> testsuite covers this feature ...
>
> OK? I would like to see this issued fixed in 6.4 also.
>
> Andrew Stubbs
> 2005-11-17 Andrew Stubbs <andrew.stubbs@st.com>
>
> * mi/mi-main.c (mi_load_progress): Don't do anything for -i=mi.
> Ensure the use of mi1 uiout for the duration of the function.
How about we commit this without the current_interp_named_p change for
now? Normally we'd need to use a cleanup to save and restore uiout,
but nothing here can throw exceptions AFAICT, so we're OK with the way
you've done it.
--
Daniel Jacobowitz
CodeSourcery, LLC
next prev parent reply other threads:[~2005-11-18 15:54 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4378DDB4.3020702@st.com>
[not found] ` <20051117042008.GE3513@nevyn.them.org>
2005-11-17 19:53 ` Andrew STUBBS
2005-11-18 17:12 ` Daniel Jacobowitz [this message]
2005-11-18 17:33 ` Andrew STUBBS
2005-11-18 18:19 ` Daniel Jacobowitz
2005-11-18 19:21 ` Andrew STUBBS
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=20051118155426.GB9846@nevyn.them.org \
--to=drow@false.org \
--cc=andrew.stubbs@st.com \
--cc=gdb-patches@sources.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