Mail Archives: djgpp-workers/2003/03/19/15:57:40
> Date: Wed, 19 Mar 2003 13:19:43 -0500
> From: CBFalconer <cbfalconer AT yahoo DOT com>
> >
> > 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.
- Raw text -