| Re: [cdt-debug-dev] Enhancements for the Memory View in Eclipse 3.2 |
Hi Jerome - Thanks for the feedback. It helps... Re: Support for several MAU The Memory View supports MAU larger than 8 bits. I believe you need CDT to do something in this area to display MAU larger than 8 bits. Re: Support target endianess The Memory View also supports different target endianess. What you need here is that CDT display correct values in the Registers View with different target endianess. Re: Support additional display mode. The Memory View allows clients to contribute custom renderings. You can easily have another display mode in a table format by subclassing from AbstractTableRendering. If you want to render in another format, e.g. tree, graphs, etc, you will have to create custom renderings. You mention "Fractional..." in your slides. What does that mean? What other renderings do you want support for? Since you use CDT, is it correct that you only talk to CDT through the CDI layer? i.e. you cannot contribute directly to Eclipse, you rely on CDT to add custom renderings? Re: Dump/Restore Memory There is a deferred enhancement request similar to your requirement: https://bugs.eclipse.org/bugs/show_bug.cgi?id=100080 Current definitions of the APIs allow us to add this function in the Memory View. This item is not currently planned for 3.2 due to time and resource limitation. If you would like to try to implement this, contributions are always welcome! :) Here's how I envision it to work: 1. We will need to add "export" and "import" actions in the table rendering. 2. When the "Export" action is invoked, a dialog is displayed. The dialog shows two things: address and length. The address field is pre-filled with the current selected address from the rendering. User can modify the address and the length. The dialog exports the memory with the specified address and length and saves the values to a file. Note that we are only saving the values. The file will not save the address nor the attributes of each byte. 3. When the "Import" action is invoked, a dialog is displayed to allow user to pick a file to import. The dialog will also ask for an address where memory is going to be written to. The address field will be pre-filled with the current selected address. Then the dialog reads the values from the file and goes through the IMemoryBlockExtension interface to write the values to memory. If the values can be written successfully, the memory block should fire a content change event. The rendering receives the event and refreshes. Re: Memory Search The Memory View has a "Go To Address..." action. This actions allows user to go to any address within a memory block. This should fulfill your requirement of an "Address" search. I have opened the following enhancement request for the "value" search feature: https://bugs.eclipse.org/bugs/show_bug.cgi?id=118660 This item is not planned for 3.2. I will only implement this if time permits. Re: Memory Mapped Registers I have recently added tooltip support in table renderings. By default, the tooltip shows the current address. Clients may override to show different text in a tooltip. Would it be sufficient for you to show register values in the Memory View? (Embedded image moved to file: pic18730.jpg) Re: Grey out unused Memory Space The memory view does not have a notion of "Unused" memory. The Memory View understands attributes defined in MemoryByte (readable, writeable, endianess and whether the byte has history or not). Unused memory means that the memory has not been initialized? I do not think I will change the definition of MemoryByte to add the "unused" attribute. I consider this to be a special case. I suggest that you subclass from MemoryByte to add the "unused" attribute. You can provide customized coloring to the rendering by providing an IColorProvider in #getAdapter(...) from your memory block. If a memory block provides an IColorProvider adapter, the rendering will consult the color provider when it comes to decorating the rendering. You color provider can check for this specialized "unused" attribute and grey out those cells accordingly. Thanks... Samantha Jerome CORRENOZ <jerome.correnoz@ st.com> To Sent by: CDT Debug developers list cdt-debug-dev-bou <cdt-debug-dev@xxxxxxxxxxx> nces@xxxxxxxxxxx cc Subject 11/30/2005 02:50 Re: [cdt-debug-dev] Enhancements AM for the Memory View in Eclipse 3.2 Please respond to CDT Debug developers list Dear Samantha, STMicroelectronics provides today several toolsets for its processors integrated into Eclipse/CDT Workbenches. We started to do this integration more than one year ago. We are now accelerating this process, preparing new products based on Eclipse and in parallel joining the consortium as add-in provider. Our products are mostly oriented towards embedded software development, but (will) also include specific tools for System on Chip development (traces, platform management, multiprocessor applications, etc). As part of our Eclipse work, we are monitoring several lists, forums and working groups, in particular those related to CDT. We have seen these last days in the cdt-debug-dev list that you plan to make some enhancements to the Memory View, a very important component for us, especially with respect to the support of our DSP processors. Thus we carefully read your proposal document ("Enhancements in the Memory View for Eclipse 3.2"), finding many useful items for our work. The attached document contains some ST specific requirements that we hope you could consider in your development plans. If we can contribute to the development of such features, we will be very happy to do it. In such case, please let me know how we can get involved. Hoping it helps. Best regards Jerome -------- Original Message -------- Subject: [cdt-debug-dev] Enhancements for the Memory View in Eclipse 3.2 Date: Thu, 17 Nov 2005 16:24:55 -0500 From: Samantha Chan <chanskw@xxxxxxxxxx> Reply-To: CDT Debug developers list <cdt-debug-dev@xxxxxxxxxxx> To: platform-debug-dev@xxxxxxxxxxx, cdt-debug-dev@xxxxxxxxxxx, dsdp-dd-dev@xxxxxxxxxxx Hi all - I have written a proposal to outline some of the enhancements being planned for Eclipse 3.2 The proposal talks about some of the problems with the current design and how we are going to address those problems. Let me know what you think. (See attached file: Proposal for Eclipse 3.2.doc) Thanks... Samantha Hi all, The Debugger plan proposals for 3.1 (or 3.2) have been posted at the Wiki page. I would like to have a conference call to discuss the plan items. I hope I would get some feedback by that time. Is December 1, 1:00 pm ET good for all? Thanks, Mikhail Khodjaiants QNX Software Systems _______________________________________________ cdt-debug-dev mailing list cdt-debug-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/cdt-debug-dev -- ---------------------------------------------------------------------- Jerome CORRENOZ | STMicroelectronics | HPC - Cores&IP Group jerome.correnoz@xxxxxx | Software, Tools & Services division Phone: (+33) 47658 6842 | Integrated Development Tools Expertise Center Fax: (+33) 47658 4211 | 12, rue J Horowitz BP217 | F-380019 Grenoble Cedex, France ---------------------------------------------------------------------- [attachment "ST-MemoryViewRequrements.ppt" deleted by Samantha Chan/Toronto/IBM] _______________________________________________ cdt-debug-dev mailing list cdt-debug-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/cdt-debug-dev
Attachment:
pic18730.jpg
Description: JPEG image
