Re: [ECOS] eCos Kernel: ALLOC callbacks

[Jonathan Larmour <jifl at eCosCentric dot com>]

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 modified
> > No, 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
> hooks into the *impl.hxx files instead?
Well, there's no sensible way to add them there without an unnecessary 
extra level of indirection. So I'd say no.

> 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:
>
> memfixed.hxx
> memvar.hxx
> dlmalloc.hxx
>
> And their associated .cxx files.
>
> Am I missing any files?  If I am, please tell me which ones.
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.

> > > 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) ?
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:

Objtype obj __attribute__((init_priority(50000)));

or some other number from 0 to 65535, the latter being the default init 
priority anyway. But the preferred way to do this is with a macro 
CYGBLD_ATTRIB_INIT_PRI. See infra/current/include/cyg_type.h. Search for 
the uses of this macro (grep -r) for usage examples. There's plenty 
around. Some code still uses the CYG_INIT_PRIORITY macro, but that's 
deprecated really.

Jifl
--
eCosCentric       http://www.eCosCentric.com/       <info@eCosCentric.com>
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine


--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss