Re: [cdt-debug-dev] Thread names in CDT debug view?

[Stefan Bylund <steby@xxxxxxx>]

Thanks for your information Mikhail. Using that information I browsed the CDT
source code to find out the involved parties used when constructing the thread
label used in the CDT debug view, see below.

I also provide a proposal for supporting native thread names/ids in the CDT
debug view, see below. I think that this is extremely important. A debug view
that only shows GDB's internal thread IDs and not the correspondig native thead
names or ids is very limited. The only way to find out (i.e. guess) the true
native identity of a thread in the CDT debug view is to click on all thread
nodes, examine their stack frame nodes and using knowledge of your source code
guess which native thread happens to execute that code. This is not acceptable
for real world usage where you may have an application consisting of many
threads.

You suggested that I should extend the
org.eclipe.debug.ui.debugModelPresentations extension point as is done by
org.eclipse.cdt.debug.internal.ui.CDTDebugModelPresentation in the
org.eclipse.cdt.debug.ui plugin. My impression by investigating the source code
(please correct me if I'm wrong) is that if I would follow this approach I would
effectively end up reimplementing the whole (and quite big)
org.eclipse.cdt.debug.ui plugin (since most of its implementation are in
internal packages that you are not supposed to reuse) just for the purpose of
changing the thread label in the CDT debug view. A change that really would
improve the useability of the CDT debugger and is potentially of use to many
users.

There may be a better solution than the one I propose. However, the main issue
is to provide some official way to support native thread names/ids in the CDT
debug view without resorting to hacking the CDT implementation and end up
maintaing your own version of CDT or extend a too high-level extension point and
thus reimplement much too many things. Surely, I can't be the only one to think
that this is a critical issue?

I should also point out that the way we determine native thread names in GDB is
by using the "info threads" GDB command implemented in a custom GDB remote
target connection. I believe that this approach is quite common in the embedded
world. On Solaris, the "info threads" GDB command reports the Solaris LWP id. I
don't remember what OS information "info threads" reports on Linux and Windows.

I would very much appreciate feedback on this issue from the CDT developers and
everyone else with an opinion and interest in this matter.

I also want to express that I find CDT a very exciting and promising project!

Best regards,
Stefan Bylund


CDT THREAD LABEL PRESENTATION IN CDT 1.2
----------------------------------------

1. The CDT debug view uses the
org.eclipse.cdt.debug.internal.ui.CDTDebugModelPresentation.getText() method to
render the thread labels. This method indirectly calls getThreadText() which
calls org.eclipse.debug.core.model.IThread.getName().

2. The CDT implementation of the org.eclipse.debug.core.model.IThread interface
is the org.eclipse.cdt.debug.internal.core.model.CThread class. This class has
an internal reference to an object of type
org.eclipse.cdt.debug.core.cdi.model.ICDIThread, which is implemented by
org.eclipse.cdt.debug.mi.core.cdi.model.Thread. The method
org.eclipse.cdt.debug.internal.core.model.CThread.getName() returns the string
returned by org.eclipse.cdt.debug.mi.core.cdi.model.Thread.toString().

3. The class org.eclipse.cdt.debug.mi.core.cdi.model.Thread stores the GDB
thread ID of the thread. The method
org.eclipse.cdt.debug.mi.core.cdi.model.Thread.toString() returns the GDB thread
ID integer as a string. (The org.eclipse.cdt.debug.mi.core.cdi.model.Thread
class also seems to be the natural container for storing a thread's name).

4. The org.eclipse.cdt.debug.mi.core.cdi.model.Thread objects for a debug target
is created by the org.eclipse.cdt.debug.mi.core.cdi.model.Target.getCThreads()
method. This method posts a org.eclipse.cdt.debug.mi.core.command.MIInfoThreads
GDB command and receives a corresponding
org.eclipse.cdt.debug.mi.core.output.MIInfoThreadsInfo GDB response. The method
getThreadIds() in this response is called to get an array of GDB thread ID
integers. Using this array, the org.eclipse.cdt.debug.mi.core.cdi.model.Thread
objects for this debug target are created and returned.


PROPOSAL
--------

* Add a method "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() could just return null or an empty array.

* Add a third argument to the org.eclipse.cdt.debug.mi.core.cdi.model.Thread
constructor for passing the thread name (the existing arguments are a reference
to the debug target object and the GDB thread ID integer).

* In the org.eclipse.cdt.debug.mi.core.cdi.model.Target.getCThreads() method,
call getThreadNames() (as well as getThreadIds()) in the
org.eclipse.cdt.debug.mi.core.output.MIInfoThreadsInfo GDB response and pass the
thread name (or null or an empty string if getThreadNames() returned null or an
empty array) 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.

* Change the org.eclipse.cdt.debug.mi.core.cdi.model.Thread.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.

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 thread names are not
available.

The only thing a 3rd party vendor has to do is 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 returns an
org.eclipse.cdt.debug.mi.core.output.MIInfoThreadsInfo subclass that overrides
getThreadNames(). The org.eclipse.cdt.debug.mi.core.output.MIInfoThreadsInfo
class parses the output from the "info threads" GDB command appropriately and
extracts the native thread names or ids.

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.


Mikhail Khodjaiants wrote:
>The "org.eclipse.cdt.debug.internal.ui.CDTDebugModelPresentation" class is
>responsible of rendering the thread labels. It is an extension of the
>"org.eclipse.debug.ui.debugModelPresentations" extension point. It uses the
>"getName()" method of the "IThread" interface to retrieve the thread name.
>
>Stefan Bylund wrote:
>>The standard CDT debug view shows the GDB thread IDs of the debugged
application
>>(e.g. "Thread[7] (Suspended)"). Instead of showing the GDB thread IDs, I want
to
>>show the thread names (e.g. "Thread[<threadname>] (Suspended)") as is done in
>>the standard JDT debug view for Java threads. This is much more useful if the
>>target OS supports thread naming and you have a large amount of threads in
your
>>application. Is there an extension point for this purpose? If not, which CDT
>>method(s) should I modify to get this behaviour?
>>
>>/Stefan

begin:vcard 
n:Bylund;Stefan
tel;cell:+46 709 714 325
tel;work:+46 8 507 143 25
x-mozilla-html:FALSE
url:http://www.ose.com
org:OSE Systems
adr:;;Nytorpsvägen 5;Täby;;183 23;Sweden
version:2.1
email;internet:steby@xxxxxxx
title:Software Engineer
fn:Stefan Bylund
end:vcard