Bug 69711

Description Stefan Bylund 2004-07-09 08:58:45 EDT

Add support for thread names in CDT debug view


OVERVIEW

This proposal suggests an enhancement to the org.eclipse.cdt.debug.mi.core
plugin for optionally retrieving OS-specific thread information like native
thread names or ids and display that information in the CDT debug view. By
default, only GDB thread ids are displayed in the CDT debug view. With this
enhancement, the CDT debug view may display "Thread[7 <threadname>] (Suspended)"
instead of just "Thread[7] (Suspended)". This is much more useful if the target
OS supports thread naming and you have a large amount of threads in your
application.

The way to determine native thread names in GDB is by using the "info threads"
command. For several GDB backends this command will report additional
OS-specific thread information. Unfortunately, the format of the OS-specific
contribution to the output of the "info threads" command is not specified.
Hence, this suggested enhancement does not retrieve OS-specific thread
information by itself but provides the foundation for a third party to do this.

When/if the MI command "-thread-list-ids" is enhanced to indicate which thread
is the current thread and to provide the native thread name (if any) in a strict
format, this enhancement could be done in a more elegant manner directly in the
standard CDT without the need for any third party extension. However, this
feature has not yet been implemented in GDB 6.x.

For reference, this issue was discussed in the cdt-debug-dev mailing list in
January 2004 (http://dev.eclipse.org/mhonarc/lists/cdt-debug-dev/mail2.html).
Alain Magloire suggested that I would file a PR and provide a corresponding
patch. This is the PR and soon I will supply a patch to the cdt-patch mailing
list for review.


PROPOSAL

1. Add a method "public String[] getThreadNames()" to
org.eclipse.cdt.debug.mi.core.output.MIInfoThreadsInfo that would return an
array of thread names in the same order as the array of GDB thread ID integers
returned by the existing getThreadIds() method. The default implementation of
getThreadNames() would return null.

2. In the org.eclipse.cdt.debug.mi.core.cdi.model.Thread class, add a new string
field for storing the native thread name. Add a new constructor that has the
same signature as the existing constructor but with an additional third argument
for passing the thread name (to avoid code duplication, the existing constructor
could call this new constructor with null as third argument). The reason for not
modifying the signature of the existing constructor is to minimize the impact.
Change the toString() method so that it returns a string consisting of the GDB
thread ID integer and, if the thread name is available, a space character
followed by the thread name.

3. In the org.eclipse.cdt.debug.mi.core.cdi.model.Target.getCThreads() method,
call getThreadNames() (as well as getThreadIds()) in the
MIInfoThreadsInfo response and, if it returns non-null, pass the thread name as
the third argument to the org.eclipse.cdt.debug.mi.core.cdi.model.Thread
constructor when creating the org.eclipse.cdt.debug.mi.core.cdi.model.Thread
objects for this debug target.

In this way, the
org.eclipse.cdt.debug.internal.ui.CDTDebugModelPresentation.getThreadText()
method will render the thread label as "Thread[<gdb-thread-id>
<native-thread-name>]" or just "Thread[<gdb-thread-id>]" if native thread names
are not available.


USAGE

In order to take advantage of this new feature, a third party has to implement
his own org.eclipse.cdt.debug.core.ICDebugger class (supported by the
org.eclipse.cdt.debug.core.CDebugger extension point) that installs its own
org.eclipse.cdt.debug.mi.core.command.CommandFactory subclass that overrides
createMIInfoThreads() to return an
org.eclipse.cdt.debug.mi.core.command.MIInfoThreads subclass that overrides
getMIInfo() to return an
org.eclipse.cdt.debug.mi.core.output.MIInfoThreadsInfo subclass that overrides
getThreadNames(). The org.eclipse.cdt.debug.mi.core.output.MIInfoThreadsInfo
subclass parses the output from the "info threads" command appropriately and
extracts the native thread names.

This approach is very similar to how the Cygwin GDB adaptation is done today
using org.eclipse.cdt.debug.mi.core.CygwinGDBDebugger,
org.eclipse.cdt.debug.mi.core.command.CygwinCommandFactory, and
org.eclipse.cdt.debug.mi.core.command.CygwinMIEnvironmentDirectory.