Date: Wed, 19 Mar 2003 22:52:00 +0200 From: "Eli Zaretskii" Sender: halo1 AT zahav DOT net DOT il To: djgpp-workers AT delorie DOT com Message-Id: <9003-Wed19Mar2003225200+0200-eliz@elta.co.il> X-Mailer: emacs 21.3.50 (via feedmail 8 I) and Blat ver 1.8.9 In-reply-to: <3E78B4BF.A8778A96@yahoo.com> (message from CBFalconer on Wed, 19 Mar 2003 13:19:43 -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> <9743-Wed19Mar2003183156+0200-eliz AT elta DOT co DOT il> <3E78B4BF DOT A8778A96 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: Wed, 19 Mar 2003 13:19:43 -0500 > From: CBFalconer > > > > 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. > > No, unfortunately (or fortunately) it is too late by then. I have > to capture the base of the allocation chains, and that is formed > on the initial call to malloc anywhere, and on any sbrk call that > returns unexpected values. I'm admittedly arguing without looking at the code, so I might say stupid things, but you could record the base of the chains when you first alloocate them and store them in some small number of variables. The sbrk allocations don't need to be recorded until `main' starts, since memory sbrk'ed before that is not interesting for the user. So that array you need to allocate could still be allocated after the startup code does its thing. Right? > Their actual allocation can take place long after any malloc_debug > calls are performed, and they would still be lost. Sorry, I don't understand how could this happen: any object allocated after malloc_debug is called will be recorded, right? > There is > nothing consistent evident from the startup operation - things > seem to change with command line length, for example. My guess > would be something to do with forming argv[]. Yes, it's alocating argv[] and environ[]. The former involves wildcard expansion, so could need quite a lot of memory (e.g., try "djecho .../*". Also, some memory is needed to read the DJGPP.ENV file and the response file(s), if any. > I can't declare a static array of pointers whose size is > determined at runtime. Why does it need to be static? > Nor do I want to get into any headaches from malloc recursively > calling malloc. True; that's why in my implementation I called sbrk directly. > Then please suggest which fields can be reused. The `hblks', `hblkhd', and `keepcost' are unused in my implementation. > Are the field names sacred? I believe so, I think I copied them from the Unix platforms where the same API is supported. I don't remember, but it's possible that the glibc implementation defines additional members, in which case we could add them and use them for what you need. > > > 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)? > > No funny surprises when joe luser prepares an application handling > his local shopping mall, creates a module named mallinfo, and > forgets to link it in. Or links it in and then expects to use the > allocation debug package. The same ``problem'' exists with any function whose name is identical to a library function. That's why library function names are ``reserved''. Nothing new here. > > 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. > > It is NOT going to be bloat. The debuggery package is in the > order of 2k of object code. I think 2KB is enough for us to want to avoid adding it. Charles Sandmann made several changes in the library lately for even smaller savings. > what about: > > int malloc_debug(int level, FILE *f); > > where f == NULL is the present call, and something else sets the > output file. Maybe we rename it _malloc_dbg and provide a macro: > > #define malloc_debug(i) _malloc_dbg(i, NULL) We could do this with the special GCC builtin that returns the number of arguments with which a function was called. > Please also see the sample output run I put up here a short time > ago. I will look at that when I have time, thanks.