This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: mi_load_progress question
> > I have no experience with remote debugging, so I can only suggest that
> > it's consistent i.e have progress reporting for all cases or turn it off
> > completely (I don't know how useful it is or why it should only exist in
> > MI).
>
> There's similar output from the CLI including speed and section name.
The progress reporting is described for -target-download but not mentioned
for load.
> > If the answer is yes, I suggest something like the patch below. Unless I'm
> > missing something mi_load_progress only gets called in MI. I would like to
> > make similar but more fiddly changes to mi-interp.c, removing
> > mi`N'_command_loop, N = 1,2,3, and just using mi_command_loop.
>
> You're wrong; take a look at the URL from my message. If you
> type "load" at the MI prompt, the hook remains installed, but we get
> called while the CLI is temporarily active. Doing this will probably
> crash.
OK. I can see a problem now: if I start GDB normally and use a command like
"interpreter mi -environment-pwd". Otherwise deprecated_show_load_progress is
presumably only set to mi_load_progress if GDB is invoked with "-i=mi[N]" as
there is currently there is no ability to switch interpreters permanently in
FSF GDB. Or is the problem more general than that?
When I read the thread I thought it was referring to executing CLI commands
from MI, in which case you presumably would want the MI output.
Perhaps mi_load_progress could just do:
if (mi_version (uiout) != 0)
uiout = mi_out_new (mi_version (uiout));
else
return;
> You can test this using gdbserver; "load" isn't useful with gdbserver,
> but if you load the same binary gdbserver started, it works well enough
> to test "load".
I don't see how mi_load_progress would run in this case.
--
Nick http://www.inet.net.nz/~nickrob