Mail Archives: djgpp-workers/2003/03/19/11:37:36
> Date: Tue, 18 Mar 2003 22:30:27 -0500
> From: CBFalconer <cbfalconer AT yahoo DOT com>
>
> 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.
- Raw text -