Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cdt-dev] Displaying thread names in debug view


> Subject: [cdt-dev] Displaying thread names in debug view
> 
> Hello folks,
> 
> a colleague of mine was wondering why the debug view does not display
> thread names when the gdb debugger does return them when queried with
> "info threads":
> 
> ===================
> [1.123.068.100.723] 16 info threads
> [1.123.068.100.723] (gdb)
> [1.123.068.100.723] ~"info threads\n"
> [1.123.068.100.793] ~"  5 Thread 8 ( Name: TIMERThread, State: sleeping,
> Priority: 14 )  "
> [1.123.068.100.843] ~"  4 Thread 3 ( Name: Network support, State:
> sleeping, Priority: 7 )  "
> [1.123.068.100.893] ~"  3 Thread 2 ( Name: Network alarm support, State:
> sleeping, Priority: 6 )  "
> [1.123.068.100.953] ~"  2 Thread 1 ( Name: Idle Thread, State: ready,
> Priority:31 )  "
> [1.123.068.100.993] ~"* 1 Thread 9 ( Name: pthread.00000800, State:
> running, Priority: 15 )  "
> ===================
> 
> I looked into it and found the follwing:
> 
> - org.eclipse.cdt.debug.mi.core.output.CLIInfoThreadsInfo analyzes the
> gdb output.
> - CLIInfoThreadsInfo.getThreadNames() currently simply returns null.
> - CLIInfoThreadsInfo.parseThreadInfo(String, List) currently only parses
> for the thread number.
> - It is easy to augment parseThreadInfo(String, List) so that it
> retrieves the thread name along with the number and then properly
> implement getThreadNames(). This is sufficient for getting the thread
> names displayed in the debug view.
> 
> Now we would find it a very handy feature to have the thread names and
> would do the implementation and supply the patches and all this. My
> question to the community are:
> 
> - Would this solution be accepted?

Yes, if it does not break other parsing i.e. the parsing still works for
platform not having this feature.

> Did I overlook anything?

-thread-list-id command in the MI protocol. We use "info threads" because
this MI command was not acting correctly in many releases of GDB.  It may be
fix in more recent version of gdb.  What does the command return?

 gdb -i mi
 ...
 -break-insert main
 -exec-run
 -thread-list-ids



> - Can I proceed to create a bugzilla entry?

Absolutely.

> - Who will evaluate the patches?

The committers.

> - For which version of CDT will it be available?
>

3.1 for sure, 3.0.1 maybe.
 



Back to the top