Mail Archives: djgpp-workers/2003/03/18/22:35:16
CBFalconer wrote:
> Charles Sandmann wrote:
> >
... snip ...
> >
> > I don't see a problem with a different test program as long as it
> > tests library functions to display similar information.
>
> 'similar' is just fine.
>
> It is a case of putting a limit on the things into which I will
> burrow. There are many things I would like to learn and
> investigate, but as I get older and approach dotage I realize that
> I simply cannot do it all, and that I have to put limits on
> things.
>
> I gather the whole hook mechanism is new, so I see no problem with
> using realloc entry/exit hooks, which require no assumptions
> whatsoever. The documentation for realloc_hook that I got says,
> in part, "called by free and malloc if and when realloc calls
> them".
>
> I am trying to implement mallinfo and mallocmap first, together
> with the hooks. Next will be malloc_verify, and meanwhile
> malloc_debug will just be setting an internal variable. I have
> all the data structures already, the problem is getting hold of
> the head of them, since each time sbrk returns an unexpected value
> a new chain is started. I may be forced to change the basic
> system slightly in order to record this.
Fairly good news. mallinfo and mallocmap now work. malloc_verify
looks like it will be no problem. The malloc_debug interface can
also be easy, but I think its semantics need some clearing up.
See below.
The structures to do all this are inherent in nmalloc, with the
one exception of an array holding pointers to sbrk calls that were
of the UNEXPECTED variety. I have never seen more than about 5 of
these. For the moment I am providing a fixed static array of 100
pointers to capture them, and this ensures that I can follow
everything. I seriously doubt that it will ever run out, but if
it does it does no harm, except that following some chains may be
prevented. The malloc etc. will still work correctly. It will
also be a compile time constant, so relatively easily changed. I
am very nervous about examining the environment, since
malloc/free/realloc seem to be called deep within the startup
code, and the result can't be used to assign a static object
anyhow.
The semantics of malloc_debug are going to need examination. All
the processes work from the get-go, so there is no need to enable
debugging to be able to examine things. The differences with
debug level will be in the actual response. For example,
mallocmap will simply not emit anything at level 0. Auto
verification will not be called below level 2. This makes level 1
pretty well an inhibitor of verify and map calls. mapinfo need
not be inhibited ever, since it is up to the caller whether or not
to use the data.
I would like to see an additional field to the mapinfo record,
specifying the count of free blocks. Will this cause problems
elsewhere, or will reusing an existing field cause problems? This
will help in evaluating the degree of fragmentation.
I am providing both flavors of hooks, with my earlier caveat. I
really feel quite strongly about fouling up well structured and
IMHO readable code to provide all those semantics.
How to handle namespace pollution? All those names (mallocmap
etc.) are in the users space, and should not be taken from him
IMO. I would much rather see a set of names in implementation
space. If this is done the whole set of debuggery can always be
sitting there for use on demand, with no special linking etc.
requirements. Access would be automatic on including the
appropriate header.
I also suggest considering a means of setting a logging file for
the debug output. I would do it by passing a FILE* in, and making
the user responsible for closing it on program exit. It may not
always be desirable to mix the output into either stderr or
stdout, and the proviso is cheap. It would default to stderr.
--
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 -