Message-ID: <3DB3D5D9.F1DA8C95@yahoo.com> Date: Mon, 21 Oct 2002 06:24:25 -0400 From: CBFalconer Organization: Ched Research X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: djgpp-workers AT delorie DOT com Subject: Re: CBFalconer's malloc References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: djgpp-workers AT delorie DOT com 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. USE worldnet address!