Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Memory view

Hi Alvaro,
  Sorry I didn't get back to you earlier but I have been away on sick leave.
I have already extended DSF so I suppose it shouldn't be too difficult to do what I need to do. It's been a while though so I'll need a bit of time to get re-accustomed to things!

Thanks again for your suggestions,

Best regards,

Antony


On 31/01/2014 02:19, Alvaro Sanchez wrote:
Hello, 
There are few steps to follow to extend DSF-GDB,  
take a look to the following reference.



Regards
/Alvaro



On Thu, Jan 30, 2014 at 4:53 AM, Antony Burton <aburton@xxxxxxxxxxx> wrote:
Hi,
  I've never used Trace points, I will give them a go.

Yes, of course, you're right for the example being for CDI! That explains why it works on its own but when I try to use it in my launcher (which is DSF) it does not.
I'm beginning to see what I must do. Correct me if I'm wrong, but shouldn't I extend GDBMemoryBlockRetrieval() and override the getExtendedMemoryBlock() method? That seems straight forward but I'm not sure how I should associate it with my launch...

Thanks again,

Antony



On 30/01/2014 03:24, Alvaro Sanchez wrote:
Hi, 

1) the pseudo thread idea should work, although I am not sure if this is really necessary, have you considered using Trace points ?

2) The example you are using seems to use CDI i.e. not the default debugger. 
  The references in my previous response are for the DSF-GDB (The default debugger)
 I am not quite familiar with CDI or the actual example.   You might want to consider using the DSF-GDB implementation as a reference.

Regards
/Alvaro


On Wed, Jan 29, 2014 at 9:16 AM, Antony Burton <aburton@xxxxxxxxxxx> wrote:
Hi Alvaro,
    What I meant was, seeing that "GDB cannot write memory when pointing to a thread that is running", I could create a pseudo thread which is not running and does nothing and so I could point to it and visualize the memory whilst the other threads are are running. At the moment, when the memory view is open and monitoring an address, the only way I can refresh it is by stopping a thread.

Otherwise, I'm having some trouble figuring out what is going on with IMemoryBlockRetrievalExtension. I have tried following GDBMemoryBlockRetrieval() but am still no wiser.

Getting back to the example code found at: Inside the Memory View: A Guide for Debug Providers which works well without using my launcher,
 
After calling:


    IDebugTarget target = new SampleDebugTarget(launch);

whose constructor looks like this (it extends DebugElement and implements IDebugTarget, IMemoryBlockRetrievalExtension):

public SampleDebugTarget(ILaunch launch) {
        super(null);
        fLaunch = launch;
        fireEvent(new DebugEvent(this, DebugEvent.CREATE));
    }

and then adding the debug target to my launch:

        launch.addDebugTarget(target);

Why does the method getExtendedMemoryBlock() from SampleDebugTarget() not get called when I use the memory monitor? Is there something else I must do for this to happen? I thought it would be enough to add the debug target to my launch.

Thanks,

Antony



On 29/01/2014 12:50, Alvaro Sanchez wrote:
Hi, 
Even the simplest application should have at least on thread, so you should be ready to use the memory view.

/Alvaro


On Wed, Jan 29, 2014 at 4:38 AM, Antony Burton <aburton@xxxxxxxxxxx> wrote:
Hi,
   Thanks for your reply. I could maybe create a pseudo thread and point to it to be able to visualize the memory?

I will study your description of the implementation of IMemoryBlockRetrievalExtension and follow what goes on in debug mode.

Best regards,

Antony


On 29/01/2014 03:49, Alvaro Sanchez wrote:
Hello, 

1) 
>>  Is there a problem for GDB to read memory when the program is running?

I am copying a comment from file GDBMemory_7_0.java which explains this properly when reading or writing from/to memory.

// A memory context is a container.  We have two limitations with GDB here:
// 1- Before GDB 7.2, there is no way to specify a process for an MI command, so to work around
// that, we need to specify a thread for the process we want to point to.  This is important
// to support multi-process for targets that have that kind of support before GDB 7.2
// 2- GDB cannot write memory when pointing to a thread that is running.  For non-stop mode
// we can have some threads running with others stopped, so we need to choose a thread that is
// actually stopped.

2)  
>> getExtendedMemoryBlock() is not being called.

This goes with your implementation of IMemoryBlockRetrievalExtension, you can see the GDB implementation as a reference i.e. GdbMemoryBlockRetrieval, 
  With the latest code from master, follow the constructor and see that this is created by the block retrieval manager upon reception of IStartedDMEvent with a context of IMemoryDMContext (for GDB this is implemented by the class representing a process i.e. GDBContainerDMC), so for this case we have one memory context per process... 
  This also means that for GDB the IMemoryBlockRetrievalExtension is created each time a process gets created.

The above gives you an entry to a reference implementation for GDB which you can exercise with a simple test program, 

I hope this helps you continue
/Alvaro



On Tue, Jan 28, 2014 at 11:40 AM, Antony Burton <aburton@xxxxxxxxxxx> wrote:
Hi,
    I have two questions concerning the memory view:

1)  I would like to display memory in the memory view while my application is running. At the moment, memory values are only updated when I stop a thread. I would like to add a button that, when pressed, causes the memory view to be updated. Is there a problem for GDB to read memory when the program is running?

2) We have our own embedded debugger, so now I'm trying to write my own custom memory monitor. I followed the memory view example:

Inside the Memory View: A Guide for Debug Providers

The example works, but when I try to integrate it with our plugins and make my own memory monitor there is a problem: my custom getExtendedMemoryBlock() is not being called.

 In the example, the LaunchConfigurationDelegate just creates a new debug target as in:

public void launch(ILaunchConfiguration configuration, String mode,
            ILaunch launch, IProgressMonitor monitor) throws CoreException {
        IDebugTarget target = new SampleDebugTarget(launch);
        launch.addDebugTarget(target);

    }

I do the same thing at the beginning of my LaunchConfigurationDelegate but before, I call super.launch(config, mode, launch, monitor) to connect to my target...

Could someone tell me how to get my extended memory monitor to display? Once I can get it working , I can add a button to update the view on the fly.

Thanks in advance,

Antony

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










Back to the top