Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Tapping into the Memory View

Hi,
  Thanks for your answer. So apparently, this is fixed in the latest version of Eclipse and CDT? At the moment, I'm working to get a minimal version of our plugin working with Kepler. I will also look into the patch figuring in the bug you mentioned, try to apply it to Indigo/CDT 8.02 and compare the two.

Antony

On 30/04/2014 13:58, Alvaro Sanchez wrote:
Hello, 
Your description is in line with the bug (mentioned before)

I think, the behavior you expect could be achieved e.g. by triggering a stop followed by a resume from the refresh action. This will cause it to reset the cash and a new read to reflect the new values.

/Alvaro






On Tue, Apr 29, 2014 at 10:52 AM, Antony Burton <aburton@xxxxxxxxxxx> wrote:
Hi,
  I'm back to the Memory View. I would like to follow Alvaro's advice and use the refresh command in the Memory View context menu.
I have found that the there are bugs which have probably been fixed in later versions of Eclipse and CDT (We're using Indigo/CDT 8.02). The problem is that the refresh command does not work correctly. Here is what I tried to do:

1) I have a remote target with a custom GdbServer.
2) I wrote a simple program with 2 threads: thread 1 which increments a global variable (theCounter), thread 2 which flashes a LED on the target.
3) I start the program...
4) I go to the Memory View and create a monitor to display the address of the variable "theCounter"
5) I choose a rendering and then a read memory command is sent to the target and the Memory View is updated.
6) When I use the refresh command from the context menu in the Memory View, nothing happens. (The display is not updated and and no memory read command is sent to the target).
7) I have tried suspending 1 or both threads before refreshing,  but the only way I can get the Memory View to update is by creating a new monitor.

Has this issue been fixed, and if so, is there a patch available for CDT 8.03?

Thanks for your help,

Antony

P.S. I'm using GDB 7.4


 On 22/04/2014 19:25, Alvaro Sanchez wrote:
Hi,
You could look at the changes introduced for the support of the memory changed event 
i.e. commit  0248aa4474165d5e39624971be5307212f9e5e2f
and from there decide if you want to re-implement part of it or upgrade, 

Before you do the above, consider that the default implementation for this event in Gdb 7.6 and above  is to notify of this memory changes when the memory is affected via the command line  interface. You could try it on a separate installation so you see this functionality in action.

if not sufficient, you could look into the possibility to enhance the implementation of the refresh button in the memory view / memory browser view.
see a pending cache issue documented in 


/Alvaro







On Tue, Apr 22, 2014 at 11:02 AM, Antony Burton <aburton@xxxxxxxxxxx> wrote:
Hi again,
    OK, I looked into the memory changed MI event. This looks very promising except our GDB version is 7.4 and we are using Eclipse Indigo and CDT 8.03 (we don't want to risk updating Eclipse or CDT for the moment). We can compile a 7.6 version of GDB but would it be possible to implement the memory changed event using our current versions of Eclipse and CDT?

Thanks,

Antony


On 22/04/2014 10:02, Antony Burton wrote:
Hi,
  Thanks for the info. Sorry I didn't respond earlier but I was I was on sick leave. Just got back, so will look into your suggestion today,

Antony

On 10/04/2014 12:26, Alvaro Sanchez wrote:
Hi, there is an MI event "memory-changed" introduced in GDB 7.6,  DSF-GDB supports it, it updates the cache and propagates/notify the updates to the UI  (see GDBMemory_7_6.java), 
  May be you could experiment with this and see if this would be feasible in your system


/Alvaro 


On Wed, Apr 9, 2014 at 12:23 PM, Antony Burton <aburton@xxxxxxxxxxx> wrote:
Thanks for the reply Marc,

    I did what you said and have been following the different classes such as DsfMemoryBlock. It is in this class that the method getBytesFromAddress is called which reads blocks of memory from the target.
It seems to me that it would be a lot of work to override all the different classes in a similar way to how it's done in the article "Inside the Memory View", so maybe there's an easier way.

All I want to do is periodically update the Memory view, I don't want to change the presentation. Do you think it would be possible to create a thread which loops and calls the method DsfMemoryBlock.getBytesFromAddress() every 2 seconds for example? Would this be enough to update the view? (and could I have access to this method?)

Thanks for you help,

Antony


On 08/04/2014 19:18, Marc Khouzam wrote:
I believe that article is general to the platform.  The Memory View is provided by platform and filled in by CDT.
It is used differently by DSF, but it is used nonetheless.
You can have a look at how DSF uses the MemoryView, by looking at classes like:

IMemoryBlock and its DSF extension
IMemoryBlockRetrieval and its DSF extension

Marc


From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Antony Burton
Sent: Tuesday, April 08, 2014 11:39 AM
To: CDT General developers list.
Subject: [cdt-dev] Tapping into the Memory View

Hi,
   I have created a plug-in which extends DSF-GDB and created a custom launch delegate. I use this to send commands to a custom GDBServer such as ones to upload the executable to the target, set thread dependant breakpoints etc. Now I would like to display memory while the target is running and periodically update it.

  I found the eclipse article " Inside the Memory View: A Guide for Debug Providers" (link<http://www.eclipse.org/articles/article.php?file=Article-MemoryView/index.html>). This is just what I want but it seems this is written for a CDI debugger. Could someone please explain how I could adapt this example for DSF?

Thanks,

Antony


_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev


_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev



_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev



_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev


_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev




_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev


_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev




_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev


Back to the top