This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
NavEcos wrote:
[snip]Here are my questions: 1) I think the changes need to be made to services/memalloc/common/current/src/memvar.cxx services/memalloc/common/current/src/memfixed.cxx And the definitions of the classes Cyg_Mempool_Fixed and Cyg_Mempool_Variable And that should cover doug lea's memory allocation as well. Is this correct or am I missing other classes that need to be modifiedNo, it wouldn't cover dlmalloc. Just the bog standard fixed and variable block allocators. You'd need to edit dlmalloc.cxx
OK.
Let me make it clear that I want to cover *every* dyanmic memory allocation that can be made by the application layer or the system. My goal it to be able to PROVE there are no memory leaks anywhere in the sytem, including the OS itself. This should give eCos a stronger selling point to potential customers. The same functionality can be used to prove there are no memory leaks in an application on top of eCos.
I was putting the hooks into the Cyg_Mempool_Fixed and Cyg_Mempool_Variable classes, would putting in the additional functionality into Cyg_Mempool_dlmalloc cover all the bases then?
Should do. The sepmeta allocator isn't instantiated for anything. > Should I instead put the
Well, there's no sensible way to add them there without an unnecessary extra level of indirection. So I'd say no.hooks into the *impl.hxx files instead?
Essentially what I'm asking, is where should I put in the hooks to make it the LEAST amount of work to maintain and yet cover all dynamic memory allocations and frees? So far, the list I have is:Well, one could argue that the system and the user always use separate pools, the only exception being malloc, so malloc.cxx may be sufficient. In other words, are you sure you want to track the times the kernel uses memory pools (and remember they have a fixed size and are segregated from other dynamic allocations) for *any* reason, or only when you want to track those allocations that could overlap with a user's.
memfixed.hxx
memvar.hxx
dlmalloc.hxx
And their associated .cxx files.
Am I missing any files? If I am, please tell me which ones.
It's not ISO C++ or portable no. There's no way in ISO C++ to do this - global constructor initialization order is undefined. This is a G++ extension. The info files document it, but the raw syntax is:2) It appears that heaps are being created before cyg_user_start. I want to install the callbacks into the system before any heaps are created - where should I install the callbacks?They are created by global constructors. "Simply" ( :-) ) create a global constructor of higher priority than any constructor creating a heap.
Ow - I think I got hooked on that catch.
Can you provide pointers as to how to do this? Is it ANSI C++ to do this (i.e. portable across compilers) ?
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |