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]

Re: eCos Kernel: ALLOC callbacks


On Wednesday 23 October 2002 08:24 pm, Jonathan Larmour wrote:
> NavEcos wrote:
> > About a month ago, I suggested making some changes to eCos that would
> > allow:
> >
> > a) a callback for every heap creation
> > b) a callback for every heap destroy
> > c) a callback for post allocation/decallocation
> > d) a callback for pre allocation/decallocation
> >
> > This was so that you could add additional functionality, like putting in
> > padding in the alloced memory blocks to make certain memory isn't being
> > corrupted, and being certain that you're not allocated from heaps that
> > have been destroyed, etc.
>
> I should comment on your original mail better, but in brief this is
> reasonable, as long as it is optional!

Yes, it will be an option in CDL of course.

> > 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 I instead put the 
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:

memfixed.hxx
memvar.hxx
dlmalloc.hxx

And their associated .cxx files.

Am I missing any files?  If I am, please tell me which ones.

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

> > 3)
> >
> > I would like to make the callbacks global that that installing the
> > callbacks will do it for all heaps, not just an individual heap.  Are
> > there any objections to this?
>
> Configurability is the key. With configurability you could maybe do
> either, both[1] or neither.
>
> Jifl
> [1] Use a specific callback if called, or else the global one

Let me do the global callback support first since that is what *I* need, I'll 
be happy to implement the individual ones next :)  That sound good?

I appreciate your input very much and your help.

-Rich

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]