Multi-Process Debugging with OpenArbor

From DDCIDeos
Jump to navigationJump to search

Overview

This describes the proposed requirements and design for implementing support for multi-process debugging.

The overall implementation plan so far only requires changes to OpenArbor. The MLD and gdbserver will continue to have a one-to-one relationship. OpenArbor will handle starting multiple connections, managing them, and presenting them to the user. Since MLD/gdbserver never need to know this is happening, they can continue functioning as they always have.

See DDCI_PCR:2101 for implementation progress.

Action Items

  1. Multiprocess stoppoints cannot be set except from from the command view.
    • Fixed. See DDCI_PCR:2269
    • Right now in the StoppointManager's getDebugTarget, we return null if there's not exactly one debug process. As a result, we don't even try to create the stoppoint. There are a couple of other places that rely on this assumption as well. We don't need to do a lot to handle multiple processes, as the framework is already there. We just need to be aware of it where necessary. In this case, multiple processes could be handled similar to multiple threads, defaulting to the current one when there is a choice, with the option in the stoppoint dialog to select a different one. Or better, just follow the Eclipse model of setting stoppoints for all processes.
  2. The machine code window occasionally gets stuck 'retrieving' when multiple processes are connected. This can be fixed by clicking around the stack a bit, but it shouldn't happen.
    • Fixed. See DDCI_PCR:2270
    • To reproduce, start two debug processes. Pick a stackframe A in process 1, and a stackframe B in process 2. Click A, then click B, then click A. As you click back and forth between the two stackframes in the two processes, the machine code view will get stuck "Retrieving..." If you keep an eye on the logs as well, you'll notice that we stop sending any sort of commands to the MLD. This is caused by the logic that is supposed to prevent infinite refreshes in DebugProcess.debugContextChanged. Since you're clicking between two DebugProcesses, of course when you come back the stack frame is still going to be the same as the previouslySelectedStackFrame. This could be fixed by making the previouslySelectedStackFrame shared between DebugProcesses, so they recognize clicking between processes as still always being a different stack frame.
  3. We need to decide how to handle spawned processes. Maybe they can be accessed from the Status Monitor, but we still need to distinguish them from their parents. Possibly solved by action item 6.
  4. Proceeding with the assumption that multiprocess debugging will be supported using a single UI, we need to ensure that all process-specific views are kept up to date as the user navigates the call stack. The processes should just be another level as far as they're concerned.
  5. Consider collapsing every process except the active process, similar to how threads are handled, in order to focus on what is currently of interest and avoid accidentally entering the wrong process's call chain.
  6. There is no guarantee that process names will be unique. The process id should be used as well, so that processes can always be distinguished, even when they have the same name.
  7. Make the consoles at the bottom context-sensitive.
    • Fixed. See DDCI_PCR:2294
    • Fix the terminate handler so the consoles are only cleared if all the debug sessions are terminated.
  8. For scripting/logging support, there needs to be the ability/functionality to distinguish between processes when multiple processes are being debugged. Possibly solved by action item 6.
  9. Currently, there is relatively little in the way of UI changes that is required. Therefore, the changes to the test system should be limited to some minor adjustments to the Debug perspective logic, and whatever tests are needed to validate the behavioral changes.

Thorkil's Comments

