Skip to main content

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

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