Mail Archives: djgpp-workers/2002/10/21/06:30:23
Eli Zaretskii wrote:
> On Mon, 21 Oct 2002, CBFalconer wrote:
>
> > > The following external interfaces are missing:
> > > mallinfo
> > > malloc_debug
> > > malloc_verify
> > > mallocmap
> > > __libc_malloc_hook
> > > __libc_malloc_fail_hook
> > > __libc_free_hook
> > > __libc_free_null_hook
> > > __libc_realloc_hook
> > > __malloc_get_freelist
> > > __malloc_get_slop
> > > __malloc_get_bytes_in_use
> > > __malloc_get_chunks_in_use
> > > __malloc_get_sbrked
> > >
> > > These will need to be added, or alternate debugging routines written and
> > > documented. It appears retrofitting CBF's code with the above routines
> > > would be the right thing to do (but is fairly substantial work).
> >
> > I made provisions for getting at the internal structure, and used
> > an example of it in the dumps from the testing code. If you will
> > give me the details of what those interfaces have to do I will see
> > (no promises) how they can be generated.
>
> IIRC, all those interfaces, or at least those which are intended to be
> for public use, are documented in the library reference (see malloc.txh
> in CVS).
I still have not gotten CVS installed here, much less learned to
use it properly, especially from a remote source.
>
> > The point to me is that
> > any such interfaces are done through header files, and leave the
> > malloc code itself free to do what it needs.
>
> I'm not sure I understand. The debugging hooks are called by malloc at
> strategic places, provided that they are non-NULL (each hook is a pointer
> to a function, by default set to NULL). malloc is free to do what it
> needs, but it must call the hooks while it's doing that.
Why do it within malloc? Isn't it easier to define say
void * xmalloc(size_t sz)
{
void *p;
xmentryhook(sz);
p = malloc(sz);
xmexithook(p);
return p;
}
in the users space. Then there is NO overhead in normal malloc
use. Incorporating such pointers in the module will mean they
have to be NULL initialized and tested, and non-standard routines
will have to be present to set and reset them. It also means that
such routines as "free(NULL)" cannot simply do an early return,
but must use the single return point. Trivial, but a pain. At
present the global storage needed is limited to the free space
control table, and I have strained to minimize the size of this.
Or is name changing the operational problem?
At any rate, if you can ease my getting the descriptions of the
interfaces, I can think about things much better, rather than
making wild guesses. Just looking at the names above
realloc_fail_hook seems to be missing. And what about calls that
are rejected because the memory has been corrupted or free/realloc
is passed an invalid pointer (some of which I detect and do a
signal).
Do take a look at the interface I defined in sysquery.h (probably
should have a different name) which allows access to a struct
_sysquery via the call _sysmalloc(). That gets pointers to all
the private data and offsets. I deliberately arranged it to stay
out of the users namespace. The test (or tst) program has a usage
example.
--
Chuck F (cbfalconer AT yahoo DOT com) (cbfalconer AT worldnet DOT att DOT net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
- Raw text -