Mail Archives: djgpp-workers/2002/03/05/19:40:09
Eli Zaretskii wrote:
>
> > Date: Tue, 05 Mar 2002 08:20:38 -0500
> > From: CBFalconer <cbfalconer AT yahoo DOT com>
> > >
> > > That was just an example. A hook is more general than any specific code,
> > > because it allows a programmer to implement many features that the
> > > original author never had in mind.
> >
> > Nothing prevents you implementing a hook. You have lost nothing
> > compared to the present methods, but have gained the ability to
> > see inside the system, with a minimum of danger. In fact existing
> > hook implementations that intercept malloc etc. calls and record
> > parameters and return values should continue to work unchanged.
> > The only exception is where they make unclean assumptions about
> > internal structure, which they can now find automatically and
> > correctly.
>
> Sorry, I don't understand: these are very general statements, whereas
> I was looking for a specific technical answer. Could you please
> elaborate?
>
> What I had in mind was this: if malloc, realloc, and free call
> certain hooks in strategic places, then a programmer can use those
> hooks to implement additional features without any modifications to
> the source of the library functions. If there are no such hooks,
> what is the alternative method you offer in your implementation for
> getting the same functionality?
>
> Here's an example from the version of malloc in CVS:
>
> void *
> malloc(size_t size)
> {
> int b, chunk_size;
> BLOCK *rv, **prev;
> static BLOCK *expected_sbrk = 0;
>
> /* Refuse ridiculously large requests right away. Anything beyond
> 2GB will be treated by sbrk as a negative request, i.e. as a
> request to _decrease_ the heap size. */
> if (size > 0x7fffffffU - 0x10000U) /* sbrk rounds up to 64KB */
> {
> if (__libc_malloc_fail_hook)
> __libc_malloc_fail_hook(size);
> return 0;
> }
>
> Here you see that a programmer could point __libc_malloc_fail_hook to
> some function, and that function will then get called when malloc is
> about to fail. That hook could, for example, gather statistics about
> failed malloc calls.
>
> How can I do this with your implementation?
We have been talking past one another. I was thinking of the sort
of thing where the programmer writes:
void * my_malloc(size_t sz) {whatever(); return malloc(sz)};"
which might also (for failure catching) be coded as:
void * my_malloc(size_t sz) {
void * p;
if (!(p = malloc(sz))) whatever();
return p;
}
and you are thinking of catching specific happenings. Your
example has given me one. (I didn't realize sbrk could back up).
If you have a list we could have _sysmalloc take a record
parameter, consisting of an array of functional pointers, or
possibly an index/pointer pair to set/reset a specific hook. The
index/pointer pair would probably survive longer into the future.
Again, there is no problem doing these things, once the needs are
known. A line has to be drawn somewhere. The harder thing is to
define the interface to set them.
Something that might be thought about later, and that is feasible
in this implementation, is to cut back sbrk when all areas have
been deallocated. I can detect that condition. There is no point
if other things can't use the result, though, and I suspect DJGPP
can't. Other systems, such as Linux, would be different.
--
Chuck F (cbfalconer AT yahoo DOT com) (cbfalconer AT XXXXworldnet DOT att DOT net)
Available for consulting/temporary embedded and systems.
(Remove "XXXX" from reply address. yahoo works unmodified)
mailto:uce AT ftc DOT gov (for spambots to harvest)
- Raw text -