Community
Participate
Working Groups
DSF adopters dealing with memory spaces currently have the ability to pass around a memory context that represents a particular memory space, via IMemorySpaceDMContext, a derivative of IMemoryDMContext. However, there is no means for getting information on the space beyond its string ID. In Freescale's commercial product, we need to find out whether a memory space is code or data, what's its range is, what is the addressable size of the memory and other such information. I polled the CDT mailing list to see if other vendors are in the need of such a service. TI, XMOS and Analog Devices expressed interest. I've attached a patch with my first draft of the interface. Interested vendors should review and express additional needs.
Created attachment 180619 [details] First draft of new interface
Created attachment 180659 [details] Get memory space info from expression One additional API related to memory space awareness - get memory space of an expression location. I have attached a draft for IExpression4 to get IMemorySpaceDMData from an expression. Another alternative would be a variation of IExpressionDMAddress that would provide memory space ID. Where it could be useful: - Handle correctly ExpressionChangedEvent to refresh a memory block on s specific memory space - Memory browser to create a memory block in the correct memory space based on expression without user explicitly selecting the memory space.
(In reply to comment #2) > Created an attachment (id=180659) [details] > Get memory space info from expression > > One additional API related to memory space awareness - get memory space of an > expression location. > I have attached a draft for IExpression4 to get IMemorySpaceDMData from an > expression. Another alternative would be a variation of IExpressionDMAddress > that would provide memory space ID. This capability is certainly needed. However, I'm not sure we need an API change. Couldn't we check the IExpressionDMContext to see if it's also a IMemorySpaceDMContext?
John, is this to enhance the support of IMemorySpaceDMContext? For instance, if my device support 3 memory spaces (e.g. Program, Data, I/O), this new interface will provide more information for each page. I assume that this has nothing to do with the Memory Maps our products support. For certains devices, we allow users to specify various ranges of memory addresses with different memory access (e.g. 0x0000 - 0x1000 no access, 0x1001-0xf000 readwriteable, 0xf001-0xffff no access, etc)
(In reply to comment #4) > John, is this to enhance the support of IMemorySpaceDMContext? For instance, if > my device support 3 memory spaces (e.g. Program, Data, I/O), this new interface > will provide more information for each page. I assume that this has nothing to > do with the Memory Maps our products support. For certains devices, we allow > users to specify various ranges of memory addresses with different memory > access (e.g. 0x0000 - 0x1000 no access, 0x1001-0xf000 readwriteable, > 0xf001-0xffff no access, etc) Yes. It's an extension of memory space support, of which IMemorySpaceDMContext was the first step (done for Helios). And yes, the idea is to provide information for each memory space ("page" in your terms). The concept of memory maps you describe is distinct from the concept of memory spaces. A memory map is a partitioning of a memory space into areas with varying accessibility.
(In reply to comment #3) > This capability is certainly needed. However, I'm not sure we need an API > change. Couldn't we check the IExpressionDMContext to see if it's also a > IMemorySpaceDMContext? Or you could call IMemorySpaces.getMemorySpaces() with the expression context. I'm not sure which is more appropriate so this is something that the API documentation should clarify.
(In reply to comment #6) > (In reply to comment #3) > > This capability is certainly needed. However, I'm not sure we need an API > > change. Couldn't we check the IExpressionDMContext to see if it's also a > > IMemorySpaceDMContext? > > Or you could call IMemorySpaces.getMemorySpaces() with the expression context. > I'm not sure which is more appropriate so this is something that the API > documentation should clarify. The documentation for IMemorySpaces.getMemorySpaces() is "Provides the memory spaces available in the given context". An expression is not a container for memory spaces. An expression, if an l-value, may be *associated* with a memory space. Thus, calling IMemorySpaces.getMemorySpaces() with an expression seems somewhat odd, and not something I think makes sense to support. I'll update the javadoc in IMemorySpaces to try to make this clearer.
Created attachment 180688 [details] proposed javadoc improvements Pawel, please see if this clear up the ambiguity you perceived.
(In reply to comment #8) > Created an attachment (id=180688) [details] > proposed javadoc improvements > > Pawel, please see if this clear up the ambiguity you perceived. Yes, that makes sense. Thanks.
Our product also needs to know the word size for a particular memory space as well. It would be good to provide an API to return the word size.
(In reply to comment #10) > Our product also needs to know the word size for a particular memory space as > well. It would be good to provide an API to return the word size. Can you spell out exactly what you mean by "word size". The term is quite overloaded.
*** cdt cvs genie on behalf of jcortell *** Bug 327484: New service for getting information on a memory space. Documentation improvement asked for in comment 6 [*] IMemorySpaces.java 1.3 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf/org.eclipse.cdt.dsf/src/org/eclipse/cdt/dsf/debug/service/IMemorySpaces.java?root=Tools_Project&r1=1.2&r2=1.3
(In reply to comment #11) > (In reply to comment #10) > > Our product also needs to know the word size for a particular memory space as > > well. It would be good to provide an API to return the word size. > Can you spell out exactly what you mean by "word size". The term is quite > overloaded. This is the size of the storage the device needs to represent one memory word. In most of the our devices, it is 32 bits. But some are 16 bits in the Program page but 32 bits in Data page.
(In reply to comment #13) > This is the size of the storage the device needs to represent one memory word. > In most of the our devices, it is 32 bits. But some are 16 bits in the Program > page but 32 bits in Data page. Is this a unit of address resolution? i.e. smallest data size that can be designated by an address. In this case this should be covered by covered by IMemorySpaceDMData#getAdressableSize
(In reply to comment #14) > Is this a unit of address resolution? i.e. smallest data size that can be > designated by an address. > In this case this should be covered by covered by > IMemorySpaceDMData#getAdressableSize It is the the size of the bus that used to read memory. As in Alain's example, program page bus can be 16 bits and data page bus can be 32 bits. Word size can be use to determine what is the default display data type. In the memory view example, you can display data type from as small as 8 bits and all the way up to 64 bits (or more), the default data type should be set to the word size when the view is open.
(In reply to comment #15) > (In reply to comment #14) > > Is this a unit of address resolution? i.e. smallest data size that can be > > designated by an address. > > In this case this should be covered by covered by > > IMemorySpaceDMData#getAdressableSize > It is the the size of the bus that used to read memory. As in Alain's example, > program page bus can be 16 bits and data page bus can be 32 bits. Word size can > be use to determine what is the default display data type. In the memory view > example, you can display data type from as small as 8 bits and all the way up > to 64 bits (or more), the default data type should be set to the word size when > the view is open. I see. Indeed customers for our product as well would like to have memory rendering to display data in "natural" memory grouping.
(In reply to comment #15) > (In reply to comment #14) > > Is this a unit of address resolution? i.e. smallest data size that can be > > designated by an address. > > In this case this should be covered by covered by > > IMemorySpaceDMData#getAdressableSize > > It is the the size of the bus that used to read memory. As in Alain's example, > program page bus can be 16 bits and data page bus can be 32 bits. Word size can > be use to determine what is the default display data type. In the memory view > example, you can display data type from as small as 8 bits and all the way up > to 64 bits (or more), the default data type should be set to the word size when > the view is open. OK. I assume we want to represent this in bits, correct?
(In reply to comment #17) > OK. I assume we want to represent this in bits, correct? Yes. Thanks.
John, I had a chance to go over the proposed interface and I have a few questions. 1. isCode() - this only limited to either code or not. Can this be expand to support more than just code or data? i.e I/O page 2. getAddressBitSize() - is this the same as the word size (bus size)?
(In reply to comment #19) > John, I had a chance to go over the proposed interface and I have a few > questions. > > 1. isCode() - this only limited to either code or not. Can this be expand to > support more than just code or data? i.e I/O page I was just modifying that to support the fact that a space (page) can be both data and code. I'll adjust it to return a set of flags as I think that will give us the most flexibility, and I'll add I/O as an option. > 2. getAddressBitSize() - is this the same as the word size (bus size)? They often are, but I imagine they could be different. You could have a memory space that spans 0->4GB (32 bits) but the bus only has 16 data lines. In that scenario, the word size would be 16 and the addressBitSize would be 32. Does that make sense? Also, we have to be careful about the term "bus size". A bus has lines to carry the address and lines to carry the data, right? So, in effect, the getAddressBitSize() returns how many lines are used for the address, getWordSize() returns how many lines are for the data being written/read. I think I should reword the documentation for both of these methods to explain the concept in terms of address and data lines on the bus. Do you think that would make things clearer? I think it's extremely important that we define these things accurately. Ambiguities in a standard interface often lead to problems down the road and compromise the cross-vendor interoperability the interface is meant to provide.
Created attachment 180785 [details] Second draft of new interface
I posted a second draft that hopefully addresses the points brought up in recent comments.
(In reply to comment #21) > Second draft of new interface Typo in IMemorySpaceDMData#getWordSiize
(In reply to comment #3) > (In reply to comment #2) > > One additional API related to memory space awareness - get memory space of an > > expression location. > This capability is certainly needed. However, I'm not sure we need an API > change. Couldn't we check the IExpressionDMContext to see if it's also a > IMemorySpaceDMContext? This would work only for the use-case when you create an expression on certain memory space context (i.e. current memory browser behavior when user specifies memory space of expression before evaluating it). However I am thinking of creating an expression on an execution context and quering to what memory space it actually belongs. e.g. dereferencing pointer to function expression should report that it belongs to Program memory space. However to know that, you have to evaluate the expression, thing that does not quite belong to context IDMContext paradigm, but more to data request paradigm as this can be costly.
(In reply to comment #24) > This would work only for the use-case when you create an expression on certain > memory space context (i.e. current memory browser behavior when user specifies > memory space of expression before evaluating it). > However I am thinking of creating an expression on an execution context and > quering to what memory space it actually belongs. > > e.g. dereferencing pointer to function expression should report that it > belongs to Program memory space. However to know that, you have to evaluate the > expression, thing that does not quite belong to context IDMContext paradigm, > but more to data request paradigm as this can be costly. Indeed. Your patch seems like the right way to support that use-case.
(In reply to comment #23) > Typo in IMemorySpaceDMData#getWordSiize How'd that 'i' get in there? ;-) Thanks. Will fix in the next (or final) draft.
Is there any update on this feature?
(In reply to Andrei Girnet from comment #27) > Is there any update on this feature? Not that I know of - John is not active in CDT for a long time now so I don't think this started work was ever completed. Note that we have moved CDT to GitHub, so any additional conversation on this topic would best be held there - https://github.com/eclipse-cdt/cdt - please feel free to start a discussion or featurerequest if you want to explain what you need or if you want to pick up John's work and see it to completion.
