Community
Participate
Working Groups
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.
Patch apply on the head. Is this for the 2.0 branch also ?
Apply to cdt-2.0.1 branch