Bugzilla – Full Text Bug Listing
| Summary: | [multi-core] Make use of GDB 7.1 support for displaying cores for threads and processes | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Tools] CDT | Reporter: | Marc Khouzam <marc.khouzam> | ||||||||||||||||||
| Component: | cdt-debug-dsf-gdb | Assignee: | Marc Khouzam <marc.khouzam> | ||||||||||||||||||
| Status: | RESOLVED FIXED | QA Contact: | Marc Khouzam <marc.khouzam> | ||||||||||||||||||
| Severity: | normal | ||||||||||||||||||||
| Priority: | P3 | CC: | nobody, pawel.1.piech | ||||||||||||||||||
| Version: | 7.0 | Flags: | marc.khouzam:
review?
(nobody) |
||||||||||||||||||
| Target Milestone: | 8.0 | ||||||||||||||||||||
| Hardware: | PC | ||||||||||||||||||||
| OS: | Linux | ||||||||||||||||||||
| Whiteboard: | |||||||||||||||||||||
| Attachments: |
|
||||||||||||||||||||
|
Description
Marc Khouzam
Created attachment 172943 [details]
Screenshot of suggestion #1
Here is what suggestion #1 would bring.
Created attachment 172945 [details]
Enhance classes for -list-thread-groups and -trhead-info to read 'core' field
This patch simply adds the infrastructure to read the new core field from the -list-thread-groups and -thread-info commands
Committed to HEAD.
*** cdt cvs genie on behalf of mkhouzam *** Bug 318230: Add infrastructure to read the new core field from the -list-thread-groups and -thread-info commands [*] MIListThreadGroupsInfo.java 1.5 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/mi/service/command/output/MIListThreadGroupsInfo.java?root=Tools_Project&r1=1.4&r2=1.5 [*] MIThreadInfoInfo.java 1.3 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/mi/service/command/output/MIThreadInfoInfo.java?root=Tools_Project&r1=1.2&r2=1.3 [*] MIThread.java 1.3 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/mi/service/command/output/MIThread.java?root=Tools_Project&r1=1.2&r2=1.3 [*] MIListThreadGroups.java 1.4 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/mi/service/command/commands/MIListThreadGroups.java?root=Tools_Project&r1=1.3&r2=1.4 Marc, I think it would be useful to have an option in the debug view that allows users to group threads by cores. Your screenshot would look like this:
- core2
- thread3
- core3
- thread1
- thread2
Users would be able to switch from the "traditional" view to the "core" view and back. I have seen it in some commercial products and think it is doable.
Don't know if any kind of core related GDB commands is available now but I am sure it will follow.
(In reply to comment #4) > Marc, I think it would be useful to have an option in the debug view that > allows users to group threads by cores. Your screenshot would look like this: > > - core2 > - thread3 > - core3 > - thread1 > - thread2 > > Users would be able to switch from the "traditional" view to the "core" view > and back. I have seen it in some commercial products and think it is doable. I think this is a great suggestion! I have added it to the wiki page at http://wiki.eclipse.org/CDT/designs/MultiCoreDebug#Showing_cores_in_Debug_view_labels I think it will require a little effort to change the view display, but I think we could do it. > Don't know if any kind of core related GDB commands is available now but I am > sure it will follow. What did you have in mind, as an example? (In reply to comment #5) > I think it will require a little effort to change the view display, but I think > we could do it. > I don't think that would be a problem. > > Don't know if any kind of core related GDB commands is available now but I am > > sure it will follow. > > What did you have in mind, as an example? I don't have any multi-core experience, but as far as I remember there were commands for synchronized stepping in the start/stop debug mode for hardware debugging as well as halt/run commands for a core or a group of cores. (In reply to comment #4) > - core2 > - thread3 > - core3 > - thread1 > - thread2 This works well for single process debugging which I assume you saw as: - process1 - core2 - thread3 - core3 - thread1 - thread2 But when we deal with multi-process debugging it is not as obvious. How should we we convert the standard display of: - process1 - thread3 [core 2] - thread2 [core 3] - thread1 [core 3] - process2 - thread2 [core 3] - thread1 [core 1] We could group by cores, but keep process grouping: - process1 - core2 - thread3 - core3 - thread1 - thread2 - process2 - core1 - thread1 - core3 - thread2 Or we could group completely by cores and use a label for the process, something like: - core1 - thread1 (process2) - core2 - thread3 (process1) - core3 - thread1 (process1) - thread2 (process1) - thread2 (process2) (In reply to comment #7) > This works well for single process debugging which I assume you saw as: > > - process1 > - core2 > - thread3 > - core3 > - thread1 > - thread2 > Yes, the commercial product I mentioned worked only for single process. It's not an Eclipse based product, so there is no "process" node. > But when we deal with multi-process debugging it is not as obvious. How should > we we convert the standard display of: > > - process1 > - thread3 [core 2] > - thread2 [core 3] > - thread1 [core 3] > - process2 > - thread2 [core 3] > - thread1 [core 1] > > We could group by cores, but keep process grouping: > > - process1 > - core2 > - thread3 > - core3 > - thread1 > - thread2 > - process2 > - core1 > - thread1 > - core3 > - thread2 > > Or we could group completely by cores and use a label for the process, > something like: > > - core1 > - thread1 (process2) > - core2 > - thread3 (process1) > - core3 > - thread1 (process1) > - thread2 (process1) > - thread2 (process2) More options :) - core - process - thread Speaking seriously, I am not a hardware debugging expert. We should ask somebody who has experience with it. (In reply to comment #8) > Speaking seriously, I am not a hardware debugging expert. We should ask somebody > who has experience with it. I agree. I think getting input from others on multi-core support will be valuable. Hopefully, there will be interest from the CDT community during the Indigo development. Created attachment 173595 [details]
Screenshot showing cores for processes also
Created attachment 173597 [details]
Patch to show cores for processes and threads
This patch adds a label to processes and threads to show the cores on which the process/thread is presently located. The previous attached screenshot shows the result of this patch.
Since threads can move from a core to another at anytime we don't actually refresh all the time; instead we refresh when the debugger suspends or when a new thread/process is created/destroyed.
This feature can only be trigerred by using GDB 7.1.
I will commit it to HEAD, but will adapt the solution to any comments I may get.
Mikhail, maybe you can review this change? It adds a new service version for GDB 7.1 and a couple of new interfaces to access the new 'cores' field. (In reply to comment #12) > Mikhail, maybe you can review this change? > It adds a new service version for GDB 7.1 and a couple of new interfaces to > access the new 'cores' field. I'll take a look at it tomorrow if you don't mind. (In reply to comment #13) > (In reply to comment #12) > > Mikhail, maybe you can review this change? > > It adds a new service version for GDB 7.1 and a couple of new interfaces to > > access the new 'cores' field. > I'll take a look at it tomorrow if you don't mind. Of course. In fact, from what was discussed in the mailing list, a committer that is asked for a review is not bound to actually do it, it is of course a voluntary effort. Also, the review can be done at any time, days, weeks or months later, depending on the committers free time. With the 'review' flag set, it is easy to get back to bugs that require a review. *** cdt cvs genie on behalf of mkhouzam *** Bug 318230: Use GDB 7.1 support for displaying cores for threads and processes in a label within the debug view. [*] GdbExecutionContextLabelText.java 1.3 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb.ui/src/org/eclipse/cdt/dsf/gdb/internal/ui/viewmodel/launch/GdbExecutionContextLabelText.java?root=Tools_Project&r1=1.2&r2=1.3 [*] ThreadVMNode.java 1.7 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb.ui/src/org/eclipse/cdt/dsf/gdb/internal/ui/viewmodel/launch/ThreadVMNode.java?root=Tools_Project&r1=1.6&r2=1.7 [*] MessagesForGdbLaunchVM.java 1.4 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb.ui/src/org/eclipse/cdt/dsf/gdb/internal/ui/viewmodel/launch/MessagesForGdbLaunchVM.java?root=Tools_Project&r1=1.3&r2=1.4 [*] ContainerVMNode.java 1.4 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb.ui/src/org/eclipse/cdt/dsf/gdb/internal/ui/viewmodel/launch/ContainerVMNode.java?root=Tools_Project&r1=1.3&r2=1.4 [*] IGdbLaunchVMConstants.java 1.3 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb.ui/src/org/eclipse/cdt/dsf/gdb/internal/ui/viewmodel/launch/IGdbLaunchVMConstants.java?root=Tools_Project&r1=1.2&r2=1.3 [*] MessagesForGdbLaunchVM.properties 1.2 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb.ui/src/org/eclipse/cdt/dsf/gdb/internal/ui/viewmodel/launch/MessagesForGdbLaunchVM.properties?root=Tools_Project&r1=1.1&r2=1.2 [*] MIThread.java 1.4 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/mi/service/command/output/MIThread.java?root=Tools_Project&r1=1.3&r2=1.4 [*] MIListThreadGroupsInfo.java 1.7 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/mi/service/command/output/MIListThreadGroupsInfo.java?root=Tools_Project&r1=1.6&r2=1.7 [+] GDBProcesses_7_1.java http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/gdb/service/GDBProcesses_7_1.java?root=Tools_Project&revision=1.1&view=markup [*] GdbDebugServicesFactory.java 1.12 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/gdb/service/GdbDebugServicesFactory.java?root=Tools_Project&r1=1.11&r2=1.12 [*] GDBProcesses_7_0.java 1.23 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/gdb/service/GDBProcesses_7_0.java?root=Tools_Project&r1=1.22&r2=1.23 [*] IGDBProcesses.java 1.3 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/gdb/service/IGDBProcesses.java?root=Tools_Project&r1=1.2&r2=1.3 Created attachment 174654 [details]
Screenshot of cores shown in attach process list
When the user wants to attach to a running process, we present her with the list of running processes. In some cases, the cores can be shown as well.
The screenshot shows how I propose to do this.
Ultimately, I think we should have a richer prompting for attaching to a process. The user should be able to search and sort. I'm even thinking that instead of a prompt we could have a new 'Target Processes' view, which the user could keep open and quickly select a new process to attach too. That view would be searchable and sortable. Maybe we could even allow the user to drag and drop a process onto a debugging launch session and automatically attach to that process. Until then though, I don't want to spend too much time revamping the current prompt window, so I suggest simply adding the cores as extra text, as shown in the screenshot I just attached. I just noticed that the filter box at the top of the process prompt view accepts *. Therefore, with the addition I propose, we could filter on "*core*1" to show the list of processes located on core 1. I also noticed that GDB returns the userId for the process. I think we should show this as well, since we have it. We could then filter the list on user id. Created attachment 174773 [details]
Screenshot with both 'user' infor and 'core' info
This screenshot shows what I propose to do to show the user and the cores when prompting for a process id.
Created attachment 174779 [details]
Patch to show users and cores when prompting for a process to attach to
This patch adds a way to show the userId and cores when prompting for a process to attach to.
The userId is available starting with GDB7.0, while the cores start with GDB 7.1.
This patch assumes that we will go to cdt.dsf.gdb 4.0 (major increment), since it seems that will happen. The change in this patch that breaks the API is that IThreadGroupInfo is extended and marked as @noimplement and @noextend, while the new IThreadGroupInfoExtension is removed since it was added to protect teh API, but now it just complicates the code.
I'll wait until it is confirmed that we are doing a major increment before committing this patch.
Created attachment 175600 [details]
Updated patch to show users and cores when prompting for a process
Updated patch for HEAD using version 4.0.
Committed to HEAD.
(In reply to comment #0) > 1- show the core in the thread labels of the Debug View. > 2- show the cores in the process label of the Debug View. > 3- when available, show the cores when listing processes to which a user can > choose to attach. The three goals of this bug have been achieved so I'm marking the bug as resolved. We can do many more things with 'cores' and I plan to work more on mult-core debugging as part of other bugs. *** cdt cvs genie on behalf of mkhouzam *** Bug 318230: Show cores and user name when listing processes to attach too. [*] ProcessInfo.java 1.3 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb.ui/src/org/eclipse/cdt/dsf/gdb/internal/ui/actions/ProcessInfo.java?root=Tools_Project&r1=1.2&r2=1.3 [*] GdbConnectCommand.java 1.4 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb.ui/src/org/eclipse/cdt/dsf/gdb/internal/ui/actions/GdbConnectCommand.java?root=Tools_Project&r1=1.3&r2=1.4 [*] ProcessPrompter.java 1.3 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb.ui/src/org/eclipse/cdt/dsf/gdb/internal/ui/launching/ProcessPrompter.java?root=Tools_Project&r1=1.2&r2=1.3 [*] MIListThreadGroupsInfo.java 1.9 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/mi/service/command/output/MIListThreadGroupsInfo.java?root=Tools_Project&r1=1.8&r2=1.9 [*] GDBProcesses_7_1.java 1.2 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/gdb/service/GDBProcesses_7_1.java?root=Tools_Project&r1=1.1&r2=1.2 [*] GDBProcesses_7_0.java 1.24 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/gdb/service/GDBProcesses_7_0.java?root=Tools_Project&r1=1.23&r2=1.24 [*] IGDBProcesses.java 1.5 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/gdb/service/IGDBProcesses.java?root=Tools_Project&r1=1.4&r2=1.5 [+] IProcessExtendedInfo.java http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/gdb/launching/IProcessExtendedInfo.java?root=Tools_Project&revision=1.1&view=markup (In reply to comment #20) > Created attachment 174779 [details] > Patch to show users and cores when prompting for a process to attach to > > This patch adds a way to show the userId and cores when prompting for a process > to attach to. > > The userId is available starting with GDB7.0, while the cores start with GDB > 7.1. A note that showing the cores in the attach prompt is currently only working in a remote-attach session (using gdbserver) because that is what GDB supports. |