What should the Detail Pane Show?

The Wind River debugger, like GDB is an application which communicates with the Eclipse front end over a single communication channel. 1. Concept of ‘memory regions’ - For example: the current stack, some protected memory regions, the legal stack space, some hardware circular buffers, etc. These regions can be shown in the memory view: One way to show it is to have a colored line over the region; having such a line allows multiple regions that overlap to still have their corresponding line be shown, one on top of the other. 3. From editor it should be possible to open the disassembly view for the currently selected line in the editor (maybe a context-menu). 3. Context-menu for variables that allows to choose in which memory it should be shown. If a variable is selected in variables view, the memory view would highlight the corresponding region. 1.4.2) Thread-local variable expressions : User creates expressions for variables which are valid only in specific threads. 9. Building blocks of the view should not be limited to cores, but should be a generic building block that the user can name, set the size, specify the content.

Showing the content of the real registers (i.e., top stack frame) and also show the value of each register that was pushed on the stack, kind of like a stack frame display, or a hover, or … If we want to have user-program-defined regions, like circular buffers, this may also require user-definitions. The label could match the preference of if we expand automatically or not; we may want a separate preference for how much info is in the label. We could simply never allow switching, but it would be better to have a user preference for this. 5. If supported by GDB, Eclipse should make use of MI commands that read/write multiple registers in single operation for better performance. We'd need more specific examples of what folks are looking for beyond that to understand what would be useful/important to make exportable/importable. 5. Memory views showing different memories could have different background shades of color, to make it easier to distinguish the different memories. To support different memory spaces (logical or physical) the memory view will need to indicate which memory is being shown.

CDT currently offers two memory views: the standard Eclipse Memory view and a simpler Memory Browser. This would allow CDT users to visualize many different chips out-of-the-box. Tilera's set of chips is a good example. For example a project could provide a list of pre-defined groups. These regions will need to be defined somehow, some from hardware for example. 2. If things disappear (e.g., threads) the group will continue to exist with a smaller content. 3. Symbol matching on pointer registers, so if a register points to a variable/symbol, the view will show the name of the symbol. This option could be shown in the Debug view using the little icon of a chain to show that the group has the synchronized option enabled (they are linked together). 3. Need for an option to decide if the threads should be synchronized with the others of the group, or should not.

4. Need support for import/export. 5. Should support breakpoints synchronization from the target for breakpoints that already exists on the target. Debug Target - The current debug target element would represent the debugger. As mentioned earlier the debugger is a new concept in the debug model, which would be introduced by this feature. The CDT community is currently working on a feature that would allow to group elements of the debug view into user-defined groups. The only universal part of the view layout is that the top-level elements would be the active debuggers. The Debug View shows launches as top-level entries, but the information and the control functions associated with the launch is often duplicated by other elements in the hierarchy. 3. Persistence should be per launch. Below is a general list of enhancements that could improve multicore debugging for the CDT. 6. The Multicore Visualizer should support Grouping/Hiding very much like the debug view will, as well as Pin&Clone. 2. Although modules can change when a process/core is running, it only needs to be refreshed once the process/core stops, just like for variables and such. 5. When a new thread stops, do we switch focus to the new thread or not.

In the event you loved this post and you wish to receive much more information with regards to How to stack pool cues please visit our own site.