Mail Archives: djgpp-workers/2003/03/19/19:36:24
Eli Zaretskii wrote:
> > From: CBFalconer <cbfalconer AT yahoo DOT com>
>
... snip ...
> >
> > 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?
No, it does no good then. A look at the mallocmap dump I posted
will make it clear. Apparently the last allocation the RT does is
a 16k block (some sort of transfer buffer, I assume) which is too
big to use little bits that have already been freed. Now the
application can do its own allocations, which prefer to use the
existing free blocks rather than expand sbrk. All handled memory
is kept in a doubly linked list in memory order. This is one of
the things that makes the arena integrity readily checkable. The
only reliable way to get to these reallocations in a debug scan or
map is via the base of the list. Anything else would require
complex, quite likely unreliable, coding. There is nothing
esoteric about the structures I used. As Dijkstra used to say,
'pity my poor brain' and KISS.
>
> > 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?
See above.
>
> > 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.
But I don't need anything large. I allocate an array of 100
pointers, which I estimate to be overkill by about a factor of 10.
>
> > 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 propose to use hblks to report the count of free blocks, and
possibly hblkhd to report the size of the "lastsbrk" block
remaining (which is considered part of the free blocks). keepcost
could be the built in overhead, actually (DATAOFFSET * ordblks).
>
> 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.
If you have a handy URL to examine that I /might/ take a look. I
prefer not to.
>
... snip ...
>
> > > 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.
It is still too early to strictly evaluate code size. But I can
see uses for the availability of such facilities in the end
application. When something funny happens the programmer can get
the user to dump the whole mallocmap structure for analysis,
possibly via a secret runtime switch. Like a baby post-mortem
dump.
>
> > 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.
Never heard of that. I prefer to keep everything as standard as
possible. I am even unhappy about using the GCC varargs macros,
but I will wait for heavy C99 availability before taking them
out. Are you agreeing to that change in the malloc_debug call
and/or the use of _malloc_dbg()?
--
Chuck F (cbfalconer AT yahoo DOT com) (cbfalconer AT worldnet DOT att DOT net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
- Raw text -