Date: Wed, 19 Mar 2003 18:31:56 +0200 From: "Eli Zaretskii" Sender: halo1 AT zahav DOT net DOT il To: djgpp-workers AT delorie DOT com Message-Id: <9743-Wed19Mar2003183156+0200-eliz@elta.co.il> X-Mailer: emacs 21.3.50 (via feedmail 8 I) and Blat ver 1.8.9 In-reply-to: <3E77E453.A12179D3@yahoo.com> (message from CBFalconer on Tue, 18 Mar 2003 22:30:27 -0500) Subject: Re: nmalloc revisited References: <10303181605 DOT AA14400 AT clio DOT rice DOT edu> <3E775688 DOT AC55F82B AT yahoo DOT com> <3E77E453 DOT A12179D3 AT yahoo DOT com> 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 Precedence: bulk > Date: Tue, 18 Mar 2003 22:30:27 -0500 > From: CBFalconer > > 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. Good news indeed! Thanks for working on this. > I am very nervous about examining the environment, since > malloc/free/realloc seem to be called deep within the startup > code While it's true that malloc et al are called inside the startup code, the debugging features can be disabled at that stage, since none of that phase is of any interest to users, and malloc_debug could be called only from `main' (or from static constructors that run just before `main'). At that point, there should be no problem to look at the environ[] array, since it's already set up. In other words, you could allocate that array inside malloc_debug, in which case you can be sure it's safe to examine the environment. > and the result can't be used to assign a static object anyhow. Sorry, I don't understand what problem you were thinking about here. > 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. Does that mean your code records the necessary information regardless? If so, isn't that an unnecessary overhead that could be omitted when debugging features are not required? > 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? We need to be compatible to the struct definition as it is now, since other Unix platforms use that. But I don't see any problem to use an unused member for what you need (there are a few that are unused in my implementation, IIRC). > How to handle namespace pollution? All those names (mallocmap > etc.) are in the users space, and should not be taken from him > IMO. Right. Those functions are documented and exist on other platforms, so we should keep their names. > I would much rather see a set of names in implementation > space. What would be the purpose of this, other than allow the debug interface to be part of the standard malloc (see below)? > If this is done the whole set of debuggery can always be > sitting there for use on demand, with no special linking etc. > requirements. There should be no special linking requirements. As soon as the application invokes one of the debug functions, the malloc-debug module will automatically be linked into the app. As for having it there by default, I'd rather not bloat every DJGPP program unless we really need that. We already have too many FAQs about the size of a hello world program. > I also suggest considering a means of setting a logging file for > the debug output. I don't mind, but that would be DJGPP-specific, as I think there's no equivalent functionality on other platforms that support malloc_debug. But if someone could find an equivalent functionality, I think we should design this to be API-compatible.