Re: mi_load_progress question

[Nick Roberts <nickrob@snap.net.nz>]

 > > 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