Re: info thread

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

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

This isn't a patch so isn't the gdb mailing list more appropriate?

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

Some form of event notification would be desirable where GDB tells the
front end that the relevant information has changed (pie in the sky thought,
I have no idea how to implement it).

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

There is only a slot for -thread-list-all-threads and no implementation so I
see no harm in using a new name, especially if your command doesn't list _all_
the info.  I'm not very familiar with debugging threaded applications but I
think the command should be general and not just suited to your requirements.
Also if there is a common usage pattern then I think it would be good if that
information can be obtained with one MI command rather than two/many.  That is
the essence of many of the changes that I have made to MI.

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

I think this would be a bad idea because CLI output is for human consumption,
and someone could quite reasonably change the output later and break your
front end.  With MI the intention is to change the output in predictable and
manageable ways.

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