Re: info thread

[Mark Kettenis <mark dot kettenis at xs4all dot nl>]

> Date: Mon, 18 Sep 2006 10:20:00 +0200
> From: Denis PILAT <denis.pilat@st.com>
> 
> Daniel,
> 
> I'd like your opinion about a feature that we need to implement in gdb. 
> We'd like to choose the solution that has the best chance to be accepted 
> and integrated in GDB.
> 
> As you may know, Eclipse is using "info threads" command to get thread 
> Ids. The problem is that some part of this command is not used by 
> Eclipse and can take a lot of time to execute when the debugger is 
> remotely connected to a board. In our case we have a 100 threads 
> application and the info threads takes a lot of time to execute, and in 
> Eclipse this command is run each time the user push the "next" button, 
> which leads to a non usable graphical interface.
> The stack frame information is not used at all by Eclipse and removing 
> this part saves 70% of the execution time in our case.
> Eclipse used the thread list IDs and the extra information which are 
> target specific (usually we get thread names in these information but it 
> can be whatever the targets puts)
> 
> 
> The solutions we thought are the following:
> 
> Sol 1 - developping a new MI command that gives the above target extra 
> information only (ie -thread-list-extra-info) of implementing a 
> non-implemented one with a parameter.
> I see in the doc that -thread-list-all-threads is not specified for 
> instance.
> 
> Then we need to modify Eclipse so that it uses MI command 
> "-thread-list-ids" plus this command to get all he needs.
> This can be an Eclipse contribution as well, I need to ask to Eclipse 
> maintainer as well.
> 
> Sol 2 - a parameter to the "info thread" CLI command that ask gdb to not 
> print stack frame information but only thread IDs lists and extra_info.
> (ie info thread nostackframe)
> 
> Sol 3 - a new gdb env variable that do the same as the above parameter.
> 
> 
> What is your opinion about that ?

The default output of "info thread" should not be changed.  Ans I
think we shouldn't complicate the "info thread" command unless it
helps human CLI users.

> Which solution could be adopted ?

I favour Sol 1.

Mark