[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[cdt-debug-dev] [Fwd: info thread]
|
Hi everyone,
I forward you a message I just sent the gdb maintainer about the usage
of "info threads" gdb command in Eclipse.
I need your opinion on the proposed solutions.
Regards
Denis PILAT / STMicroelectronics
-------- Original Message --------
Subject: info thread
Date: Mon, 18 Sep 2006 10:20:00 +0200
From: Denis PILAT <denis.pilat@xxxxxx>
Organization: STMicroelectronics
To: Daniel Jacobowitz <drow@xxxxxxxxx>
CC: gdb-patches <gdb-patches@xxxxxxxxxxxxxx>
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