Mail Archives: djgpp-workers/2003/03/17/00:01:55
Richard Dawe wrote:
> CBFalconer wrote:
> > Eli Zaretskii wrote:
> > > > Date: Sun, 16 Mar 2003 12:33:12 -0500
> > > > From: CBFalconer <cbfalconer AT yahoo DOT com>
> > > >
> > > > What I don't see in the htm file I posted before is any process of
> > > > setting those hooks described. Nor do I find any libc/malloc.h on
> > > > my system.
> > >
> > > libc/malloc.h is new with the development version of the library, so
> > > you can only find it in the DJGPP CVS.
> >
> > Then why is anyone worrying about compatibility with it?
>
> >From the "What's Changed" section for 2.04 in the Knowledge Base:
>
> "There are new `malloc' debug facilities. While not as powerful and
> versatile as existing external packages, such as YAMD, these facilities
> do allow to detect a wide variety of heap corruption problems, and to
> report important heap usage statistics. The new functions are
> `mallinfo', `malloc_debug', `malloc_verify', and `mallocmap'; these
> names are compatible with many Unix and GNU/Linux systems. In
> addition, special hooks, such as `__libc_malloc_hook' and
> `__libc_free_hook', are provided for building custom `malloc' debugging
> packages."
Following this (at the end) is the header file for malldbg, which
is the module that will implement all of this. The set of hooks
are fundamentally flawed, and, while included, I also propose a
set that will avoid those flaws. For example, the existing
realloc hook has no way of telling what the result of realloc
was. In addition the specifications have magic numbers, which
have no relationship to reality for this system.
>
> > I developed nmalloc to satisfy the well published and known standard
> > interface, and got people screeching about failure to mate with
> > other modules. I finally found a definition of those modules, and
> > am even attempting to provide something close, but now you tell me
> > those are for the inner-sanctum only and are not even published.
>
> The development tree in CVS, which is publically accessible. It's not just the
> "inner-sanctum" that can access it. People suggested several times that you
> should look at DJGPP CVS, because of various differences including the debug
> interface, and gave help on how you could get it (CVS, snapshot of CVS). Hint:
> you can get the test packages of DJGPP 2.04 made by Andrew, which are
> available from here:
>
> http://clio.rice.edu/djgpp/win2k/main_204.htm
Due to my innate crustiness etc., also the limitations of this
system, I am not about to create a whole developent environment.
And I have no idea what to poke at anyhow. I have to rely on you
guys for that. Nobody has confirmed or denied that the html doc
file I fed back earlier really covers the subject. Maybe the
following header will have better luck.
>
> > Why not define a proper interface first, and go from there. I
> > started this with the sysquery provisions in nmalloc, in such a
> > manner that ANY debugger could be built without unclean knowledge
> > of the malloc system guts.
>
> Maybe the sysquery interface will help implement some of the features required
> by the debug interface?
>
> > I feel a good healthy rant coming on.
>
> Uh-oh. ;)
I have modified (but not published yet) nmalloc to allow use of
the HOOKABLE define, which basically modifies the access points
from malloc to _malloc, etc.
/* -------- malldbg.h ----------- */
#ifndef malldbg_h
#define malldbg_h
/* This is to be used in conjunction with a version of
nmalloc.c compiled with:
gcc -DNDEBUG -DHOOKABLE -o hookmem.o -c nmalloc.c
after which linking malldbg.o and hookmem.o will
provide the usual malloc, free, realloc calls,
preventing any linkage from the normal library,
together with the following:
*/
#include <stddef.h>
struct mallinfo {
int arena;
int ordblks;
int smblks;
int hblkhd;
int fsmblks;
int uordblks;
int fordblks;
int keepcost;
};
struct mallinfo mallinfo(void);
int malloc_verify(void);
int malloc_debug(int level);
void mallocmap(int level);
/* FOUL FOUL FOUL FOUL */
/* This is a most unclean way of implementing the interface */
extern void (*__libc_malloc_hook)(size_t size, void *block);
extern void (*__libc_malloc_fail_hook)(size_t size);
extern void (*__libc_free_hook)(void *block);
extern void (*__libc_free_null_hook)(void);
extern void (*__libc_realloc_hook)(void *block, size_t size);
/* proposed future mechanism */
enum m_hook_kind {malloc_HK, malloc_fail_HK,
free_HK, free_null_HK,
realloc_HK, realloc_exit_HK};
/* Depending on kind, some params may be meaningless */
typedef void (*m_hookfn)(size_t sz, void *bk);
/* returns previous value of the appropriate function */
m_hookfn set_m_hook(enum m_hook_kind which, m_hookfn newhook);
#endif
/* -------- malldbg.h ----------- */
--
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 -