info thread

[Denis PILAT]

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 ?
Which solution could be adopted ?

Regards
Denis PILAT