Re: New mi commands for threads

[Nick Roberts <nickrob at snap dot net dot nz>]

 > > Lists use square brackets, information on each thread should be enclosed in
 > > curly brackets:
 > >
 > > threads=[{thread-id="6",frame={...},thread-extra-info="bla"},{thread-id="5",frame={...},thread-extra-info="bla"},...]
 > >
 > > I guess your output has been manually generated as thread-id="1" seems to
 > > duplicate some information.
 > This output is a side effect of the frame printing, the actual 
 > -thread-select command has the same. I'm going to have a look at how we 
 > can avoid it, but I think it will impact *-thread-select* as well.

OK, I dodn't realise that.  Interestingly the example in the manual doesn't
show the duplicate information (or the fullname field, so it will have to be
updated).  It seems to due to the fact that do_captured_thread_select uses
SRC_AND_LOC, while the other MI commands use LOC_AND_ADDRESS.  I see that
normal_stop specifies LOC_AND_ADDRESS specifically for MI.  It looks a bit
of a hack but perhaps we should do the same for do_captured_thread_select:

	  /* For mi, have the same behavior every time we stop:
	     print everything but the source line. */
	  if (ui_out_is_mi_like_p (uiout))
	    source_flag = LOC_AND_ADDRESS;


 > About brackets, I see how they were used in *-thread-list-ids*, 
 > according to your comment, this one should use square brackets as well, 
 > am I right ?

Yes, I think it, should but we probably shouldn't change it until we bump the
MI level.  It's probably a legacy from mi0 when all brackets were curly ones.

 > About position of "number-of-threads" and "current-thread-id", I prefer 
 > them in front as well, but that would be not consistent with 
 > -thread-list-ids. But do we care about consistency with this one that 
 > seems to be not consistent with the MI list format  ? 

Well one lists threads and the other lists thread ids, so I don't see a
problem.

 > > I thought that the frame information was expensive to get and that it was
 > > agreed you could get it, if needed, using other MI commands anyway.
 > Yes it is, but I want to get rid of CLI commands and for front ends that 
 > want to get all informations, they could use this command if they need 
 > extra information. But I can add an option to include or not these 
 > information.
 > For remote (or on board) debugging, our front ends will emit 
 > *-thread-list-ids* to get only the list, and then *-thread-info* to 
 > focus only on the current thread.

OK, I see now.

-- 
Nick                                           http://www.inet.net.nz/~nickrob