delorie.com/archives/browse.cgi | search |
From: | sandmann AT clio DOT rice DOT edu (Charles Sandmann) |
Message-Id: | <10210210402.AA21746@clio.rice.edu> |
Subject: | Re: CBFalconer's malloc |
To: | djgpp-workers AT delorie DOT com |
Date: | Sun, 20 Oct 2002 23:02:20 -0500 (CDT) |
In-Reply-To: | <3DB32764.292952DC@yahoo.com> from "CBFalconer" at Oct 20, 2002 06:00:04 PM |
X-Mailer: | ELM [version 2.5 PL2] |
Mime-Version: | 1.0 |
Reply-To: | djgpp-workers AT delorie DOT com |
Errors-To: | nobody AT delorie DOT com |
X-Mailing-List: | djgpp-workers AT delorie DOT com |
X-Unsubscribes-To: | listserv AT delorie DOT com |
> Glad someone is looking at it. We have a few problems... The code is significantly different from the current documentation and user interfaces in CVS/V2.04. 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). There is also the question of stress testing the code. The easiest thing to do would be to fix the bare minimum naming to be libc compatible, dump it into a copy of libc.a, and try building the entire toolchain twice to see if all goes well. This would need a volunteer ...
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |