Description Tomas Martinec 2011-06-12 18:32:05 EDT

Build Identifier: I20110519-1138

Hello,

I need a specific behaviour of gdb memory cache (implemented mostly in MIMemory class). The problem is basically that threads in my debugged program have separated address space (more details are here: http://dev.eclipse.org/mhonarc/lists/cdt-dev/msg22070.html).

I have already achieved the desired behaviour by redefining CDT behaviour from my plugin. However, I have not been able to avoid changes in CDT code completely. I attach a patch with minimal CDT changes that are needed by my plugin.

I would be happy to discuss (and possibly implement) any further required changes.

I will describe how I implemented the different address space for each thread and what lead me to the proposed changes:

At first I create my own thread context (MsimThreadDMContext) that implements IMIExecutionDMContext and IMemoryDMContext. This context is hold in GdbMemoryBlocks. For creation of such blocks I use my own memory block retrieval (MsimMemoryBlockRetrieval). During memory request these contexts are passed to my own memory service (MsimMemory) that derives from MIMemory. Unfortunately the cache behaviour in MIMemory is not very accessible. At least I need to access the fCommandCache field in the derived class, and to generalize fMemoryCaches field - which is the reason for the IMIMemoryCacheEntry interface in the patch. In the MsimMemory I implement my own cache, which is sensitive to the thread of the memory block.

I also attach the MsimMemory class. It might help to see how I have done things. The important parts are: getMemoryCache, MsimMemoryCache.getMemory and MsimMemoryCache.setMemory

... well, personally I dont think my minimal patch is well designed for a new public API. In MsimMemory.MsimMemoryCache I am forced to copy-paste the implementation of MIMemory.MIMemoryCache, because the MIMemoryCache does not allow an easy reuse. Currently the fCommandCache must be manipulated in both MsimMemoryCache and MIMemory, which looks quite unfortunate to me. And the IMIMemoryCacheEntry interface seems too complicated.

I would rather discuss the proper design for customizable cache API before implementing it just on my own. Personally I think that the methods IMIMemoryCacheEntry.getMemory, IMIMemoryCacheEntry.setMemory and IMIMemoryCacheEntry.refreshMemory should be moved to the MIMemory class and that the IMIMemoryCacheEntry should handle just its list (lists) of memory blocks. So IMHO the IMIMemoryCacheEntry should provide API just for storing the memory contents and getting it, and other logic should be performed in the MIMemory (or derived class). If you like that idea, I can implement and post a patch that would illustrate that.

Tomas

Reproducible: Always