This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: info thread
- From: Mark Kettenis <mark dot kettenis at xs4all dot nl>
- To: denis dot pilat at st dot com
- Cc: drow at false dot org, gdb-patches at sourceware dot org
- Date: Sat, 23 Sep 2006 19:15:29 +0200 (CEST)
- Subject: Re: info thread
- References: <450E56B0.806@st.com>
> 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