Desired functionality

  1. Launching - separate MLD session for each process?
    1. Initial comments from --Trasmussen@ddci.com 12:31, 8 January 2013 (UTC)
    2. no action required: OpenArbor already manages launching the MLD to debug a user selected process. This involves creating a gdbserver process for the MLD to communicate via as well as the necessary ports. After the launching OpenArbor maintains a number of windows that use the MLD to get the data to display. Other windows are general debugging windows where debugger output is written, where debugger commands can be typed.
    3. no action required: OpenArbor is currently able to handle multiple debugging sessions simultaneously. Such sessions can address several targets, so the basic functionality for dealing with multiple MLDs is already present.
    4. no action required: Deos processes can in many ways be regarded as separate 'programs' that may share the same virtual address space, so it is a natural thought to consider connecting several MLDs to several Deos processes on the same target in a manner similar to OpenArbor's support for multiple programs each on its own board.
    5. no action required: For the MLD the controlling input is an executable file with code and data sections, debug information, symbol tables and more. The MLD has from start been a single-executable debugger, even though with Deos it was extended to have multiple executables for shared libraries as long as these libraries' virtual address ranges were not overlapping. The mapping of an address to a specific executable file is essential to the MLD, and this holds true for the shared object files.
    6. no action required: Should the MLD be extended to support more executable files it should also have multiple simultaneous connections and would have to keep them separated under just about all circumstances. Receiving and sending messages between the MLD and the targets would be a level more complex, and it would cause the risk that standard MLD behavior could fail in some cases. The MLD would have to be able to connect separately to each target, and in the Deos context this would mean connecting to a specific process, including starting a gdbserver for the connection, something OpenArbor already does well.
    7. no action required: The natural choice here is therefore to leave the MLD as a single-process/single-target tool, and for Deos to let OpenArbor connect the required MLDs in its usual way. This will require much fewer changes both to the MLD and to OpenArbor, and the risk that multi-process support is delayed or malfunctions will be much reduced.
    8. Action Item 1,2: An experiment has been conducted where OpenArbor was used to connect two MLDs to two Deos processes. OpenArbor started both MLDs and allowed debugging in both the processes. This included showing the proper source, running to cursor in both processes, displaying variables, call-chains, threads and more. With the present OpenArbor there were also some problems: setting break- and tracepoints was not possible, unless the debugger command window was used to set them instead, the machine code window was sometimes 'retrieving', but this could be fixed by selecting another call-chain level, and then return back to the desired level. The bottomline however was that OpenArbor was very close to behave as you would expect it to.
    9. Action Item 3: A special problem is how to debug a process spawned dynamically by another process. If the spawned process appears in the StatusMonitor view just like the other processes there could be a problem with how to identify which executable to use in the debugging. It should probably be the spawning process' executable, but then some way to identify that is needed. The spawned process has another start address than the spawning process, and maybe less code allocated in its virtual address space(?).
    10. more???
  2. Retain MLD functionality
    1. no action required: It is a multi-process functional design criteria that MLD functionality when inside a thread is as it has always been. The individual MLD does not need to have knowledge about the existence of other MLDs. The user can decide to look at variables in any of the MLDs and do with that as he wishes, including copying displayed data to a text file to help comparisons. The MLD shall do what it does best!
    2. Action Item 1,4,7: The original PCR 886 regarding multi-process debugging wrote: Deos customers often have two executables running on a target and would like to watch communication between the processes take place. Set a bp in each process, etc. This 'requirement' is without a doubt expected to be fulfilled whereas a requirement to make data values in one process available for the MLD in another process would have raised new issues regarding how the values are formatted and 'understood' in either process. Making things simple - like using a common debugger window - makes it more likely that the strategy we have chosen is being used.
    3. more???
  3. Updating of views
    1. Action Item 4: The general look-and-feel shall be that when you are in or have switched to a specific process then all the windows displayed reflect this process and thread. The overview of the possibilities for the user to switch between is the 'debug' window where all the debugged processes with their threads are displayed. It may be that only some of the debugged processes are actually stopped, and switching to a running process shall only allow the user to possibly stop it.
    2. Action Item 5: The switching between processes, or more accurately between a thread in process A and a thread in process B, shall use the call-chain view. There is from a user perspective no real difference between switching between two threads in the same process or in different processes. Inside OpenArbor it may involve more communication with the respective MLD for the new process. To avoid accidental switches to another process when a switch to another thread in the same process was intended, the non-selected processes' call-chains could be collapsed and requiring the user to open them explicitly.
    3. Action Item 6: Since process names are not necessarily unique, the display of a process' information should include the Deos process id that could be the only item distinguishing debuggers. Alternatively the port number could be used.
    4. Action Item 7: Some windows should not be process-specific, e.g. the debugger output window. If tracepoints have been set in two or more processes you would expect hitting these tracepoints would be shown in the order they arrived to OpenArbor. Both breakpoints and tracepoints are process specific, but hitting them causes 'common' windows to be used to reflect that.
    5. Action Item 7: Process data is process specific, but displaying an object in process A (which is going to be transmitted to process B) shall show the A-object in a common window, so that a suitable breakpoint in process B (at reception) can display the received object and compare in the common debugger output window.
    6. more???
  4. Scripting/Logging
    1. Action Item 8: Are logs/scripts desirable to work across processes and MLD instances? If so, would OpenArbor have pseudo commands that it handles to distinguish which MLD the next set of script commands is for. Similarly, would it log output indicating that it switched which process generated the next set of output?

Changes Needed to OpenArbor

  1. Action Item 2,4: All the process specific windows shall be checked to assure that they are updated again when a thread in the process is switched to. Many of the windows already appear to be updated, but problems have been seen with the machine code display that can be 'retrieving'.
  2. Action Item 5: Consider collapsing the non-active processes' thread displays when switching to a new process to avoid that the other processes are accidentally selected to switch to.
  3. Action Item 1,4: Correct that breakpoints and tracepoints cannot be set when two or more processes are under debug. Since these are process specific entities the window that displays them shall be updated when switching if that does not happen already (could not be established).
  4. Action Item 6: Add the process id for the call-chains to distinguish identically named processes in their display
  5. more???

Changes Needed to MLD

  1. no action required: With the basic idea that the MLD remains a single-process debugger, the existence of other MLDs debugging other processes is of no concern to the individual MLD. It may be that this idea will be revised later.
  2. more???
Retrieved from "https://ddci.zapto.org/ddciWiki/index.php?title=Multi-Process_Debugging_with_OpenArbor&oldid=21572"