[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[cdt-debug-dev] Re: cdt-debug-dev Digest, Vol 17, Issue 9
|
Hi, Stefan:
Thanks for the quick reply.
I looked at the proposal
https://bugs.eclipse.org/bugs/show_bug.cgi?id=69711. I can see the patches in CDT
3.1. However I guess it is a little different from our problem.
Let me clarify my problem:
When user selects the IThread element in the Debug view, I want to provide the output of the "info thread" to the user. User may select more than one elements under same Target.
To solve the problem, I expect CDT to expose the whole output of "info threads" to the user. I think the following two sub problems should be addressed:
1) Should the thread info be saved or recreated each time when user select the thread?
2) When user select the element in Debug view, how can he get the thread info from the current selection?
For subproblem 1), I think Thread(or somewhere else?) should keep the info threads output, and refreshing the thread info is not necessary, because when response to the Debug Suspend event, CDT should have already updated the thread info. To keep CDT platform independent,the output will be kept as a String (Only user who cares about this output should parse it). The alternative of 1) may be to post a new info thread command to MISession.
For subproblem 2), I could not find a way (if you can, please let me know) to figure out exactly the underlying mi.core.cdi.model.Thread of an IThread based on current CDT3.1 (we can only get the Thread[] and currentThread:-< from the target). I then decide to change the CDT
debug.core, and add an adapter factory to the CThread.class, so that it can return an ICDIThread when user select IThread in Debug view.
I guess someone else may also have similiar problem, so I just wonder if the following related change could be adopted in the futuren CDT release:
- Add a field info to the mi.core.cdi.model.Thread class to keep the output of the info thread
- Make the ICThread/IThread adaptable, so that getAdapter(ICDIThread) can be used to find the ICDIThread. Similiar changes for IStackFrame and other debug element. The alternative of this change is to make the CThread::getCDIThread() public.
Thanks
-Chengdong
------------------------------
Date: Tue, 25 Jul 2006 15:13:58 +0200
From: Stefan Bylund <steby@xxxxxxx>
Subject: Re: [cdt-debug-dev] Collect more thread information - About
"info thread" output?
Hi Chengdong,
There is support for optionally displaying thread names in the CDT debug
view. This feature was added in the patch
http://dev.eclipse.org/mhonarc/lists/cdt-patch/msg02506.html
and
described in the corresponding bug report
https://bugs.eclipse.org/bugs/show_bug.cgi?id=69711.
This patch was initiated by a discussion of this issue found here:
http://dev.eclipse.org/mhonarc/lists/cdt-debug-dev/msg00462.html
The conclusion was that there is no reliable way to retrieve thread
names and other thread metadata from the output of the "info threads"
command in a platform-independent manner. Instead, we choose to only
provide the foundation for a third party to do this.
I think you can use the mechanism described in bug report 69711 to
display thread names and any other thread metadata you may have.
Regards,
/Stefan
chengdong li wrote:
>
> Hi,
>
>
> We have a problem to retrieve the thread information based on current
> CDT3.1. For our system, we want to know the underlying thread ID and
> other thread information when user selects an IThread in the Debug
> view (or LaunchView). However, there is no way through the API to
> retrieve such information (let me know if there is one :-)).
>
>
>
> The current org.eclipse.cdt.debug.mi.core.output.CLIInfoThreadsInfo
> only keeps the thread id assigned by GDB. For example:
> The info thread command for a standard GDB will return the following
> output for pthread:
> 3 Thread -1217840208 (LWP 23518) 0xb7f6c17c in clone () from
> /lib/tls/libc.so.6
> * 2 Thread -1209451600 (LWP 23517) do_nothing (null=0x0) at
> pthread_Test.c:12
> 1 Thread -1208182528 (LWP 23514) 0xb7f6c17c in clone () from
> /lib/tls/libc.so.6
>
> For our system, our GDB will return the following output for a thread:
> 6 Thread 121 (state=STOP, ID=0x0000100, name="THREAD
No.1",
> priority=211)
>
> CLIInfoThreadInfo only keeps the id (the first digit of above output
> lines). All the information besides the thread id will be also useful
> to us. However, we could not find a way to access the output by using
> current API.
>
> Here is our solution:
> - Add a String[] to the CLIInfoThreadsInfo class:
> class CLIInfiThreadsInfo{
> protected String[] infos;
> public String[] getThreadInfos(){
> return infos;
> }
> }
> The infos[] will be sorted together with threadIds[].
>
>
> - Change the org.eclispe.cdt.debug.mi.core.cdi.model.Thread constructor:
> class Thread{
> protected String info;
> public String getThreadInfo(){
> return info;
> }
> public Thread(Target target, int threadId, String info)
> implements ICDIThread{
> this(target, threadId, null, info);
> }
> public Thread(Target target, int threadId, String threadName,
> String threadInfo){
> super(target);
> id=threadId;
> name=threadName;
> info = threadInfo;
> }
> }
> And refactor the caller of Thread (only few places in mi.core
> package need change).
>
>
> - Add an adapter factory to the CThread.class, so that it can return
> an ICDIThread when user select IThread in Debug view. This is done in
> the org.eclipse.cdt.debug.internal.core.model
package.
>
>
> I think the above change does not break the other modules. I am not
> sure if this is a good solution or not. If is there any other solution
> available without changing the CDT code, please let me know. If above
> changes make sense, I can send you a patch.
>
>
> Thanks
>
> -Chengdong
>
>
