Community
Participate
Working Groups
Build Identifier: Provide a view which keeps track of execution locations for currently suspended processes, and provide an action to create PTP sets/groups corresponding to the processes at one or more of those locations. Reproducible: Always
Created attachment 177148 [details] initial patch for proposed contribution
I've committed a modified version of this patch to HEAD. Changes/issues: 1. The debugger is structured into two layers: an upper abstract layer (IP* interfaces) and the lower parallel debug interface (PDI) layer (IPDI* interfaces). Only the IP* interfaces should be used by the UI and external plugins, so I removed the direct access to IPDI* interfaces. 2. A dependency on the org.eclipse.ptp.proxy.protocol plugin was added. The ptp.debug.core plugin should not have this dependency so it has been removed. 3. The dependency in (2) was caused by code in PLocationSetManager#handleSuspendedEvent that issues a list stack frames request. I don't understand why this code is needed, and it should definitely not be referencing Proxy classes. At the most, only IPDI* interfaces should be used. I've left the commented code in place, but please explain it's purpose or let me know if it is ok to remove. 4. The view requires an icon. Please find an existing icon or create a new one. Please test the committed code to ensure that it is working as expected. Thanks!
2&3) The IPDILocator object available from the IPDIBreakpointInfo/IPDILocationBreakpoint is constructed from the breakpoint marker info rather than from an SDM event. Thus, the information available from the breakpoint locator is either incomplete or in a different format than the locators for other suspend types. The function info is not filled in for line breakpoints for example, and the filename is in the workstation format rather than the host format. The workstation filename info could be normalized with the backend format but that seemed a bit problematic, especially trying to retrieve and normalize the function name. The net effect of these differences is that you get weird/incomplete debug locations appearing in the view when you run to a breakpoint, as compared with simply stepping to the same location. Ideally, for each location you should get one entry in the view which is the sum of all processes at that location, regardless of whether the processes were run or stepped to that point. To sidestep this issue, the proxy call simply asks the process(es) stopped on the breakpoint for their actual location as the SDM understands it, which returns info consistent with the other suspend types like step_end. FYI: I didn't much like the addition of the proxy dependency or call either. That code is based on the existing example of PAnnotationManager#addAnnotationWithSourceFound in the ptp.ui plugin which does the same thing, so perhaps something should be exposed in the higher model layers for this.
I guess this code confuses me: TaskSet tasks = event.getTasks(); if (tasks.isEmpty()) throw new AssertionError(); TaskSet onetask = new TaskSet(tasks.taskSize()); onetask.set(tasks.nextSetBit(0)); This seems to be requesting the stack frame on only one of the tasks, but the tasks may have hit breakpoints at different locations. The locations of these tasks seem to be ignored. In any case, I think you can use the following code rather than referencing the proxy classes directly: IPDIBreakpoint bp = ((IPDIBreakpointInfo) reason).getBreakpoint(); if (bp instanceof IPDILocationBreakpoint) { locator = ((IPDILocationBreakpoint) bp).getLocator(); try { TaskSet tasks = event.getTasks(); if (tasks.isEmpty()) throw new AssertionError(); TaskSet onetask = new TaskSet(tasks.taskSize()); onetask.set(tasks.nextSetBit(0)); IPDISession session = reason.getSession(); IPDIListStackFramesRequest request = session.getRequestFactory().getListStackFramesRequest(session, onetask, 0, 1); session.getEventRequestManager().addEventRequest(request); IPDIStackFrameDescriptor[] frames = request.getStackFrames(tasks); locator = frames[0].getLocator(); } catch (PDIException e) { throw new RuntimeException(e); } } Can you test this and let me know if it is ok?
The IPDIBreakpointInfo associated with the IPDISuspendedEvent can only return a single breakpoint, so in practice we saw that separate IPDISuspendEvents were always generated for simultaneous breakpoints. ie: suspend events in different locations were never aggregated if they had a different reason (breakpoint), so it seemed safe to only ask a single member of the associated TaskSet for the location info. The code revision suggested in comment #4 works fine, thanks.
Created attachment 182432 [details] icon for the parallel debug locations view
Thanks! These have been committed.
